hotspot-dev Digest, Vol 128, Issue 13

[A Z]

These are Java SE questions.

-Is it likely that JEP 306 could be updated in a Java update, earlier?
Apart from the assertion 'will not fix', accurate floating point
is a massive requirement.  It isn't very possible to do within-range
float or double multiplies, divides, powers, roots, or even things
in other classes like obtaining the distances between two points
(in Java2D and Java3D).

-Could there be a BigDecimal version of StrictMath
being put in to the standard libraries, under Java's own umbrella,
and not as someone else's separate library?


'Consider the square root function on the interval [1, 2), that is the
half-open region that includes 1 but does not include 2. This
corresponds to the floating-point numbers with an exponent of 0. There
are 2^52 floating-point values with this exponent. Mathematically,
sqrt(1) = 1 and sqrt(2) ~= 1.414... Therefore, in floating-point, for
values 1.0 <= x < 2.0, the result of sqrt(x) also has an exponent of 0.
Now we see that there are 2^52 floating-point values with an exponent of
0 and taking a square root of those values will only yield about 0.414 *
2^52 distinct answers. Therefore, we see that using a fixed
floating-point precision, the square root function on [1.0, 2.0)
*cannot* be inverted losslessly since only a minority of the input
elements have distinct answers.'

It is the case, however, that if the policy is taken, even slightly beyond the range of a decimal value,
e.g. that if the precision is 64, you can rationally aim to get the obverse and inverse of
a value in a function call if you round HALF_UP by means of considering the decimal
in precision 65, which is what I'm trying to suggest.  Some extra logic at the boundary zone,
to facilitate

(pow(sqrt(3),2) == 3) //true