Re: Calculating e
[Prev][Next][Index][Thread]
Re: Calculating e
Lisa Ledwith <lledw@GA.K12.PA.US> writes:
> I wanted to illustrate on the calculator how (1+1/A)^A goes towards e as A
> becomes large so I wrote the following program. Everything is fine until I
> get to 10 x 10^13 because the value for B is greater than e. I think this
> is probably a rounding error but I don't know what is really happening. I
> understand what is happening when A is 10x10^14 --- at least I am assuming
> that the overflow in the calculator allows 1/A to be undefined so from that
> point on the calculator thinks it is rasing 1 to a power and thus yeilds 1.
Hm, I think you are exceeding the dynamic range of the floating point
implementation of the calculator. All floating point systems (that I
know of) use a fixed number of bits (or digits) for the mantissa and
the exponent.
To illustrate this, let's assume a floating point format that can
handle only 5 digits of mantissa and 2 digits of exponent. Such a
system can still represent numbers as big as 0.99999*10^99 and as
small as 0.00001*10^-99 (0.99999*10^99 and not 9.9999*10^99 because
numbers get normalized internally). However, the dynamic range is
always limited to 5 digits. So, if you want to add or subtract, the
two operands need to be "lined up" first.
1.0000 (0.10000*10^1)
+0.00001 (0.10000*10^-4) aligning this with above number yields 0.0000
-------- because only 5 digits can be represented with a 5 digit mantissa.
1.0000
In this fictitious example, the smallest number you can add to a
number x*10^n is 1*10^(n-4) (5 digits dynamic range).
> I added the lines in the program to dispay the value of A and then played
> around a bit. When I increase A's value by multiples of 5 or 2, similar
> things happened. If I change the multiplier to 5 or 3, I eventually get
> numbers on either side of e. Also, if I change my seed, A, to 9, I get
> weird results. Can anyone explain what is happening here? At the very
> least, I have another example of how the calculator can 'lie'.
>
> 10 stor A
> Lbl 1
> (1+1/A)^A sto B
> DISP B
> DISP A
> A*10 sto A
> PAUSE
> GOTO 1
Most floating point implementations convert decimal numbers to
internal binary floating point format. That's why the "funnies" occur
at weird decimal numbers. You can probably deduct the internal binary
presentation by observing exactly where the truncations occur.
Deduction can be quite difficult because the calculator may or may not
use rounding before truncation or use several more digits internally
than it displays etc...
There are arbitrary precision calculator programs that run on PCs.
I think they use the closest integer fraction to represent numbers.
E.g. 22/7 to represent 3.1428571....
Disclaimer: I have ported a floating point library once, but I am not
a mathematician. Somebody may have a mathematically more correct
answer than this.
Regards
--
Manfred Bartz <mbartz@werple.net.au>
References: