Re: Infinite precision floating-point (was Re: Counting number of digits)

André Thieme wrote:
> jtdubs@xxxxxxxxx schrieb:
>
> > I've often wondered why no languages support infinite-precision
> > floating-point. Apprently, bignums where deemed important enough
to
> > standardize in Common Lisp, but not bigfloats. Anyone have an
> > explanation for this that they'd like to share with me?
>
> One thing I could think of as a first idea are irrational numbers.
> The program could find out if something is rational like (/ 1 3) and
> convert it to 1/3. But if you are calculating an irrational number
you
> anyway have to decide when to stop. And for that purpose the current
> solution seems fine.

Good point. I wonder if this would really be a problem though.

In what ways can you product a infinitely long number. I can think of
a few.

1. Type it in. :-). That's clearly not feasible.
2. Arrive at it as a result of a calculation. Now that's better.

But, what sort of calculation can produce a number of infinite length.
I can think of only a few of these, also.

1. An infinitely long calculation

An example would this would be using an infinite progression or
summation to calculate pi or e. No problem there because it will take
infinite time to get your infinite digits.

2. Division

What sort of numbers when divided produce an infinitely long result.
Infinitely long numbers are one such case, but that's our base case, so
that doesn't count. Simple numbers that result in a repeating
floating-point is another. All of these can be expressed as ratios or
rationals, which I would say is their more natural form. So, given 0.5
/ 1.5 in our system, we can find a common denominator and turn this
into 1/3 because we know 0.5 and 1.5 perfectly accurately. So, I don't
think these are a problem.

3. Exponentiation with a negative exponent

Square roots and the like. These are the toughest, I suspect. Perhaps
these need to be introduced as a valid numeric type also so that (expt
2 -2) results in some sort of #<EXPT 2 ^ -2> value which doesn't get
expanded. Coercing this to a bigfloat would be an infinitely long
operation, but I can live with that.

That's all I can come up with. I think this could be made to work, but
it would likely require a more rich number system to build off of.

Thoughts?

Justin Dubs

.

Relevant Pages

  • Re: solution for the interest rate of an annuity
    ... interestratein the present-value calculation of an annuity. ... the form of an infinite convergent series, ... upper bound on the error when calculating only a finite set of terms. ...
    (sci.math)
  • Re: solution for the interest rate of an annuity
    ... interestratein the present-value calculation of an annuity. ... the form of an infinite convergent series, ... upper bound on the error when calculating only a finite set of terms. ...
    (sci.math)
  • Re: Was Einstein the most ignorant, immoral, stupid, dishonest plagerist,
    ... To say that the calculation is not ... ab is the rod of 1m and is moving with v' relative to K'. ... because the mass of the rod becomes infinite. ... The mass doesn't change. ...
    (sci.physics.relativity)
  • Re: Division by Zero in Nature,
    ... It really isn't my calculation, ... But no infinite values are measured. ... >> The imaginary part of the refraction index is dvided by zero. ... >> The imaginairy part of n is a measure for absorption of ...
    (sci.math)
  • What Computationalism means
    ... An idealized Turing Machine is an infinite tape with binary digits on ... floating-point computations inside of them to decide what to do next. ... Because natural processes are NOT processes ... argument is only that OUR SIMULATION will be turing-computable. ...
    (comp.ai.philosophy)
Loading