[squeak-dev] Re: [ANN] Number comparison, hash, NaN, Point,
and other partially ordered sets
Andreas Raab
andreas.raab at gmx.de
Wed Jan 7 04:49:22 UTC 2009
nicolas cellier wrote:
> Yes, the correct version is the one corresponding to last Installer hook
> in bugnotes.
Ah, yes, sorry I missed that. It's too sprinkled around in the notes ;-)
> isFinite is a pre-requisite that can be found at
> http://bugs.squeak.org/view.php?id=6983
>
> This is corresponding to Installer hook (Installer mantis ensureFix: 6983)
>
> Definition is very simple and answer false both for nans and infinities
> isFinite
> ^self - self = 0.0
>
> Concerning equality of infinities, I think IEEE 754 say they are equal
> Once, i did wonder why. My rationale is
> (Float infinity - Float infinity) isNan.
> Since the difference of two infinities is not defined, how can we decide
> they represent equal quantities ?
Interesting point. However, I do think that a = a should be true for all
objects including Infinity and NaN.
>> I really like the fix for Integer/Fraction/Float hash.
>>
>
> Then thank Andrew Tween for the base idea
> http://bugs.squeak.org/view.php?id=6601
Ah, interesting. I had totally missed that.
>>> http://bugs.squeak.org/view.php?id=6719
>>
>> [NaN comparisons]
[... snip ...]
> However there are other cases like these ones where it could serve:
>
> (1/2) < #(0 1 2). "#(false true true)"
> (1/2) > #(0 1 2). "Array does not understand <"
>
> (1/2) < '1'. "true"
> (1/2) > '1'. "Error: Instances of Fraction are not indexable"
>
> I agree, these are not beautiful examples, some functionalities that
> might better take there way out of the image.
>
> Notice that:
> 3 > '2' and: [3.0 > '2']. "true"
>
> Why not define in Fraction what already is in Integer and Float?
No reason. I wasn't aware that your changes addressed both situations. I
was only concerned that addressing the NaN issues would lead to a
proliferation of Magnitude subclasses having to implement all of the
comparison operations instead of just a limited subset.
>> 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
>
> Gasp, I thought I could retrieve an official reference...
> successor ISO/IEC 10967-2 is not very verbose about that
> http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps
>
> But you can read page 8 of Kahan's
> http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
> (via http://en.wikipedia.org/wiki/IEEE_754-1985)
>
> Anyway, this is implemented by all libraries I know of:
One idle thought I had today was whether one couldn't entirely get rid
of float-valued NaNs and instead introduce a well-known NaN instance
that *isn't* an instance of Float and consequently also isn't a Number,
doesn't do any arithmetic etc. etc. etc.
It would be fairly simple to change the VM to have a well-known NaN slot
in the specialObjectsArray so that when a primitive attempts to return a
float-valued NaN via pushFloat: the VM instead pushes that NaN object.
This would fix 99% of all places that could ever return a float-valued
NaN, including things like ByteArray>>doubleAt:, or the FFI etc.
What I have personally no clue about is whether anyone ever uses
float-valued NaNs for anything useful. I have never done that but there
may be people who have and it would be interesting to see whether they
have any insight into the use of a non-float NaN instance.
>>> 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?
>>
>
> No, I have absolutely no guaranty.
Sure. I'm just asking for anecdotal evidence in your day-to-day images.
Are you actively using these changes?
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|