On Fri, 26 Mar 2010 15:01:46 +1300 Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The more I think about it, the more I think that the only reason for needing NaNs in the first place is if you don't have, or don't want to use, an exception mechanism.
As Meyer points out, treating NaN == NaN as false is not fundamentally any more correct than treating it as true. One interpretation or the other might be appropriate in a particular algorithm, but this needs to be considered on a case-by-case basis.
[In a language or a given case where yielding a NaN does not raise an exception from scratch.] It seems to me there are various comparison cases (esp. in an OO language, case 2): -1- Comparing (any) Nan to non_NaN should return False. a = <expr yielding a NaN> b = 1 a == b # ==> False -2- Comparing a given NaN with itself should return True. a = <expr yielding a NaN> b = a a == b # ==> True -3- Comparing various NaNs is the undefined case. Actually, I think it's the only case where a theoretical NaB makes sense. In my opinion, as Greg says, the python way would here be raising an exception. But only in that case. Denis ________________________________ vit esse estrany ☣ spir.wikidot.com