I have found that double and float types in java are heirs to arithmetic underflow and overflow at any use.
I have found that presently, floating point is an arithmetic approximation. My problem is that the java language needs to be changed here, so that one may have arithmetic accuracy with floats and doubles. There is also a trigonometric shortfall when it comes to BigDecimal. I have attempted to, and have more carefully described these problems, via the java bugs database: JDK-8190947 JDK-8197995 JDK-8190991 JDK-8190946 -These types, as things are, must be computationally discarded, used only in terms of push and pull, and be programmed around using BigDecimal, which will be a waste of memory, program execution speed, and a total confusion due to the lack of any operator usage options on BigDecimals. -It is the case that set, get methods, constructors and mutability methods are all based around float and double, not BigDecimal, which is part of the previous problem. -It is the case that setting up BigDecimals can be and is a circumstantial waste of memory with very many tasks, combined with the fact that the fact that having to use BigDecimal method calls is nowhere near as efficient or legible to developers or mathematics and enginner programmers (and useful with their time) as +, -, *, /, %, +=,-+,*=,/=,%=, ++, -- .This is a syntax argument largely, but also an instruction argument since BigDecimals have to be set up or used with an extra, thereby second, call. -It is the case that every other major language includes both floating point and accuracy mode options with these two types and or Objects, either as a source code instruction or as a compiler switch option. These languages at least provide both options for floating point and mathematical accuracy mode. -It is so that the present arithmetic underflow and underflow are total disadvantages, that need only be changed in place, for preconditions and postconditions. This is in regard to programs that have been compiled and built already. -It is also the case that the state of Java floating point for the last 10 years or so is not really any argument, given that things can be changed in place remaining reverse compatible, along with how clear and necessary the problem is. -My Oracle Support technical reviews seem not to recognise these real problems whatsoever, or only interpret matters in terms of the Java Language Specification on these issues, which of itself possesses inadequecies in these places. Can someone please reply to me on these things? Can Oracle update the Java SE language?
