# Fw: Question about JEP 306.

joe darcy joe.darcy at oracle.com
Wed Dec 6 23:15:57 UTC 2017

```PS With a more concrete example below....

On 12/5/2017 6:55 PM, Joseph D. Darcy wrote:
> Hello,
>
> On 12/5/2017 5:07 PM, David Holmes wrote:
>> Adding core-libs-dev as both mailing lists are named in this JEP.
>

[snip]

>>> It should also be the case
>>> that there should be a round half up for the decimal place
>>> beyond the last one in the float or double range, to help support
>>> all notions of
>>>
>>> (pow(sqrt(3),2) == 3)  //true
>
> Putting aside non-finite values like NaN and infinities, this identity
> is difficult to have hold in any fixed-precision system, including
> IEEE-style floating-point. The mathematical square root function in
> general returns irrational results for rational inputs so the result
> is fundamentally approximated.  If my rusty calculus is correct, for x
> >= 0.25, the derivative of sqrt of x has magnitude less than one and
> is positive, meaning there exists some set of multiple input values
> that must get mapped to the same output value. Therefore, the
> information to do an exact inverse operation based on the output is
> not present just from a pigeon hole principle argument.

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.

HTH,

-Joe
```

More information about the core-libs-dev mailing list