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

nicolas cellier ncellier at ifrance.com
Wed Jan 7 22:25:34 UTC 2009


Andreas Raab a écrit :
> nicolas cellier wrote:
>>>> 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.
> 

I redefine only one message in Magnitude
 >= aMagnitude
	^aMagnitude <= self

instead of:
 >= aMagnitude
	^(self < aMagnitude) not

This is absolutely not necessary and can be skipped.

What I had in mind was that it would be sufficient to define only < in 
subclass in case of total order, and only < and <= in case of partial order.
That would work with Nan, but that's not true with Array for example...
Argument class also has to agree on the reverse relation.

> 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.
> 

Mostly agree but:
1) I would prefer a behaviour controlled at image level
    Read more in my response to Paolo.
2) We cannot just ignore outside world.
    I think Eliot, Paolo, John did answer enough about it.


>>>> 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?
> 

No, it is in my personal images, but
1) I don't use squeak intensively (not professionally).
2) The changes are far too young.
Some volunteers have to help...

> Cheers,
>   - Andreas
> 
> 




More information about the Squeak-dev mailing list