in reply to Re: NaNs are true
in thread NaNs are true

The NaN, being an NV, is being evaluated in numeric context, not "string" context. And the string "foo", when evaluated in numeric context, will be false (0).
I don't think there's any inconsistency there ... except perhaps that "foo", when evaluated in numeric context should really be NaN, not 0 ;-)

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: NaNs are true
by ikegami (Patriarch) on Feb 28, 2011 at 06:07 UTC

    "The Unicode Bug" is what happens when you have values whose meaning change based on how they are stored.

    False is "", "0" and what stringifies to these. For NaN to be false, it would have to stringify to one of these, or "NaN" would have to be false too.

[reply]
Re^3: NaNs are true
by jdporter (Paladin) on Feb 28, 2011 at 03:15 UTC

    I never said anything about string context. And I thought it was pretty well understood we were talking about boolean context anyway, since you're going on about whether things evaluate to true or false.

    "foo" in boolean context is true, not false. And that was my point: "foo", being "not a number", is true; and so NaN, being "not a number", ought to be true as well (if one follows this line of reasoning). So, yes, there is no inconsistency, if one buys this logic. In which case — what are you complaining about?

    Update: Argh. I meant inconsistency. Corrected. :-P

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
[reply]
[d/l]
[select]
      what are you complaining about?

      Nothing, no complaints at all ... mainly just trying to fathom whether the Math::MPFR object returned by "Math::MPFR->new()" (whose value is NaN) should be true or false.

      The object returned by "Math::MPFR->new(0)" is false because its value is 0, and it seems anomalous to me that "Math::MPFR->new()" should be deemed true even though it has been assigned no value at all.
      I could rewrite the module so that "Math::MPFR->new()" returns an object whose value is zero (or some other randomly chosen number), but that would be deviating from the way the mpfr C library behaves.

      Sorry - must've misunderstood your point. (I'm pretty thick.)

      A post to the mpfr mailing list returned the info that when both ECMAScript and XPath convert a number to the boolean type, "the result is false if the argument is +0, -0, or NaN; otherwise the result is true."
      Hardly compelling stuff, but at least it makes me feel a bit less like a fucking freak.

      Anyway, I'll just leave Math::MPFR as is for now - ie Math::MPFR objects whose values are 0, -0 or NaN are false, all other Math::MPFR objects are true . No-one has yet complained about it, and I don't anticipate that anyone ever will.
      Many thanks to all respondents (including you) ... many interesting approaches and views.

      Cheers,
      Rob
[reply]

        What happens if you add NaN to zero? i.e. 

        if ( 0 + $MPFR_NaN_obj )

        [download]
        I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
[reply]
[d/l]

        and it seems anomalous to me that "Math::MPFR->new()" should be deemed true even though it has been assigned no value at all.

        Correct, which is why uninitialised needs to be distinct from NaN. The former is false, the latter is true.

[reply]

In Section Seekers of Perl Wisdom