Why does we still need StrictMath?

[Joseph D. Darcy]

On 5/8/2022 4:10 AM, Martin Desruisseaux wrote:
> Le 08/05/2022 à 10:56, Andrew Haley a écrit :
>
>> Some targets (x86, in particular) have intrinsics (log, trig) that 
>> are faster than StrictMath and also more accurate. StrictMath is not 
>> about accuracy, but cross-architecture down-to-the-last bit 
>> reproducibility. Whether we still need that reproducibility is, I 
>> suppose, something for debate.
>>
> In production code, maybe not. But in test code (e.g. using JUnit), 
> when the program does a lot of trigonometric operations (e.g. map 
> projections), I have meet cases where a test was successful on a 
> machine but failed on another machine. The systematic use of 
> StrictMath in all JUnit test code ensure that the difference in 
> behavior is not in the test code, so we can focus our debugging effort 
> on the main code.

JEP 306 was concerned with changing the definitions of the 
language-level floating-point operations and JVM-level floating-point 
instructions to be consistently strict, the original language and VM 
semantics from the mid-1990's.

The strictfp-ness, or not, of arithmetic operations is a separate matter 
from the semantics of the methods in java.lang.Math and 
java.lang.StrictMath. For example, even when strictfp and default-fp 
were both present, it is was *not* always necessary to declare a method 
in StrictMath to be strictfp (since the difference between strictfp and 
default-fp is only visible when overflow or underflow occurs).

As noted elsewhere in this thread, several platform have faster versions 
of some methods (log, sin, cos, tan, etc.) and in other situations it is 
more expedient to just use the reproducible methods in StrictMath. So to 
meet the reproducibility goals of the platform, StrictMath is still 
needed IMO while Math provides an alternative for users to opt-into 
possible greater speed.

(If Strictmath were being added to the platform today, its specification 
would most likely say the methods need to be correctly rounded, but that 
was less tractable a choice when StrictMath was added in JDK 1.3.)

-Joe