RaFaL Pocztarski wrote:
> I haven't got any contact with NaN before, but when Tim pointed that
> NaN!=NaN is true in IEEE I thought that it does make sense. I see pros
> and cons and it's not so ugly and non-intuitive as it can look. When
> comparing $a and $b as numbers there is no need for $a==$b!=NaN, if
> NaN!=NaN then $a==$b is ok for any values of $a and $b, it would be true
> only if $a and $b are numbers and they are equal. If NaN==NaN is true,
> then the longer $a==$b!=NaN is needed. So when comparing two scalars as
> numbers NaN!=NaN being true makes it easier. But then "until $inflation
> != NaN" would be useless as NaN!=anything is always true (NaN!=NaN, and
> NaN!=anynumber). With NaN!=NaN some other way like $x.isNaN or $x.isnum
> would be needed. Or maybe NaN evaluates to 'NaN' in string context and
> +$x eq 'NaN' (or +$x eq NaN) could be used? NaN==NaN being false is in
> fact very intuitive for me, as NaN is something without any numerical
> meaning, so numerically compared to anything doesn't make sense (as ==
> means numerical equality, not just equality). Maybe it should be undef
> instead of false?
I'm coming to this thread after nearly a week of everyone weighing in
their opinions, and fully expect to see what I'm about to type in
stated by someone else, days ago, a little further down the long list
of posts.
What if not-a-number stringifies to NaN, but numerically always compares
to false, so the conditional in the example could CLEARLY be written
while $inflation ne NaN;
--
David Nicol 816.235.1187
1,3,7-trimethylxanthine
