RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math

Raffaello Giulietti raffaello.giulietti at gmail.com
Thu Feb 4 11:22:43 UTC 2021


Hello Joe,

in the javadoc of acos() I think you should replace the mathematically 
incorrect

  * <li>If the argument is {@linkplain Double#isInfinite infinite},

with something like

  * <li>If the argument is zero,



Also, in some places pi/2 is described as

<i>pi</i>/2, rounded,

which is more open to interpretation, depending on what is meant by 
"rounded" (which mode? Granted, default is "to closest"), whereas in 
other places it is described as

the value closest to <i>pi</i>/2

which is preferable, as it is unambiguous.


Greetings
Raffaello



> On Thu, 4 Feb 2021 02:08:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:
> 
>> Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values.
>> 
>> Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present.
>> 
>> If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods.
>> 
>> There is no intention at the moment to change the behavior of pow to align with IEEE 754.
> 
> PS After the wording for the Math class is finalized, I'll add analogous wording to the StrictMath class and run a CSR.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2395
> 


More information about the core-libs-dev mailing list