nextafter

[Tim Peters]

Just a note to suggest that this problem may look very different
depending on whether you're interested in primitives that are

1) easy for hardware to implement

or

2) good candidates for standardization in languages (implying they
   should "make sense" and be efficiently implementable across a wide
   range of arithmetics)

or

3) convenient as language primitives portable only among platforms
   supporting a specific arithmetic

I think these concerns are confused in the msgs on this topic so far.
Good examples of #3 are the "recommended" functions in IEEE-754/854;
good examples of #2 are the numeric inquiry & manipulation functions in
Fortran 90 (although dgh may not agree with that, although I'm not sure
he's seen their most recent definitions).

>  [bob a]
>  At Tera, we agree that nextafter(x, y) is too much to put in one hardware
>  instruction.

I.e., it's not good a candidate for class #1 above, although it may be
for #3 (which I agree with, and which I think dgh said earlier too).

>  However, we are thinking about computing "ulp(x, y)" such
>  that
>
>  	nextafter(x, y) = ulp(x, y) + x
>
>  I think this scheme works for all cases except nextafter(infinity, y)
>  where y < infinity.

As a #1+#3 candidate this looks good, but not sure it works for #2.
E.g., if you don't have denorms, ulp(0,y) is a pain to get too.

>  Is it important that nextafter(inf, 0) give maxfloat?

Surely you jest:  the whole philosophy of 754 is that every stinking
detail is vital <grin>.  Seriously, lots of existing IEEE code already
depends on nextafter(inf,0) == maxfloat ...

>  Another possibility is "nextdir(x, d)" such that
>
>  	nextafter(x, y) = nextdir(x, x-y).
>
>  Here, all kinds of badness can happen when computing x-y (including
>  underflow, overflow, invalid op, inexact) even when the end result is
>  not exceptional.

But nextdir(x,d) is still a good candidate for class #2.  E.g., F90
spells your "nextdir" as the generic NEAREST(X,D).  And since *most*
invocations of nextafter I've seen actually use "+inf" or "-inf" as
their second argument, nextdir/NEAREST(x,1.) and nextdir/NEAREST(x,-1.)
would actually be full replacements for most uses of nextafter I've
seen.

>  [cleve m]
>  For the kinds of things we've done with LINPACK and EISPACK and MATLAB,
>  all we really need is:
>
>      ulp(x) = nextafter(x,inf) - x

ulp(x) === SPACING(X) in F90.

>      maxfloat = largest floating point number

HUGE(X) in F90 (HUGE is generic, so X is used just to establish the
type; a reasonable implementation will of course treat a reference as a
compile-time constant).

>      minfloat = smallest positive normalized floating point number

TINY(X) in F90 (see comment about HUGE above).

>  ...
>  Today, we don't put such things in data statements anymore, but I'm
>  afraid we still haven't agreed where they should be put.

There's an awful lot about F90 I dislike intensely, but their use of
generic intrinsics for these purposes is (I think) well thought-out.
It's a shame that ANSI C seems to forbid a clean implementation of
generics, because I think even this group <grin> *could* agree on a nice
set of functions for class #2 ...

fat-lot-of-good-it-does-if-you-have-to-remember-umpteen-different-
   names-for-'em-though-ly y'rs  - tim