in reply to NaNs are true

There are several Perl-like languages that decided that string '0' should be "true". While I understand the temptation to only have one string that is "false", my experience is that this choice was a mistake (in each case) -- I have seen repeated cases of bugs due to "as a string" vs "as a number" causing opposite behavior. It would be an even bigger mistake in Perl where the transformation between strings and numbers is even more implicit.

Since you will never make the string "NaN" (or the other stringifications of NaNs) "false", I believe it would be a mistake to make a (non-string) NaN "false" in Perl.

I also disagree that a NaN should be "false" even ignoring the stringification problem. For numbers, 0 is false. NaN is very much not zero. I assume you aren't making any of the "Inf"s "false". A NaN is more like an Inf than like a zero, so I find it unnatural to draw the circle of "is false" around such different things as zeros and NaNs while having it separate NaNs from Infs.

I appreciate that a NaN is similar to undef. However, an undef becomes a zero whenever you treat it like a number and there are even ways for an undef to silently become a zero ($undefined++). So undef is much more like zero than a NaN is like zero.

So I think it is very natural for undef to be "false". And I find it natural in Perl for "uninitialized" to be "false".

So I need to address the case of an "uninitialized number". I can appreciate the value in having an uninitialized number being a NaN. And I can see the expectation that "uninitialized" would be "false" (though a bit less strongly for a strictly numeric data type since, when I test a number for "truth", I usually think of it as short-hand for comparing a number to 0). But I would be very bothered by doing a calculation like $x/$y and ending up with an "uninitialized" value, or even a false value.

So I'd probably have an uninitialized number be a special undef type of NaN, a value that could never be generated from a calculation and that stringifies to an empty string (with a warning). I very much would not have a non-zero result of a calculation be "false" (especially when it stringifies to a "true" value).

- tye        

Replies are listed 'Best First'.
Re^2: NaNs are true (!"NaN")
by syphilis (Archbishop) on Feb 27, 2011 at 11:10 UTC
    NaN is very much not zero

    More than that - in the world of numbers, NaN is very much not anything ... and I can't think of anything falser than "not anything".

    I assume you aren't making any of the "Inf"s "false"

    That's correct - an Inf is just like any other non-zero number, except bigger. No doubt in my mind that Inf should be true.

    when I test a number for "truth", I usually think of it as short-hand for comparing a number to 0

    You're probably not the only one who does that - yet I've created a situation where that's not what "truth" is testing.
    That provides an opportunity for confusion and misunderstanding to arise, which is definitely not such a good thing.

    Cheers,
    Rob
[reply]
Re^2: NaNs are true (NaN == 0 -> true? Really?)
by BrowserUk (Patriarch) on Feb 27, 2011 at 07:48 UTC

    That's all very logical, except that at the end you seem to have arrived at the situation where you would have an implicit test of a NaN against zero be true?

    NaN == 0 -> true cannot be right.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      What about idea that NaN never matches numerical comparison?
      NaN == 0 #false
NaN != 0 #false
NaN == NaN #false
NaN != NaN #false

      [download]
[reply]
[d/l]

        I think all of those are correct, though not particularly useful. They should also prompt (at least) a warning, though I think a catchable exception is better.

        You also have to be careful to distinguish between a variable containing NaN, and a constant NaN I think.

        That is, I think the only time any comparison involving a variable containg NaN should result in a true value, is if it is compared against a predefined constant NaN; were one to be provided. Though an isNaN( $x ) function or equivalenly $x->isNan() method would serve the same purpose and be less likely to confuse.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom