I am attempting to find someone who can program some important
alterations to the JVM for my sake, and that of the public too.
I'm after someone to reprogram, build and submit an altered
64 bit Windows version of Java SE 11 Stable version
(as downloads from the zip file at https://jdk.java.net/11/
that is altered so as not to have any more floating point arithmetic errors
(denromals and pronormals) produced any more, so that the default
behaviour is range accurate, and doesn't have any pronormal or denormal
values at the most RHS digit excent of the range. Probably, also in a way which
continue to use and be layed out in memory in optimised fashion.
This is, unless such a version of this release of the OpenJDK is already out there,
for 64 bit Windows, which I believe that such is not.
The types involved are float and double, Float and Double (autoboxing
The classic example for this problem is this very known example:
double a = 0.1;
double b = 0.1;
double x = a*b;
out.println(x == 0.01);
Brackets and arithmetic ordering have apparently been part of the problem.
+, -, *, /, %, ++x, --x, x++, x--, (, ), +=, -=, *=, /=, %=.
Hexidecimal mode needs to be corrected, on double and float.
Bitshifting operators may be impacted, and needs to be consistent
with the storage of the value; in the end it might not need to be changed,
or not very much.
java.lang.StrictMath will need to be updated so that all its methods operate
with accurate value consideration for the final decimal place is all function
input values. If any of it contains the strictfp keyword, those will all
have to be removed.
I would like the default changed to be range accurate,
and things left so that if the strictfp keyword is used,
denormals and pronormals come back again
(normally, as before), if this is not very harder.
The Global Location for anyone doing this, if they can, will realistically be
anywhere in the world, although it could be better (or not) if you are not
very much offset, either before or after, around
Australian Central Standard time, UTC + 9:30, GMT + 9:30.
I am probably looking for a more advanced programmer who knows
how to acheive all of the relevant changes described, and can rebuild
the runtime so that it will work flawlessly, again,
at all used and mutual interface points, with no
problems, at all the interface points for floating point
computations and submissions.
The ability to accept currency converted payment
through paypal details would be totally ideal, instead of the more challenging
but possible bank transfer approach.
Given that this issue is tantamount to an error fix in the Java SE language,
I am seeking a volunteer or lower cost worker who thinks similarly abou
t floating point operator errors at the Java defaulting as I do.
We can exchange through this forums by posting messages and replying,
certainly since they probably won't let people post email addresses in
their posts, really, anyway.
The last thing is that the results will need to be published on
sourceforge, for download availability, to comply with Java's GPL.
Last that I learned, Stephan van Hulst
seemed willing to help me, and I look forward to his reply.
I look forward to someone who can easily
produce or even knows more about this problem!