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
