[Patches] introducing math.rint

[Guido van Rossum]

> [Guido, about rint]
> > Not to worry, I've already added the necessary magic to the configure
> > script.
> 
> Are you sure you want to?  While I expect that the existence of some
> functions in the OS module depends on the platform, I'm really dubious about
> extending that to other modules, and it's especially dubious in a module
> like math.  I learned today that Windows doesn't support "rint" either --
> this is a function that apparently exists (at least under that name) only on
> some unknown subset of Unix derivatives.

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.)

Also, how hard would it be to provide a reasonable approximation on
platforms that don't have it?  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?

> > (PS Tim, did you get a chance to look at the second installment of the
> > cmarh.acosh/asinh patches?)
> 
> No, it's way back in my inbox, and I don't expect to get to it this month.
> However, if I had the hours it would take to look at this carefully, I would
> probably conclude that all the complex transcendentals suffer deep numeric
> problems (the ones I looked at so far are certainly fragile as eggshells!).
> On that basis, if the new patch isn't obviously broken, it's probably no
> worse than what it's replacing, and at least one motivated user thinks it's
> a lot better <0.5 wink>.

Sigh.  I'll see what I can do.

--Guido van Rossum (home page: http://www.python.org/~guido/)