Hi Boz,
At 03:05 PM 2/15/00 -0000, you wrote:
>
>The "pi issue" reminded me of a recent incident in one of my classes
>in connection with the introduction of "e".
>I asked the class to consider the expression (1+h)^(1/h) for small
>values of h. I was using DERIVE live in the class, and accessed the
>simplify, substitute commands to give h different values. I let h
>take the value 10^(-3) then used the approximate operator to get
>a nice result. I then let h take the value 10^(-6) and oops! - not what
>I expected - try it and see!
>I had to think quickly in order to get the desired result by altering the
>working precision.
>Of course, LIM((1+h)^(1/h),h,0) simplifies correctly to e WITHOUT
>any need to tinker with precision modes as I am sure that my friend
>Johann will be able to explain.
>
>Cheers,
> Boz Kempski.
Thank you very much, indeed. Your trusting in me surely boosts my
selfconfidence. I just wonder whether I can live up to your expectations.
Well, my guess is that DERIVE appoximates the subexpression 1+h in
(1+h)^(1/h) to 1, if h is close enough to 0 (e.g. h=10^(-6) for the default
precision). This leads to the result 1 for the whole expression, unless h=0
in which case its value is undefined.
LIM((1+h)^(1/h),h,0) is a different kettle of fish, where DERIVE is faced
with an indefinite form of the type 1^inf. At the risk of being wrong, here
my guess is that internally the computation goes along the following lines
(using the standard DERIVE notation)
LIM((1+h)^(1/h),h,0) = lim(exp(ln(1+h)/h),h,0)= exp(lim(ln(1+h)/h,h,0)) =
= lim(exp(1/(1+h)),h,0) = ê
where the rule of l'Hospital was used for the third equality. It could
also be that this limit is simply looked up in a table of standard limits.
At any rate, a totally different algorithm is applied in this case which
explains the different results.
Cheers, Johann
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|