On Tue, 08 Jul 2014 16:53:47 +0200, Anders J. Munch wrote:
> Most people don't need to deal with NaN's in Python at all, fortunately.
> They just don't appear in normal computation, because the interpreter
> raises an exception instead.
>
> It happens in my work I come across them quite a lot. I'm writing
> software that talks to embedded applications that can contain NaN values
> for a variety of reasons - never-initialised storage, initialise-to-NaN,
> hardware failures etc.
>
> So when my software reads these values in binary, unpack them using the
> struct module, and goes to work. And NaN's are no different from any
> other value, it's something to store, compare, display etc.
>
> And that worked fine in my Python 2.4 apps.
I think you're smoking something funny :-)
[steve@ando ~]$ python2.4
Python 2.4.3 (#1, Jan 9 2013, 06:49:54)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
py> NAN = float('NAN')
py> NAN == NAN
False
NANs compared unequal in Python 2.4.
[...]
> Now, all this bothers me. Not that I had to do some work to get stuff
> to work in an imperfect world. No, what bothers me is that this
> behaviour was explicitly and deliberately put in for no good reason.
Oh, you've read the IEEE-754 standard, and that's what it says? "We're
going to specify this behaviour for NANs just to annoy people" perhaps?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
