OpenEuphoria

[EUPHORIA (#1998-27)] Comments on other postings

• Posted by Jeff Zeitlin <jeff.zeitlin at MAIL.EXECNET.COM> Jun 15, 1998
• 623 views

On Sun, 14 Jun 1998 00:00:11 -0400, Andy Kurnia <akur at DELOS.COM>
wrote:

>>global function exp(x)
>>  return power(n,x/log(n))
>>end function

>Nice try, but it should be
>global function exp(atom x)
>                    ^^^^
>(integer x would have worked as well).

You're right; I managed to overlook that.  Atom is better than
integer; no sense in restricting it to integral powers when the
function itself is continuous over any value of x.

>An unoptimized experiment:
>-- exp.ex begins
>atom n
>
>function exp(atom x)
>    return power(n, x / log(n))
>end function
>
>for i =3D 0.5 to 10 by 0.5 do
>    if i !=3D 1 then
>        n =3D i
>        printf(1, "n =3D %4.1f, e =3D %.15f\n", {n, exp(1)})
>    end if
>end for

[results snipped]

>i.e. the e remains the same for every n 

Yup.  The derivation I came up with so indicated.  That's what
led to the function.  As it turns out, that particular expression
will yield as its result whatever number the "log" function uses
as its base.  If you have a language that uses "log" for base 10
and "ln" for base e, the formula as written will yield 10^x;
you'd have to rewrite it as power(n,x/ln(n)) to get e^x.

>Another way to calculate e, without using log, is to calculate
>    e =3D power(1 + 1 / k, k)   -- or e =3D power((k + 1) / k, k)
>with k being (an integer?) as large as possible. For example,

Nope.  The expression is power(1+(1/x),x) or power(1+x,(1/x)).
But it _does_ approach e as a limit as x increases without limit.

>    (5001/5000)^5000 =3D 2.718010050102
>    (10001/10000)^10000 =3D 2.718145926825
>    (50001/50000)^50000 =3D 2.718254646127
>    (123457/123456)^123456 =3D 2.718270819444
>    (654322/654321)^654321 =3D 2.718279751283
>    (123456790/123456789)^123456789 =3D 2.718281794077

Notice how at comparatively low x, the accuracy of the value of e
is poor.  If you have base-e logarithms available, it's better to
use the formula I gave.

>The following are against the limit theorem, or else Microsoft's =
calc.exe
>has a bug:

>    (987654322/987654321)^987654321 =3D 2.718282052029
>    (9876543211/9876543210)^9876543210 =3D 2.718279072627
>    (1000000000000/999999999999)^999999999999 =3D 2.718523496035

There are known bugs in calc.exe, and known bugs in some early
Pentium chips.  Also, as noted above, low limits to the size of
atoms or atom-equivalent result in low accuracy as well as low
precision for the value of e.
--
Jeff Zeitlin
jeff.zeitlin at mail.execnet.com