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 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_r1334533360