Dear fellow GNUsteppers, I have another problem. :-D This time, it is NSNumberFormatter's tendency to compare with NaN.
In [NSNumberFormatter-attributedStringForObjectValue:withDefaultAttributes:], the message [anObject isEqual:nanNumber] is issued. In my code, anObject is an NSSignedIntegerNumber, while nanNumber is by design an NSDecimalNumber. [NSNumber-isEqual:] calls [NSNumber-isEqualToNumber:], which calls [NSSignedIntegerNumber-compare:]. Case 'd' is taken, the double values (99.0 and NaN) are obtained, and the two values are compared using the macro COMPARE. Is 99.0 less than NaN? No. Is 99.0 greater than NaN? No. The macro decides that 99.0 orders the same as NaN, and the callers conclude that 99.0 equals NaN. Thus, even for such a beautiful number such as 99, the NSNumberFormatter returns "NaN". My limited experimenting shows that Apple (OS X 10.6.6, Foundation 751.42.0) orders NaNs below any numeric value. Do we wish to follow suit? (Further experiments, especially with +inf and -inf, are welcome; I'm too sleepy to continue experimenting right now.) I hope this is not a compiler or configuration but a code bug. ;-) Cheers, ~~ Ondra _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
