[squeak-dev] Re: [ANN] Number comparison, hash, NaN, Point, and other partially ordered sets

Andreas Raab andreas.raab at gmx.de
Tue Jan 6 05:54:52 UTC 2009

nicolas cellier wrote:
> I think I now have an acceptable and consistent solution.
> This is spreaded across several mantis bug reports:

Wow. This is quite a bit of work. Here are some comments:

> http://bugs.squeak.org/view.php?id=3374

[transitive equality of arithmetic comparison]

I'm a little confused here which version is the "correct" patch. I'm 
assuming it's the M3374-xxx versions of the files - if not, please let 
me know.

I generally like the solution proposed for comparisons here but the 
coercion methods itself look a little odd: First, they appear to rely on 
a method #isFinite which is not defined anywhere and second -assuming 
that isFinite returns false for well-defined infinities like IEEE 754- I 
am not sure why two infinities should not compare equal. I don't have my 
IEEE 754 spec handy but at least for Float I think that is well defined. 
Can you explain your reasoning here a little more?

I really like the fix for Integer/Fraction/Float hash.

> http://bugs.squeak.org/view.php?id=6719

[NaN comparisons]

This one I don't like quite as much. How about a much simpler version 
along the lines of:

Magnitude <= aMagnitude
	"Answer whether the receiver is less than or equal to the argument."

	^(self > aMagnitude or:[aMagnitude isNaN]) not

Etc. This should work just as well and requires only changes in 
Magnitude instead of polluting too many subclasses (may require 
promoting isNaN to Magnitude).

Also, out of curiosity, what's your take on the IEEE 754 requirement 
that NaN compares not equal to itself? This breaks fundamental 
relationships (for example you can't use NaN in Sets or Dicts) and my 
feeling has always been that it would be more useful if:
* there was a bit-fiddling test for Float>>isNaN
* NaNs would compare equal to itself (though not necessarily to NaNs 
with different bit-patterns)
* Standard float prims would *never* return NaN but rather fail
The last one proved tremendously helpful in Croquet where I've been 
using fdlibm and simply fail any float prims that would produce NaNs. 
The image can then take care of it properly.

> http://bugs.squeak.org/view.php?id=7259

[point-number comparisons]

This is an elegant solution (nice use of adaptTo:andCompare:) but I'm 
not sure how much code will break with it. Have you tried running this 
for a while in daily use?

> http://bugs.squeak.org/view.php?id=7260

[float prim behavior with NaN]

I'm with you on this one. The primitives are very, very badly broken at 
this point and I'm really surprised this has escaped us for so long.

All in all, this is great stuff!

   - Andreas

More information about the Squeak-dev mailing list