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

[Kiuhnm]

On 4/27/2012 17:39, Adam Skutt 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.

Mathematics is more than arithmetics with real numbers. We can use FP 
too (we actually do that!). We can say that NaN = NaN but that's just an 
exception we're willing to make. We shouldn't say that the equivalence 
relation rules shouldn't be followed just because *sometimes* we break them.

> 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.
>
> However, when comparing NaN against floating point numbers, I don't
> see why NaN == NaN returning false is any less conceptually correct
> than any other possible result.  NaN's very existence implicitly
> declares that we're now making up the rules as we go along, so we
> might as well pick the simplest set of functional rules.
>
> Plus, floating point numbers violate our expectations of equality
> anyway, frequently in  surprising ways.  0.1 + 0.1 + 0.1 == 0.3 is
> true with pen and paper, but likely false on your computer.

Maybe wrong expectations of equality, since 0.1 (the real number) is 
/not/ a floating point.
Don't confuse the representation of floating points with the floating 
point themselves.

>  It's even
> potentially possible to compare two floating point variables twice and
> get different results each time[1]!

We should look at the specification and not the single implementations.

>  As such, we'd have this problem
> with defining equality even if NaN didn't exist.  We must treat
> floating-point numbers as a special case in order to write useful
> working programs.  This includes defining equality in a way that's
> different from what works for nearly every other data type.
>
> Adam
>
> [1] Due to register spilling causing intermediate rounding.  This
> could happen with the x87 FPU since the registers were 80-bits wide
> but values were stored in RAM as 64-bits.  This behavior is less
> common now, but hardly impossible.

Kiuhnm