[Patches] introducing math.rint

[Tim Peters]

[Guido]
> Peter clearly wants to use rint().  It exists on his platform.  Why
> should we deny it to him?  (I added a note to the documentation that
> it's not available on all platforms.)

The argument against is that it makes writing portable code that much
harder; portability in this sense is something a math module user never has
to worry about today.  "Slippery slope" applies here too:  there are dozens
and dozens of platform-specific functions that could just as well be added
to the math module.   For example, I *definitely* want to use _chgsign,
_controlfp, _copysign, _finite, _fpclass, _isnan and _nextafter, most of
which are recommend by 754 too and all of which are supported directly on
*my* platform (that's Windows, today <wink>).  Should Python grow all of
those too?  If yes to rint, why no to any other random platform function?

> Also, how hard would it be to provide a reasonable approximation on
> platforms that don't have it?

I've already posted (Python) code to do that to c.l.py, where Peter started
a rint thread.  Fredrik has too.  Unfortunately, I know of no way to write
/F's clever code in C that will generate correct code under all common
compilers ("extended precision" will kill it on Intel chips, and overly
aggressive optimization on others).

> Assuming the default rounding settings, it seems to round to the
> nearest integer where if you're exactly halfway it rounds to the
> nearest *even* integer.  I know we can't know the actual IEEE754
> rounding mode, but as Python does not provide access to it, it's
> likely that it's the default mode, right?

Extremely likely.  It's easy to figure out regardless (just add a few things
and look at the result), but, meaning no offense to Peter, he doesn't appear
to be aware of any of the subtleties actually embodied by his platform rint.
If you force nearest/even, it does not match the platform rint.  If you
don't force it, it's harder to write, and makes less sense in *Python*
because Python provides no means to set rounding mode.  The rint I
implemented at KSR supported an optional second argument, to specify which
of the six behaviors you wanted (i.e., to minus infinity, to plus infinity,
to zero, to nearest/even, the non-754 "add a half and chop", or follow the
current 754 rounding-mode setting); but this was easy to implement there
because the *hardware* supported all six directly!

BTW, I'm having a hard time understanding why you're eager to jump into
brand new pits when 1.6 is already behind schedule <wink/frown>.