How does the DM42 accuracy compare to other calculators ?

[Claudio L.]

(12-21-2017 07:01 PM)Dieter Wrote:  If it actually is zero something has gone wrong. ;-)

...

The non-zero imaginary part is not an "error", it's the exact result of the performed calculation.

I'm going to take the bait and play advocate of the devil here. If the argument is "exactly" 3.14159265359 is one thing, but if that number came from other calculations with roundoff error, the number is not exact, it is approximated.
We don't really know what the rest of the digits were going to be if we had more precision, so that number represents a range from [3.141592653585 to 3.141592653595[ which is the set of numbers that after rounding would've resulted in 3.14159265359.
Now that means sin(3.14159265359) could be any result in the range
[4.7932384626...E-12 to -5.2067615373...E-12[
Since asin(x) on all those numbers would produce the correct result of 3.14159265359.
By "snapping" the argument to 3.14159265359(00000000....) we are fixing the result of the function sin() to -2.0676153735E-13, but that doesn't make it the "exact" result, any number in the range above is just as exact, including the zero!
The choice of grid to "snap" our discreet results into can be changed arbitrarily. For example, newRPL uses degrees internally to "snap" angles to a grid, so sin(x) will convert that number to degrees 3.14159265359*(180/pi) = 180.000000000011846563 (bold numbers are the 12-digit precision limit). Since the original angle maps to 180 degrees with 12 digits, we can "snap" the result to 180
degrees and apply the function, obtaining zero for sin(180).
All this operation did is change the "snap" grid to something that actually includes the relevant points in the circle.
Is returning zero any better than the other result you called "exact"? Not really, it's just another value within that range of values that are acceptable results, but sure looks a lot cleaner on the screen.