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:





-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 

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 

point and mathematical accuracy mode.

-It is so that the present arithmetic underflow and underflow are total 

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 

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 

which of itself possesses inadequecies in these places.

Can someone please reply to me on these things?

Can Oracle update the Java SE language?

Reply via email to