[squeak-dev] Re: [ANN] Number comparison, hash, NaN, Point,
and other partially ordered sets
ncellier at ifrance.com
Wed Jan 7 22:25:34 UTC 2009
Andreas Raab a écrit :
> nicolas cellier wrote:
>>> [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 <= self
^(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.
>>> [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...
> - Andreas
More information about the Squeak-dev