[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<wink>-ly
y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4