Well, things like range accurate floating point mode surely need to happen.
As Tim has said, Java® is here following the rules of IEEE754; no such change will ever be made. What's more, the Java® Language Specification (=JLS) says that floating‑point operations follow IEEE754, so it would not be possible to change that without breaking old code.Peter Baumarchais wrote:. . . these changes must and will go ahead. . . .
You haven&aposlt shown overflow nor underflow, but the simple imprecision inherent in floating‑point arithmetic. There is a page on the University of Princeton website showing how those imprecisions can cause wildly inaccurate results in some instances. I can't remember where it is, sorry.. . . arithmetic operations, that underflow and overflow.
. . .
Never. If you need more precision, it will be necessary to use a different platform.When are they going to include a compiler switch or a keyword to enable proper, range accurate arithmetic for the float and the double, and their objects?
They are indeed limited only by the memory capacity of the platform, but only support a limited number of operations, e.g. mutiplicative and additive. There is no way to calculate irrational numbers to a greater precision than the 53 bits you get with double. If you need that, you will have to use a different platform. I don't believe there ever will be such a greater precision for other operations. BigInteger's arithmetic is indeed precise, as is int's, but I don't think integer arithmetic is relevant to your question. Yes, there are major problems about the design of BigDecimal; you haven't mentioned the worst problem. Yes, maybe it would have been better to have a decimal primitive datatype, as does C#. But there isn't. Yes, maybe BigDecimal and BigInteger should support operator overloading for +-*/ and %. But they don't. And I do not believe that will ever change.-BigDecimal and BigInteger actualy are not arbitrary precision. . . .
Peter Baumarchais wrote:When are they going to include a compiler switch or a keyword to enable proper, range accurate arithmetic for the float and the double, and their objects?
Their own in place library code can produce errors in this area.
StrictMath, Vector3f and Vector3D are examples. Or calculating the norm of a vector.
-BigDecimal and BigInteger actualy are not arbitrary precision. Arbitrary precision arithmetic, in terms of digit places, is infinitely extensible to more integer or decimal places, limited only by available virtual machine memory.
-The largest scale arithmetic that the java language has also does not support operator syntax at the source code level, which it has to.
Trigonometry must include sin, cos, tan, asin, acos and atan. Support for power, nth root, square root, logarithms in base 10, 2 and Euler's e, a method for calculating pi to any decimal places, and a method for calculating e to any decimal places.
Actually, maybe I was mistaken on that point.Earlier today, I wrote:. . . The design of BigDecimal to be immutable is inconsistent with its use of operators like *=. . . . .
Floating point values in Java use the IEEE-754 standard
It's YOUR job as the programmer
How do you figure that BigDecimal isn't arbitrary precision?
Operator syntax source code? Why?
Peter Baumarchais wrote:
The solution to all this is what every other major language does here, which is either to introduce
a new keyword or such that can enforce floating point arithmetic range accuracy, or to introduce a compiler switch.
Stephan van Hulst wrote:
I'm also interested in a convincing example why you need more than 2 billion decimal places.
Why would you need more that 2.1 billion decimal places?
Peter Baumarchais wrote:I am in favour of increased operator support. That must happen.
Peter Baumarchais wrote:
Why would you need more that 2.1 billion decimal places?
Because you might. Because of reasons that people don't speculate on, because
of a situation which is outside of people's minds. That's why.
But you are more likely to be successful with that sort of request if you can present a concrete example of where > 2³¹ digits is likely to be needed.Dave Tolls wrote:. . . There's lots of things that some people might want to do with a language, but that doesn't mean a language has to cater to that. . . . .
There are three kinds of actuaries: those who can count, and those who can't.
Peter Baumarchais wrote:I would have thought that arithmetic and functions mathematics were so grass roots that the should have arbitrary support, anyway.
Besides which, their own documentary does use the term arbitrary precision, at any rate. Hence, along with grass roots concerns, the interest in it.
Peter Baumarchais wrote:However the changes that I am suggesting are not ultimately as complicated as all the other changes that they have been prepared to make.
...
A quality maths system, with operators, with the option to disable floating point overflow and underflow (for code thats already compiled) is not a particularly greater problem than any of these changes, and is even smaller a change.
Stephan van Hulst wrote:
In short, you will probably have to wait for a long time because you're in the minority that really wants this change, especially so if you can't produce scenarios where you absolutely need this behavior.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Yes, I'd like to be able to use a currency class that allowed mathematical operators, but so far no one has persuaded the architects of Java to permit operator overloading, and mathematical operators in Java apply only to primitives, not classes.
Side‑issue. Java® was “laid down” and “launched” in the days of 32‑bit computing, when there were still some 16‑bt machines around, but 64‑bit computing was but a distant vision. If we follow that sort of argument to its logical conclusion, would that mean you would like to use longs as a default integer type for arithmetic instead of ints, would you want a very long integer primitive (128 bits), would you want arrays to use longs as their indices and have capacities up to 2⁶³ elements, etc?Peter Baumarchais wrote:. . . 64 bit Java . . . doesn't have the memory limit that 32 bit java has. . . .