I think we should (1) issue a warning when Math.nan is used inside a
case and (2) make sure that switch (Math.nan) does not match any case.
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.
Switches use binary search on a sorted array. Using floating point NaN
either as a case entry or as a lookup value therefore does not work
properly. I think the current situation can lead to bugs easily, e.g.
when using case ranges with floats as in this rather artificial example:
int
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.
I think the first part was the one I am unsure about .)
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
On Thu, Jul 9, 2015 at 2:09 AM, Arne Goedeke e...@laramies.com wrote:
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?
What about the following radical proposal: Define Math.nan == Math.nan to
be
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?
What about the following radical proposal: Define Math.nan == Math.nan to
be true. It would immediately fix all the inconsistencies with container
Violating IEEE without a good reason would introduce other problems,
and I'm sure there'll be discussions around the place of exactly why
nan has to be unequal to itself. Incidentally, Python's rule about NaN
in containers isn't that it compares equal to itself, but that
container membership is
On Thu, Jul 9, 2015 at 2:37 AM, Arne Goedeke e...@laramies.com wrote:
Violating IEEE without a good reason would introduce other problems,
and I'm sure there'll be discussions around the place of exactly why
nan has to be unequal to itself. Incidentally, Python's rule about NaN
in containers
