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.