Accuracy of Free42 and DM42

[Dieter]

(12-21-2017 08:30 AM)Thomas Okken Wrote:  Found it -- the special case for 45° is coded like

if (x == 45) result = sqrt(0.5)

May I ask why this is required? The sine for 45° ±1 ULP seems to be fine, so why has the 45° case to be handled separately?

Here and there it looks like my Free42 version 1.5.5 has the last (34th) digit sometimes truncated instead of rounded, but this is fine by me. On the other hand I seem to remember a remark - maybe by yourself - saying that some of the routines in the Decimal version may not return 34 exact digits since they originally had been used in the binary version with less precision (maybe 25 digits?). Since we're now at version 2.0x: can you say something about the accuracy level of Free42 in general? Does it - usually - provide full 34-digit accuracy?

Here I remember the HP15C Advanced Functions Handbook including a detailled documentation of the various error levels. Which shows that even a calculator with proven reliability will not always get all its returned digits right. Think 3²⁰¹. ;-)

Dieter

[Thomas Okken]

The way angles around 45° are handled is necessary to make its behavior symmetrical and continuous, in the Decimal and Binary versions.

Regarding errors in the final digit: if memory serves, IEEE-754 allows transcendental functions to be off by 1 ULP, while everything else is supposed to be correct within the limits of representation, i.e. 0.5 ULP.

When I mentioned, years ago, that Free42 Decimal doesn't evaluate transcendentals to maximum precision, this was in reference to Hugh Steers' BCD20 library. (He did modify that library eventually to provide full precision for all functions, which I integrated into Free42 1.4.52.) This doesn't apply to Free42 1.5 and later.

[Werner]

Dieter: that was necessary to make SIN(45°) = COS(45°).
Because if you do not handle that case separately, they will be calculated as SINRAD(PI/4) and COSRAD(PI/4), and those differ by a few ulps.

Cheers, Werner