On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy <da...@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
