A related effect happens when investigating the behavior of the commonly used
⎛
1
⎞
n
calculus limit of
lim
⎜
1
+
. One of the common tasks given to students in introductory calculus classes is
⎟
n
→∞
⎝
n
⎠
to evaluate this expression for increasing values of
n
to see that it tends towards
e
. This can easily be done in
the Function aplet using the
NUM
view but there is a trap in store for the unwary!
Begin as follows:
1.
Entering the function into the
SYMB
view as
F1(X)=(1+1/X)^X
2.
Change to the
NUM SETUP
view and choose
Build Your Own
in the
NumType
field.
3.
Now change to the
NUM
view enter increasingly large values
for
X
.
The convergence towards e can also be seen graphically in the
PLOT
view but is very slow to reach high
accuracy.
The ‘trap’ mentioned earlier lies in the fact that the slow convergence will mean that people will often try to
graph this function for very large
values of
X
. The first graph on the
right shows the graph of this function
for the domain of 0 to 100.
The second graph shows how
instability develops in the domain 0
to 1E11 (
1 10
11
).
×
This apparent instability is caused by the internal rounding of the calculator. It works to 16 bits accuracy,
which means that it can store 12 significant digits (for reasons only of interest to programmers). This means
that when you invert a really large number and add it to one, you lose a lot of accuracy.
⋅ ×
⋅
×
For example, if X =
2 85 10
10
then 1/X is
2 5087719298 10
-11
. When you add 1 to this, the calculator is
forced to discard all but the last decimal place because it can only store 12 significant digits. Thus 1 + 1/X
becomes 1.00000000003 (rounded off from 1.00000000002508...)
There are naturally a whole range of numbers which will all round off to
the same value of 1.00000000003, so that (for that range of numbers)
the expression (1+1/X)X is equivalent mathematically (on the HP) to
1.00000000003X. This produces a short section of an exponential
graph, which only looks linear because you don't see enough of it.
81
