RFR: JDK-8316708: Augment WorstCaseTests with more cases

[Raffaello Giulietti]

On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

test/jdk/java/lang/Math/WorstCaseTests.java line 56:

> 54:  * sinh and cosh.
> 55:  *
> 56:  * Additional worst-case observed error inputs for the FDLIBM-dervied

Suggestion:

 * Additional worst-case observed error inputs for the FDLIBM-derived

test/jdk/java/lang/Math/WorstCaseTests.java line 230:

> 228: 
> 229:             // Worst-case observed error
> 230:             {-0x1.004d1c5a9400bp-1,    -0x1.0c6e322e8a28cp-1},

It seems that the exact value y meets `-0x1.0c6e322e8a28cp-1` < y < `-0x1.0c6e322e8a28bp-1`, and is closer to `-0x1.0c6e322e8a28bp-1`.
Thus, the correctly rounded result is `-0x1.0c6e322e8a28bp-1`.
The truncated (expected) value should be `-0x1.0c6e322e8a28bp-1` as well.

test/jdk/java/lang/Math/WorstCaseTests.java line 266:

> 264: 
> 265:             // Worst-case observed error
> 266:             {-0x1.34e729fd08086p+21,    +0x1.6a6a0d6a17f0fp-1},

Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result here.
I don't know why the paper says otherwise. Perhaps OpenLibm is not exactly fdlibm.

test/jdk/java/lang/Math/WorstCaseTests.java line 293:

> 291: 
> 292:             // Worst-case observed error
> 293:             {-0x1.0068b067c6feep-1,     +0x1.0c335e2f0727p1},

Similar considerations as for asin above.
The "expected" value should be `0x1.0c335e2f0726fp1`.

test/jdk/java/lang/Math/WorstCaseTests.java line 325:

> 323: 
> 324:             // Worst-case observed error
> 325:             {0x1.3f9605aaeb51bp+21,     -0x1.9678ee5d64935p-1},

The given expected value seems to contradict the introductory comment.
The exact value y meets `-0x1.9678ee5d64935p-1` < y < `-0x1.9678ee5d64934p-1`, and is closer to `-0x1.9678ee5d64935p-1`.
Thus, the rounded value of y is `-0x1.9678ee5d64935p-1`, but its truncated value is `-0x1.9678ee5d64934p-1`.
This should be the expected value, but then the test fails.

I don't think that the test logic can support errors > 1 ulp, as is the case here.
Perhaps, rather than a single expected value, there should be explicit lower and upper bounds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334533881
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334537273
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334556250
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334539144
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334533360