John Roth wrote:
is there any simple reason why IEEE special values are so poorly
supported in python?
Like a lot of things, Python's math functions are a rather thin layer
on top of the native C library's math functions. If the C library's
math functions, to use the vernacular, suck, then Python's math
functions will do likewise.
That's what I would have expected, BUT: gcc and glibc behave perfectly well
(2.95.4) so obviously, the layer in between is rather too thick than too

p.e. log(-1.0) gives a plain "nan" in C, while python throws an exception.
One of the essential problems is that every library does certain
things differently, like deciding whether it's going to start up with
silent or signaling NaN's, or what the actual string values are for
NaN, infinity and so forth.
I do understand that string representations may be a problem here (that's
exactly what PEP 754 would address) but I don't touch strings anywhere so
far. And the behaviour for binary representations is perfectly well defined
by the IEEE standard. Maybe there are old libraries out there that don't
implement this correctly, but why let them spoil the fun to all others?
It takes developer time to clean up that situation. I suspect
that volunteers would be very welcome.
Of course - I will not debate about that. :-)


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 5 | next ›
Discussion Overview
grouppython-list @
postedAug 16, '03 at 12:16p
activeAug 16, '03 at 4:53p



site design / logo © 2022 Grokbase