Please stop sending mails marked as urgent to a mailing list, you just make a fool of yourself.
The need to round floating point numbers for commercial math (and the risk involved in doing so) is nothing new, it predates the IEEE standard and should be subject for even basic comp sci curriculums all over the world. (Having said that, automatic precision/rounding for number formats in C++ looks neat) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev <core-libs-dev-r...@openjdk.java.net> im Auftrag von A Z <powerus...@live.com.au> Gesendet: Dienstag, März 15, 2022 5:24 AM An: core-libs-dev@openjdk.java.net <core-libs-dev@openjdk.java.net> Betreff: Discussion about Java Floating Point? To core-libs-dev@openjdk.java.net, In terms of floating point, it seems there are thus three (3) phenomena that are relevant. 1) Arithmetic on float and double, via operators. 2) Elementary function calls, namely those made from java.lang.StrictMath, as it is, on double values. 3) Comparison operators. ==, !=, >, <, >=,<=. Java floating point successfully has 3) the way required, even though other languages, particularly C++ , do not compare their floats and doubles through those comparison operators. The point at issue is Java although, so Java is satisfactory at point 3). My point of contention is that Java does not have 1) and 2) operating as they should, even though C++ and other languages do, in those two areas, namely C++: Martin has submitted the following: ?The following statement is not entirely true when using finite floating point precision: > (?snip?) It is a mathematical fact that, for > consistent, necessary and even fast term, 10% of 10% must > always precisely be 1%, and by no means anything else." /* #include <iostream> using namespace std; int main() { 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. */ This is actually not fully or finally true, including SSE, SSE algorithm logic and further. The included C++ example of mine above here disproves this. Even though I do contextually admit these answers can only work within the range of the involved types, it is still actually the case that 10% of 10% can and always precisely be 1%, within the range of the type used, and by no means anything else. Because of the laws of decimal arithmetic. See https://en.wikipedia.org/wiki/Floating-point_arithmetic and the starting sentence: 'In computing, floating-point arithmetic (FP) is arithmetic using formulaic representation of real numbers as an approximation to support a trade-off betwee range and precision.' However, it simply isn't the case that reduced precision has to exist inside the range, certainly not any more. Rationally, one would have to think, with the present SSE support in ubiquity, and the preimplementation that is possible and already around elsewhere, that this kind of tradeoff in floating point isn't any kind of use or advantage any more. This is part of the issue with Java and the OpenJDK at this time, and I am trying to contend that this should be changed, either at default or in some mutual compatibility mode. The other part is java.lang.StrictMath, since it generates denormal and pronormal values on its own, also. Raffaello has stated: To summarize, Java uses IEEE 754 binary arithmetic as by specification, as do most other languages, including C/C++. It is however fundamentally wrong to use binary floating-point arithmetic to emulate decimal behavior. Also, pay attention to the output routines that convert float and double values to a decimal representation. Usually, C and C++ will have information loss by default, as in your case. What we and others are beginning to need to happen, in detailed Java 2D and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java floating point arithmetic and function behaviour, on float and double, within their ranges, do need to perfectly match decimal behaviour. C++ arithmetic, at least, has had no problem using floating point arithmetic, at least, to emulate decimal behaviour. I am trying to prove the opposite to Raffaello's statements, that floating point can and indeed must represent decimal behaviour. Output functions in any language that alter the appearance of the float or double value become irrelevant, because the only relevant factor is the operator behaviour and the innate, representation viewpoint of those float or double values. In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must be changed so that it upholds base ten (10) arithmetic, algebra,and elementary functions on real value arguments within the ranges of double and/or float. Alongside a calculator class that upholds the same. These are in keeping with the Wikipedia view on floating point arithmetic that I quoted earlier, but more than that, they are in keeping with the standards/specifications of Mathematics, and not just an idea that grew in computer science. I wish to still request that this matter be pursued, despite Java's stance on this matter, in terms of the JRE for a very long time now. While it is the case that JDK-8190991 does exist, and should continue, JDK-8190947 has been too blithely swept away. See: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 The explanation 'Closing this enhancement as will not fix' does nothing to explain why the advantages of floating point repair have been turned away, and in fact, not apprehended specifically in Java. Is there someone who can look deeper into this matter, and implement arithmetic and Calculator class changes for the next release version of SE and OpenJDK?
