hotspot-dev Digest, Vol 128, Issue 13

[David Holmes]

"A Z" you already basically asked this in your "Java SE Maths questions" 
thread. Please don't create multiple threads on the same issue - and 
please never use the subject "hotspot-dev Digest, Vol XXX, Issue NN" - 
if replying to a digest please add the correct subject.

Thank you.
David

On 7/12/2017 12:04 PM, A Z wrote:
> 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
>