[squeak-dev] a==b "true" but a=b "false"
Andres Valloud
avalloud at smalltalk.comcastbiz.net
Thu Sep 4 23:55:11 UTC 2014
On 9/4/14 16:00 , Chris Muller wrote:
> On Thu, Sep 4, 2014 at 2:39 PM, Andres Valloud
> <avalloud at smalltalk.comcastbiz.net> wrote:
>>>> A: With Float nan.
>>>>
>>>> Float nan == Float nan "true"
>>>>
>>>> Float nan = Float nan "false"
>>>>
>>>> It violates what I have long considered an invariant that if a==b, then
>>>> a=b.
>>>
>>>
>>> Yep. We might want to fix that.
>>
>>
>> I'm curious now. Where did that long considered invariant come from? I
>
> It comes from a normal sense that an object is "equivalent" to itself.
I think the underlying issue is that "equivalent" means different things
in different contexts. The poor #= message, being only one, cannot cope
with complying with multiple conflicting points of view.
> I get Eliots statement that, given all the different possible origins
> of NaN, assuming equivalency is assuming too much. But that's a
> purists view
Well, hang on, because this comes down to one of the subtle issues we
end dealing with all the time. In short: we tend to reinterpret others'
ideas to our liking. The issue is that in doing so we might develop our
own brand of IEEE-754 which is then incompatible with the IEEE-754
understanding of everyone following the standard to the letter ---
including the implementation of modern FPUs.
I'm not saying I like every single little thing in IEEE-754. However,
compliance gives me compatibility, portability, the ability to read
Knuth without having to redo his work according to my private
interpretation of IEEE-754, etc. It's a compromise: in exchange for
restraining oneself, one can take advantage of the work of others.
>> also know of a real application that defined, quite on purpose,
>>
>> SomeDomainObject>>= anObject
>>
>> ^false
>
> Well, I'm curious about the contexts. What app considered an object
> not equal to itself on purpose?
Hmmm. I only remember the details vaguely. It had something to do with
a GUI display. I also remember being shocked by what at first seemed
like a horrible hack. But, after spending a couple hours on it, I
realized that accomplishing the same desired behavior in some other way
would have been way, way more onerous. I suspect it had to do with the
issue of "equivalence" meaning different things at different times.
Maybe I'd look at it today and figure out something better. At the
time, I let that hack live.
To me, this brings back the issue that once you instantiate a class,
it's difficult to recast the identity of the instance from a different
point of view. Multiple inheritance doesn't quite work. Polymorphism
is more practical, yet somehow incomplete.
Andres.
More information about the Squeak-dev
mailing list
|