Damian Conway <[EMAIL PROTECTED]> writes:
>
> > But I assume that == means numerically equal (and here I could be
>
> > wrong). If what I assume is true however, then anything which
> doesn't
>
> > have any numerical meaning, numerically compared to anything
> (even to
>
> > itself) should not return the misleading result that the two
> compared
>
> > values are numerically equal.
> >
> > Then again, if you tell me that == operator doesn't mean
> "numerically
>
> > equal", I will agree that NaN==NaN should be true even
> considering that
>
> > 'cat'=='dog' will also be true.
>
> But 'cat'=='dog' *is* true. Numerically, they *are* equal.
> They are equally not numbers. One should certainly get a warning
> (and one will if warnings are enabled), but this
> expression shouldn't return false.
>
> Sigh. I *do* see your point of view (Laziness), but I still have
> immense
>
> difficulty with the notion that:
>
> $x == NaN
>
> doesn't return true if $x contains NaN.
But there are going to be problems in some cases if we change the
behaviour of NaN to the perl semantics. There are cases where the IEEE
behaviour is *useful* dammit.
The problem here is that you can't simply do:
...
until $inflation;
Because 0 isn't true.
Hmmm... just had a thought. How does this sound:
+'non_numeric_string' becomes 'NaN is undefined'
sqrt(-1) becomes 'NaN is defined'
Then, if you're doing loop control you'd do
...
until defined(+$inflation)
And when you're doing numeric calculation type stuff you get the
useful IEEE behaviour.
Why do I have the horrible feeling that *nobody* is going to like this
proposal...
