Jim, I think there are a couple of points here. 1) How should this be clearly specified? I prefer a specific table, such as the attached. 2) What specific values/exceptions are relevant. I have no great preference, but prefer clarity. DVJ -----Original Message----- From: stds-754-bounces@xxxxxxxxxxxx [mailto:stds-754-bounces@xxxxxxxxxxxx] On Behalf Of Jim Thomas Sent: Thursday, June 29, 2006 11:13 AM To: stds-754@xxxxxxxx; stds-754@xxxxxxxxxxx Subject: [Stds-754] nextafter touch-up I'm seeking feedback on the following proposal (not yet a motion). Currently, overflow, underflow, and inexact exceptions for nextafter are specified directly, rather than, like for other standard operations, as natural consequences of rounding. This approach requires awkward special treatment in several places in the draft. Ordinarily, nextafter(x,y) produces the next floating-point number with the precision of x. As with other operations, ordinary expectations can not be met if exponent range is exceeded and hence an overflow or underflow signal is appropriate. The following modifies the definition of nextafter so that its exceptions are natural consequences of limited exponent range, like other operations: Replace the last bullet in the definition for nextafter with: If x < y, then nextafter(x, y) is the least p-precision number (with unlimited range) greater than x, rounded up (to the result format), where p is the precision of x. If x > y, then nextafter(x, y) is the greatest p-precision number less than x, rounded down, where p is the precision of x. Then the exceptions for nextafter are a natural consequence of rounding, as with other FP operations -- almost. The awkward case is nextafter(max-subnormal, anything-larger). The next p-precision number is less than 2^emin, so with the new definition, underflow will be signaled. With the current definition it would not because the final (in-format) result is 2^emin, not strictly between +/-2^emin. For users, whether or not underflow is signaled in this case doesn't seem any more important than the distinction between between before and after rounding, i.e. not at all (except for test programs). This might could be a benign enough incompatibility with 754. Or, we could allow, but deprecate, not signaling underflow in the awkward case. _______________________________________________ Stds-754 mailing list Stds-754@xxxxxxxxxxxx http://mailman.oakapple.net/mailman/listinfo/stds-754
Attachment:
NextAfter2006Jun22.pdf
Description: NextAfter2006Jun22.pdf