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