[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