On Wed, 8 Jul 2015, Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum
wrote:
I believe that the compiler should:
- Special case NaN if there's an explicit case-label with NaN.
- Map NaN to the default label (if any) otherwise.
We should definitely do the second, the current behavior is just a bug.
I am personally not sure about the second, because it would make the
switch incompatible with standard equality.
Container types have similar problems with nan. Trivial example:
> ([ Math.nan : 1 ]);
(1) Result: ([ /* 1 element */
nan: ** gone **
])
Of course, this could be fixed, too, by fixing describe_mapping.
Similar, but more subtle:
> mapping m = ([ Math.nan : 1 ]);
> equal(m, m+([]));
(1) Result: 1
> equal(m+([1:2]), m+([1:2]));
(2) Result: 0
What about arrays?
> ({ 1, 2, 3, Math.nan }) ^ ({ Math.nan });
(1) Result: ({ /* 3 elements */
1,
2,
3
})
> ({ 1, 2, 3, Math.nan }) - ({ Math.nan });
(2) Result: ({ /* 4 elements */
1,
2,
3,
nan
})
uh??
Of course all this is nothing new. Python afaik tries to treat NaN in
containers as if it compared equal to itself. Is that the best one can
do?
arne
