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