why () is () and [] is [] work in other way?

[Ian Kelly]

On Fri, Apr 27, 2012 at 9:39 AM, Adam Skutt <askutt at gmail.com> wrote:
> On Apr 27, 8:07 am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>> Useful... maybe, conceptually sound... no.
>> Conceptually, NaN is the class of all elements which are not numbers,
>> therefore NaN = NaN.
>
> NaN isn't really the class of all elements which aren't numbers.  NaN
> is the result of a few specific IEEE 754 operations that cannot be
> computed, like 0/0, and for which there's no other reasonable
> substitute (e.g., infinity) for practical applications .
>
> In the real world, if we were doing the math with pen and paper, we'd
> stop as soon as we hit such an error. Equality is simply not defined
> for the operations that can produce NaN, because we don't know to
> perform those computations.  So no, it doesn't conceptually follow
> that NaN = NaN, what conceptually follows is the operation is
> undefined because NaN causes a halt.
>
> This is what programming languages ought to do if NaN is compared to
> anything other than a (floating-point) number: disallow the operation
> in the first place or toss an exception.  Any code that tries such an
> operation has a logic error and must be fixed.

NaNs do not signify errors (for instance, a NaN could result simply
from subtracting one Inf from another), and they do not necessarily
imply that the calculation should halt.  They are propagating values
indicating the lack of a concrete value, and frequently they can
reasonably be ignored.  If you need to know about a NaN immediately,
then you can trap them with fpectl.  If you don't, then you let it
propagate and check for it at the end of the calculation.  If instead
they raised exceptions by default, then we would need to wrap
virtually every floating point operation in a try-except, which would
quickly become a mess.  See also:

http://grouper.ieee.org/groups/754/faq.html#exceptions