[Cfp-interest 1920] "numerically equal" and "numerically equivalent"
David Hough CFP
pcfp at oakapple.net
Mon Feb 15 17:43:28 PST 2021
I had an action item:
Look into 'numerically equivalent' vs 'numerically equal' usage
in the C standard and revisit CFP 1849.
I looked in n2596.pdf of Dec 11 and compared to C18.
Searching for "numerically eq" turned up surprisingly few matches:
F.9 Optimization
F9.2 Expression Transformations
Valid expression transformations must preserve numerical values.
The equivalences noted below apply to expressions of standard floating types.
x/2 <-> x * 0.5 page 449 (also in C18)
Although similar transformations involving inexact constants generally do not
yield numerically equivalent expressions, if the constants are exact then such
transformations can be made on IEC 60559 machines and others that round
perfectly.
page 450 (added since C18)
EXAMPLE 1. * x -> x is valid for decimal floating-point expressions x,
but 1.0 * x -> x is not:
1. ? 12.34 = (+1, 1, 0) ? (+1, 1234,?2) = (+1, 1234,?2) = 12.34
1.0 ? 12.34 = (+1, 10,?1) ? (+1, 1234,?2) = (+1, 12340,?3) = 12.340
The results are numerically equal, but have different quantum exponents,
hence have different values.
F9.3 Relational operators page 450 (also in C18)
x < y -> isless(x,y)
Though numerically equal, these expressions are
not equivalent because of side effects when x or y is a NaN and the state
of the FENV_ACCESS pragma is "on".
This transformation, which would be
desirable if extra code were required to cause the "invalid" floating-point
exception for unordered cases, could be performed provided the state of the
FENV_ACCESS pragma is "off".
=====
"Equivalent" seems to mean that expressions may be used interchangably by
optimizers.
"Numerically equivalent" and "numerically equal" are not defined, but I
guess the intent is
"Numerically equivalent" is the same as "equivalent" - same results, same
side effects, in all cases under all environments.
"Numerically equal" just means the same real number value, but quantum
exponents or side effects might differ, so they can't be used
interchangeably in all cases under all environments.
=====
[Cfp-interest 1849] Re: hypot(SNAN,+0)
Fred:
> On Oct 28, 2020, at 9:16 AM, Fred J. Tydeman <tydeman at tybor.com> =
wrote:
>=20
> C23 F.10.4.4 has
> hypot(x, =C2=B10) is equivalent to fabs(x).
>=20
> Is that true for x being a Signaling NaN?
Jim:
No. We could say
hypot(x, +-0) is equivalent to fabs(x), for all x not a signaling NaN.
But, either way, this seems to require hypot(x, +-0) to be a
sign bit operation, which we don't want for multiple reasons
(treatment of NaNs, preferred quantum exponent, canonicalization).
754 says
hypot(x, y) is even in both operands.
...
For the hypot operation, hypot(+-0, +-0) is +0,
hypot(+-inf, qNaN) is +inf, and hypot(qNaN, +-inf) is +inf.
Draft C23 F.10.4.4 says=20
--- hypot(x, y), hypot(y, x), and hypot(x, -y) are equivalent.
--- hypot(x, +-0) is equivalent to fabs(x).
--- hypot(+-inf, y) returns +inf, even if y is a NaN.
The equivalence to fabs guarantees the 754 requirement about zeros and
also requires correct rounding for y (or x) = +-0. We could
replace the bullet about fabs with the two bullets
--- hypot(+-0, +-0) is +0.
--- hypot(x, +-0) is numerically equivalent to fabs(x).
=====
Hough:
I'm not sure about the bullet
--- hypot(x, +-0) is numerically equivalent to fabs(x).
when x is a signaling NaN. hypot expects a signal but fabs does not.
I would rather avoid "numerically equivalent" unless we are willing to
define it, and also avoid reference to fabs which is likely to be
implemented in an inherently different way.
In an extreme example, the orginal SPARCstation had Weitek fpus and
a Fujitsu gate array to hold the FP registers and control logic.
If I remember correctly, fp move, negate, and abs were implemented in the
control logic in one cycle as bit ops and thus were faster than real FP ops.
Later SPARCs with integrated floating point handled those ops in the
FP pipeline.
But if the point is
--- hypot(x, +-0) is the absolute value of x when x is a number.
maybe we should just say that.
More information about the Cfp-interest
mailing list