Java Floating Point Arithmetic and StrictMath Method denormal and pronormal errors?

[sminervini.prism]

To Jochen Theodorou, OpenJDK, and the JCP,

The subject of our inquiry isn't the introduction of new types with compatible data writing
to float and double. Rather, we are trying to justify that float and double themselves need
to be repaired, or rendered dual mode, in source code and for code that cannot be recompiled.

/*
//The Java Language. Arithmetic only, no comparisons.

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 repaired in either a default or certainly a mutual way,
simply because denary accuracy is required out of compiled, running, Java programs, in a fast,
efficient, and easiest-to-use way

The workarounds used, being BigInteger, BigDecimal, and big-math and the like are too
slow and too large in RAM memory, and don't allow for the use of arithmetic operators.
Things that we need!

What seems to be required is having two range limits for float and double; values range
limits, and right hand side consideration range limits for decimals and their relationship
to binary. If the existing range fields of float and double are not to be changed, but
if representation and inclusion problems are to go away, providing range accurate and
contiguous properties.

This applies to the float, float primitives, double, Double Objects, java.lang.StrictMath,
and any classes or interfaces closely bound with Float and Double, typically with
those terms in their names.

Extra SSE registers, and their descendents, exist in all relevant Java compatible
CPU hardware today. Those registers can be leveraged to solve these values and
calculations problems.

Another modern language that uses SSE, either by compiler switch or default, is GNU C++.
Its success, within ranges, certainly that are less than Java, yet nonetheless, are more
than an example, they are a source to draw from. Its implementation is freely available,
to copy, examine, include or refactor:

/*
//The C++ language. Arithmetic only, no comparisons.

#include <iostream>
//#include <iomanip>

using namespace std;

int main()
{
//cout << setprecision(20);
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}

Program has started...

0.01

0.01

Program has Finished.
*/

Compatability, if more desirable than default adjusting, can be leveraged at nearly any level.
If language precompilation cannot be altered, there are all sorts of approaches that would
work. Runtime and compiler switches would work. Manifest file entries are some option
Maybe annotations could be wrought to work, as applied to variables, data, objects,
classes and interfaces and static blocks. Just as float and double have the f,Fd,D,
data qualifiers, there could be subsequent data qualifiers and key words to go along
with float, Float, double, Double.

Since the OpenJDK does produce floating point errors, may those involved either repair the root
of the problem by default, or in a mutually compatible mode option way, in your version
of the OpenJDK and JRE?

We would be thrilled to hear about a positive response!

Sergio Minervini.

S.M.

Sent with [ProtonMail](https://protonmail.com/) secure email.