Accuracy of Free42 and DM42

12222017, 07:17 PM
(This post was last modified: 12222017 07:19 PM by Dieter.)
Post: #21




RE: Accuracy of Free42 and DM42
(12212017 08:30 AM)Thomas Okken Wrote: Found it  the special case for 45° is coded like 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 34digit 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^{201}. ;) Dieter 

12222017, 08:43 PM
Post: #22




RE: Accuracy of Free42 and DM42
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, IEEE754 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. 

12222017, 09:11 PM
Post: #23




RE: Accuracy of Free42 and DM42
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 

« Next Oldest  Next Newest »

User(s) browsing this thread: