On Sunday, May 29, 2011 6:14:58 PM UTC-7, Chris Angelico wrote: > On Mon, May 30, 2011 at 10:55 AM, Carl Banks > wrote: > > If exceptions had commonly existed in that environment there's no chance > > they would have chosen that behavior; comparison against NaN (or any > > operation with NaN) would have signaled a floating point exception. That > > is the correct way to handle exceptional conditions. > > > > The only reason to keep NaN's current behavior is to adhere to IEEE, > > but given that Python has trailblazed a path of correcting arcane > > mathematical behavior, I definitely see an argument that Python > > should do the same for NaN, and if it were done Python would be a > > better language. > > If you're going to change behaviour, why have a floating point value > called "nan" at all?
If I were designing a new floating-point standard for hardware, I would consider getting rid of NaN. However, with the floating point standard that exists, that almost all floating point hardware mostly conforms to, there are certain bit pattern that mean NaN. Python could refuse to construct float() objects out of NaN (I doubt it would even be a major performance penalty), but there's reasons why you wouldn't, the main one being to interface with other code that does use NaN. It's better, then, to recognize the NaN bit patterns and do something reasonable when trying to operate on it. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
