[Oberon] An alternative for the present inaccurate Math.ln(x)

Hans Klaver hklaver at dds.nl
Thu May 23 13:43:41 CEST 2024


Hi Jörg,

You wrote: 

> Thx for pointing out.
> Find a very minor improvement below:
>  
> PROCEDURE ln*(x: REAL): REAL;
> (* ln(x) = 2*arctanh( (x-1)/(x+1) )
>     around 0, arctan() is almost linear with slope 1
> *)
> CONST
> c1 = 1.4142135;  (* sqrt(2) *)
> c2 = 0.6931472;  (* ln(2) *)
> c3 = 0.89554059;
> c4 = 1.82984424;
> c5 = 1.65677798;
> VAR e: INTEGER;
> BEGIN
> ASSERT(x > 0.0); UNPK(x, e);            (* x in 1 .. 2 *)
> IF x > c1 THEN x := x*0.5; INC(e) END;  (* x in 0.7 .. 1.4)
> x := (x - 1.0)/(x + 1.0);               (* x in -0.17 .. 0.17 *)
> x := FLT(e)*c2 + x*(c3 + c4/(c5 - x*x))
> RETURN x END ln;

Beautiful!

Thanks. You managed to find an even more elegant form for ln().

But please note that there is an unclosed comment in the above code.

You mention the arctan() function, which reminds me of one episode in which I corresponded with Niklaus Wirth, about typos in his online book 'Programming in Oberon (a Tutorial)', later called 'Programming, A Tutorial'. I asked him if he had left out the function procedure arctan deliberately in his definition of Math.Mod (p. 46). He replied: "I did it intentionally, because I find that arctan is rarely used anyway". 

I was shocked. To me it was as if someone left out the icosahedron from the list of Platonic solids "because it is rarely used anyway"! 

The list of standard mathematical functions in programming languages has a long tradition (going back to FORTRAN, and Algol-60), and all these early languages were thought out by mathematicians or physicists, so I thought there was a good *mathemetical* reason to have arctan in the list.

Wirth was a pragmatic programmer, and for him obviously it was no problem at all to leave arctan out. But he was not extremely thorough, because arctan is still mentioned in 'Programming, A Tutorial', on p. 15 ;-)

I'm not a mathematician, but in my humble opinion Math.Mod without arctan is lacking. And maybe there are good computer science reasons to include more mathematical functions in it (as proposed in the Oakwood Guidelines).

Regards,

Hans



More information about the Oberon mailing list