Did you consider a message such as magmaEquals:, implemented in terms of 
the usual equality test for most objects except for Float?

On 9/4/14 18:00 , Chris Muller wrote:
> On Thu, Sep 4, 2014 at 7:33 PM, Andres Valloud
> <avalloud at smalltalk.comcastbiz.net> wrote:
>> On 9/4/14 16:00 , Chris Muller wrote:
>>>
>>> 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; I think NaN, more generically, means, "could not be
>>> calculated", and therefore, in terms of the vision any given system
>>> has on a model, it's practical to TREAT the stuff outside its scope
>>> equivalently.
>>
>>
>> All of a sudden I think I misunderstood what you meant.  Are you saying it
>> would be practical to treat all NaNs as equivalent, at least from a
>> pragmatic point of view?
>
> I think so.  I know in pure science domains, we can't regard
> incalculables as equivalent.  But when limited to strictly the bounds
> of a particular model, a software might simply want to "treat" all
> incalculables the same.  We have explicit isNaN checking which is
> probably sufficient for most cases, but for a few "general
> object-level" cases like my commit-conflict check (on any type of
> object), the isNan check is easy to miss and makes the code slightly
> less elegant.
>