| [adoptium-wg] Java Floating Point Arithmetic and StrictMath method Correction? |
|
Dear Adoptim,
IEE 754 doesn't specifically say anything about the base 10 digit degradation that can happen at the right hand side of
float and double, inside their information range. 754 is not complete, and is not enough as justification. However all examples
like that are logic errors, that need to be repaired in either a default or mutual way, simply because denary accuracy is required
from them and out of the compiled Java program, and for any further in the program itself.
The problems occur by means of java arithmetic operations on float and double, and the java.lang.StrictMath method calls
as well. Any of these operators, on those two types, are presently offenders:
+, -, *, /, %, ++n, --n, n++, n--, +=, -=, *=, /=, %=
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!
Oracle and the Java Community Process aren't responding at all on this issue. It is better that a downstream vendor
accomplish these things, in a default or "switch" controlled mutually compatible way, 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.
The other option is a version compatible patch for one vendor's JDK and JRE that can be included or omitted.
Some entity out there that publishes an official implementation of OpenJDK simply must correct this whole problem,
even withstanding Oracle and JCP ignoring these problems.
Considering all this new information, can Temurin or
Adoptium change their minds on this critical issue?
Yours Sincerely,
Sergio Minervini
S.M.
Martijn Verburg
Mon 25/04/2022 9:12 AM
This is a matter for OpenJDK and has been discussed there before. Eclipse Temurin builds do not deviate from the standard OpenJDK implementation and we have no plans to change. Cheers, Martijn
A Z
Sun 24/04/2022 2:28 PM
Dear
Adoptium and Eclipse,
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 = a*b;
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 degradation 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@xxxxxxxxxxxxxx
|