'There was a JSR to add a new mode' Citation about problems with Java floating point:
https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf I suppose I would be asking for that change on float and double, that being the case, as well as an extra mathematics class for BigDecimal. People absolutely need decimal accuracy, and not floating point approximations, within their ranges. Double a = 0.1D; Double b = 0.1D; Double output = a*b; out.println(output == 0.01D); //false, should be true. //and, Float a = 0.1F; Float b = 0.1F; Float output = a*b; out.println(output == 0.01F); //false, should be true. Despite all the time since 1.1, these are necessary changes, since having to use BigDecimal for all accurate arithmetic begins to waste memory, instructions, and the presently unavoidable translation betwee get/set (float or double) and compute (BigDecimal) and convert to (float or double). The other thing is that whenever asking for a .distance() method in Java2D, Java3D, AWT, Swing, JavaFX, JavaFX2, if I even temporarily want to proceed with decimal distances, these methods are all possibly able to return underflow or underflow results. These are in fact not opinions, but very great needs that the Software community has needed from java for a very long time now, despite statements in the Java Language Specification, which in fact do not entirely, unilaterally implement the IEEE 754 standard. And can people please check out, sitting on the Oracle Java Bugs Database: JDK-8190947 JDK-8197995 JDK-8190991 JDK-8190946
