-
Bug
-
Resolution: Unresolved
-
P3
-
None
-
17.0.5
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
The bug appears on both tested hardware plaforms:
* Windows 11 running on Intel(R) Core(TM) i7-10875H CPU
* Linux CentOS distribution 3.10.0-1062.4.1.el7.x86_64 Intel(R) Xeon(R) CPU E5-2680
A DESCRIPTION OF THE PROBLEM :
I'am running an apache Math Common optimizer named LevenbergMarquardtOptimizer. Goal is to find parameters to a custom harmonic + polynomial model.
Using same exact input data lead the optimizer :
* Converge on Java 8 with parameters of the model are found
* Does not converge on Java 17
There is no crash just a divergence in numerical results.
I was wondering if JEP-306 would be the cause, but it seems that strictfp is by default enforced in Java 8 on my platform without having to specify the strictfp keyword, as described in a comment by Joe Darcy inhttps://bugs.openjdk.org/browse/JDK-8266524
In any case we are wondering what is the cause of this divergence, is it a know behavior ?
REGRESSION : Last worked in version 8u351
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I have a unit test to reproduce the issue. I first run it with Java 8 environnement (compile + runtime=Java8) then on Java 17 environment.
I just pushed on github a minimalistic reproducible example. You can find it here
https://github.com/gjevardat/ReproduceFloatingPointBug.git
Clone the project and run the unit test named TimeSeriesModelFitterBugTest. I ran it in eclipse as a Junit5 test.
To see the difference of behavior just switch the java.version property from 1.8 to 17 in the pom.xml.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect same result on both JDK's.
ACTUAL -
Results are not similar. In one case the apache math common LevenbergMarquardtOptimizer converges in the other case it does not.
---------- BEGIN SOURCE ----------
Unfortunately due the non trivial code that is used, it is difficult to provide a minimal running example. If necessary and if this problem is not known or not obvious we can put extra effort to extract a compilable code that show case the problem
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Non workaround
FREQUENCY : always
The bug appears on both tested hardware plaforms:
* Windows 11 running on Intel(R) Core(TM) i7-10875H CPU
* Linux CentOS distribution 3.10.0-1062.4.1.el7.x86_64 Intel(R) Xeon(R) CPU E5-2680
A DESCRIPTION OF THE PROBLEM :
I'am running an apache Math Common optimizer named LevenbergMarquardtOptimizer. Goal is to find parameters to a custom harmonic + polynomial model.
Using same exact input data lead the optimizer :
* Converge on Java 8 with parameters of the model are found
* Does not converge on Java 17
There is no crash just a divergence in numerical results.
I was wondering if JEP-306 would be the cause, but it seems that strictfp is by default enforced in Java 8 on my platform without having to specify the strictfp keyword, as described in a comment by Joe Darcy inhttps://bugs.openjdk.org/browse/JDK-8266524
In any case we are wondering what is the cause of this divergence, is it a know behavior ?
REGRESSION : Last worked in version 8u351
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I have a unit test to reproduce the issue. I first run it with Java 8 environnement (compile + runtime=Java8) then on Java 17 environment.
I just pushed on github a minimalistic reproducible example. You can find it here
https://github.com/gjevardat/ReproduceFloatingPointBug.git
Clone the project and run the unit test named TimeSeriesModelFitterBugTest. I ran it in eclipse as a Junit5 test.
To see the difference of behavior just switch the java.version property from 1.8 to 17 in the pom.xml.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect same result on both JDK's.
ACTUAL -
Results are not similar. In one case the apache math common LevenbergMarquardtOptimizer converges in the other case it does not.
---------- BEGIN SOURCE ----------
Unfortunately due the non trivial code that is used, it is difficult to provide a minimal running example. If necessary and if this problem is not known or not obvious we can put extra effort to extract a compilable code that show case the problem
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Non workaround
FREQUENCY : always
- relates to
-
JDK-8266524 javac changes for JEP 306
- Closed