[squeak-dev] Re: [ANN] Number comparison, hash, NaN, Point,
and other partially ordered sets
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:
[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
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.
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.
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?
[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!
More information about the Squeak-dev