A few questions/comments about floating-point.

[Tim Peters]

Just noting some subtleties:

> Example #3:
>
> Given a type `double' variable `d', the results of evaluating:
>
> 		(d >= 0.0) ? d : -d
>
> may differ from the results of evaluating:
>
> 		fabs (d)
>
> [because when d is sNaN the former signals invalid but the latter often
> doesn't]
> ...
> [if fabs were required to signal invalid operation on sNaN inputs]
> there would be no notable semantic distinction between these two
> expressions, and thus the optimization would always be permissible.

It's clearly in the IEEE spirit for fabs(sNaN) to gripe, and I agree it
wouldn't hurt to spell that out.  In my experience, IEEE details left
unspecified because "they're obvious" create no end of problems, because
to most people involved in software integration, testing, documentation,
management, maintenance (& so on), absolutely nothing about floating
point is "obvious".  Nevertheless, they're inclined to argue <grin>.

A subtler problem in your example occurs when d is a quiet NaN:  ">="
maps to a predicate that's supposed to signal invalid operation given a
qNaN comparand, while fabs(qNaN) clearly shouldn't gripe.

A still subtler problem is that the results also differ when d is -0:  the
1st expression returns -0, while (one hopes that!) fabs(-0) returns +0.

There's a fourth potential problem when the invalid trap is disabled and
d is a NaN (whether signaling or quiet):  The IEEE stds guarantee almost
nothing about the bit patterns in NaNs as they move through operations,
so there's no reason to believe that the bit pattern returned for -NaN
("NaN >= 0.0" is false, so the "-d" clause applies in the 1st expression)
will be the same as that returned by fabs(NaN).


Despite these differences between the C idiom and a "real" IEEE fabs,
when our compiler sees a "fabs-like" conditional expression, it optimizes
it into our fabs hardware instruction (which, yes, signals invalid on
sNaN but not on qNaN, and maps both +0 and -0 to +0).  It would be a nice
change of pace if _some_ standard blessed this bit of common sense <ahem>.

can't-win-ly y'rs  - tim

Tim Peters   timaksr.com
not speaking for Kendall Square Research Corp