Fw: Question about JEP 306.

[joe darcy]

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