Re: [Stds-754] nextafter touch-up

[David Hough 754R work <754r@xxxxxxxxxxx>]

> the least p-precision number (with unlimited range)

That sort of thinking, referring to a hypothetical format with fixed
precision and unbounded range,  
has confused everybody dealing with 754 underflow-after-round
for almost 30 years.    I don't see the point of propagating it.

The exceptional behavior of nextafter is just a mistake, based on a
mistaken presumption that checking a flag was a cheap operation.
As our other current discussion thread indicates, checking a flag is just
about the most expensive operation there is.

That's why I moved to remove nextafter last month.

The only interesting question (in my mind) is whether nextup/nextdown
should signal on signaling NaNs.   If they don't, then they can be
implemented in the integer unit, if desired, with no harm done because
(as also pointed out today) negate, abs, and copysign are defined in a
way that severely inhibits the portable usefulness of signaling NaNs.

If they were redefined to signal on signaling NaNs, the nextup/nextdown
should as well, of course.

Perhaps there should be a STATIC mode enabling signaling NaNs on all 
operations with floating-point operands.    That was the point of the
trapping NaN proposal a couple of years ago.

As it is, signaling NaNs are just an embarrassing artifact retained mostly for
compatibility.    They do retain some useful debugging capability, but not
in any portable way, and not enough to outweigh the pain they inflict on
conscientious implementers of software that might have signaling NaN inputs.

We have been over this ground every year for six years, so I don't expect
a different resolution now.    Maybe in the next revision in thirty years.