On Fri, 1 Apr 2022 15:38:36 GMT, Andrew Haley <a...@openjdk.org> wrote:
>> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? >> I've noticed differences in iterative machine learning algorithms using exp >> & log across different JVMs and architectures which we try to track in >> [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in >> our model provenance objects. If this patch is integrated will there be an >> easy way to get (e.g. from `System.getProperty`) what implementation of exp >> is in use by the current JVM? Otherwise I won't be able to notify users that >> the model may not reproduce if they rerun the same computation on different >> versions of Linux with the same JVM & architecture. > >> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? >> I've noticed differences in iterative machine learning algorithms using exp >> & log across different JVMs and architectures which we try to track in >> [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in >> our model provenance objects. > > Exactly so, and that is why this patch was never integrated. This was only > ever going to be about `java.lang.Math`, but we foundered on the rock of > monotonicity. Here's the spec: > > "most methods with more than 0.5 ulp errors are required to be > semi-monotonic: whenever the mathematical function is non-decreasing, so is > the floating-point approximation, likewise, whenever the mathematical > function is non-increasing, so is the floating-point approximation. Not all > approximations that have 1 ulp accuracy will automatically meet the > monotonicity requirements." > > We couldn't guarantee we'd meet the monotonicity requirements if we used > glibc libm, so this patch was, with some regret, abandoned. @theRealAph Thanks for the summary. I closed the JBS issue as Won't Fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510
