[Python-Dev] math.rint bites the dust (original) (raw)

Tim Peters tim_one@email.msn.com
Sun, 6 Aug 2000 16:54:02 -0400

[Guido]

After a brief consult with Tim, I've decided to drop math.rint() -- it's not standard C, can't be implemented in portable C, and its naive (non-IEEE-754-aware) effect can easily be had in other ways.

[Thomas Wouters]

I don't particularly disagree, since I hardly do anything with floating point numbers, but how can something both not be implementable in portable C and it's effect easily be had in other ways ?

Can't. rint is not standard C, but is standard C99, where a conforming implementation requires paying attention to all the details of the 754 fp model. It's a non 754-aware version of rint that can be easily had in other ways (e.g., you easily write a rint in Python that always rounds to nearest/even, by building on math.floor and checking the sign bit, but ignoring the possibilities of infinities, NaNs, current 754 rounding mode, and correct treatment of (at least) the 754 inexact and underflow flags -- Python gives no way to get at any of those now, neither does current C, and a correct rint from the C99 point of view has to deal with all of them).

This is a case where I'm unwilling to support a function at all before it can be supported correctly; I see no value in exposing current platforms' divergent and incorrect implementations of rint, not in the math module. Code that uses them will fail to work at all on some platforms (since rint is not in today's C, some platfroms don't have it), and change meaning over time as the other platforms move toward C99 compliance.

I also recall someone who was implementing rint() on platforms that didnt have it... Or did that idea get trashed because it wasn't portable enough ?

Bingo.

everyone's-welcome-to-right-their-own-incorrect-version-ly y'rs - tim