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
