<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi all,<div class=""><br class=""></div><div class="">Did anyone notice that the Project Oberon 2013 Math.ln(x) function gives very sloppy results, only the first decimal or first few decimals being correct? </div><div class=""><br class=""></div><div class="">While trying to produce a fractal on letter H (a nice programming task when your name is Hans ;-) and getting the result in figure 1, I first blamed my home grown graphics routines, but it soon became clear that Math.ln was the culprit. I use that function in my implementation of Math.power() which I need to calculate a contraction factor for the fractal.</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="9E2B3EA1-DA87-4F67-AA4C-119ACBAE049A" width="889" height="900" src="cid:DB9BCBE8-D6FF-41CD-8E60-B4F72D299A8D" class=""></div><div class=""><br class=""></div><div class="">To see the inaccuracy just calculate ln(5.0) with a calculator or on <a href="http://www.wolframalpha.com" class="">www.wolframalpha.com</a> and compare it with the result of Math.ln(5.0): the correct result to 6 decimal places should be 1.609438E+00 but Math.ln gives 1.621313E+00.</div><div class=""><br class=""></div><div class="">First I hoped that a typo was the cause: in the PO book (Applications, p. 83) constant q1 = 6.176106560E1, whereas in the source q1 = 6.76106560E1. But changing that value gave little improvement.</div><div class=""><br class=""></div><div class="">With the help of two older Oberon implementations I was able to figure out a correct version of Math.ln(x) which also uses the UNPK(x, e) standard procedure, and doesn't need to import SYSTEM. The new correct version turns out to be even simpler than the present one.</div><div class=""><br class=""></div><div class="">  PROCEDURE ln* (x: REAL): REAL;  (* hk  18 May 2024 *)<br class="">    CONST<br class="">      c1 = 0.70710678;  (* 1/ sqrt(2) *)<br class="">      c2 = 0.69314718;  (* ln(2) *)<br class="">      c3 = 0.89554059;<br class="">      c4 = 1.82984424;<br class="">      c5 = 1.65677798;<br class="">    VAR e: INTEGER; y: REAL;<br class="">  BEGIN ASSERT(x > 0.0); UNPK(x, e);<br class="">    y := x * 0.5; INC(e);<br class="">    IF y < c1 THEN y := 2.0*y; DEC(e) END;<br class="">    y := (y-1.0)/(y+1.0);<br class="">    y := c2*FLT(e) + y*(c3 + c4/(c5 - y*y))<br class="">  RETURN y<br class="">  END ln;</div><div class=""><br class=""></div><div class=""><div class="">  PROCEDURE ln*(x: REAL): REAL;    (* INCORRECT version *)</div><div class="">    CONST c1 = 0.70710680;  (* 1/sqrt(2) *)</div><div class="">      c2 =  0.69314720;  (* ln(2) *)</div><div class="">      p0 = -9.01746917E1;</div><div class="">      p1 =  9.34639006E1;</div><div class="">      p2 = -1.83278704E1;</div><div class="">      q0 = -4.50873458E1;</div><div class="">      q1 =  6.76106560E1;</div><div class="">      q2 = -2.07334879E1;</div><div class="">    VAR e: INTEGER; xx, y: REAL;</div><div class="">  BEGIN ASSERT(x > 0.0); UNPK(x, e);</div><div class="">    IF x < c1 THEN x := x*2.0; e := e-1 END ;</div><div class="">    x := (x-1.0)/(x+1.0);</div><div class="">    xx := x;</div><div class="">    y := c2*FLT(e) + x*((p2*xx + p1)*xx + p0) / (((xx + q2)*xx + q1)*xx + q0);</div><div class="">    RETURN y</div><div class="">  END ln;</div><br class=""></div><div class="">The two older versions (one from 1995 by Michael Griebling and another by an unknown author from the 1999 ETH Oberon System 3 release 2.3) give the exact same correct results, but could not use UNPK and therefore are much more and somewhat more convoluted. </div><div class=""><br class=""></div><div class="">The procedures UNPK and PACK prove very useful to implement these mathematical functions. In Griebling's version the functionality of UNPK is given by two functions fraction() and exponent() and that of PACK by a function scale(); they need SYSTEM.VAL() and SET. Also in the 1999 ETH version SYSTEM.VAL() and SET is used.</div><div class=""><br class=""></div><div class="">You can find them on my GitHub pages, along with a TestMath module. (<a href="https://github.com/hansklav/Oberon-07-Math.ln/tree/main" class="">https://github.com/hansklav/Oberon-07-Math.ln/tree/main</a>)</div><div class="">There you can also find the (imho) missing arctan() function. (<a href="https://github.com/hansklav/Oberon-07" class="">https://github.com/hansklav/Oberon-07</a>)</div><div class=""><br class=""></div><div class="">As far as I could test them the other functions in module Math (sqrt, exp, sin, cos, arctan) are accurate enough.</div><div class=""><br class=""></div><div class="">For those who are puzzled by procedures UNPK and PACK it may be informative to know that in most other languages their functionality is given by functions named frexp() and ldexp() or scalbn(). These routines are used to extract the binary fraction and exponent of 2 from a floating-point value, and to synthesize a float from these components. They provide a way to get at the internal representation of a float without doing direct bit manipulation. Wirth only used them in module Math.</div><div class=""><br class=""></div><div class="">With the new Math.ln() function the H fractal looks much prettier ;-)</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Hans Klaver</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="E9499BF6-8BCE-40E2-9CA9-717B27F4CB17" width="778" height="900" src="cid:CDFA0705-72E7-4A6B-822E-69C25C0574BA" class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></body></html>