luchsh
commented
2 years ago For the record, I'm not a maintainer any more and now speaking only on behalf of myself.
Based on my limited knowledge on Dragonwell project, the behavior regarding to floating point numbers is exactly the same as upstream OpenJDK project, (Dragonwell maintainers, please correct me if that info is outdated). The plan of changing anything may be up to current maintainers, here I can only help to ping @joeyleeeeeee97 @yuleil and ask for their opinions :)
joeyleeeeeee97
Does your JDK/JRE Java runtime generate floating point arithmetic or java.lang.StrictMath denormal and pronormal values as a result of course code like this?
**//The Java Language.
import static java.lang.System.; public class Start { public static void main(String ... args) { out.println();
out.println("Program has started...");
float a = 0.1F; float b = 0.1F; float c = ab; out.println(); out.println(c); double d = 0.1D;
double e = 0.1D;
double f = d*e;
out.println();
out.println(f);
out.println(); out.println("Program has Finished."); }}
/* Program has started...
0.010000000000000002
0.010000001
[0.01]
Program has Finished.*/**
IEE 754 doesn't specifically say anything about the base 10 digit degredation that can happen at the right hand side of float and double like the included example. However all examples like these are logic errors, that need to be repairs in either a default or mutual way, simply because denary accuracy is required out of the compiled Java program, and for any further of that Java program.
The workarounds, being BigInteger, BigDecimal, big-math are too slow and too large in memory, and don't allow for the use of arithmetic operators. Things that we need! Ir Oracle and the Java Community Process won't respond at all on this issue, it would be better that a downstream vendor accomplish these things, rather than logic errors remain in the Java runtime, requiring a poorer workaround to evade an error, permanently, for the whole Java language into the future.
What seems to be requires are having two range limits for float and double; values range limits, and consideration range limits. SSE registers, and compatible, exist in all relevant Java compatible CPU hardware. Those registers can be leveraged to solve these values and calculations problems.
If your Java runtime does produce floating point errors, can you either repair the root of the problem by default, or in a mutually compatible mode option way?
Can you please reply to me here in English, or at my secure secured email address,
sminervini.prism@protonmail.com
?
We would be thrilled to hear about a positive response!