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

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.

Replies are listed 'Best First'.
Re^4: NaNs are true
by syphilis (Archbishop) on Feb 28, 2011 at 05:45 UTC
    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]
        What happens if you add NaN to zero?

        The usual rules apply. NaN+0 equals Nan, so ( 0 + $MPFR_NaN_obj ) returns a Math::MPFR object (courtesy of overloading of '+') that has a value of NaN, which is false.

        Cheers,
        Rob
[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]
        Correct, which is why uninitialised needs to be distinct from NaN

        In C, the creation of an mpfr_t variable is done as follows: 
        mpfr_t x; /* declaration */
x = mpfr_init(); /* initializes x with a value of NaN */

        [download]
        x cannot be used for anything until it has been initialized - and once initialized, x remains NaN until some other value gets assigned to it.
        "Math::MPFR->new();" wraps those 2 steps. Maybe it should stop short of calling the mpfr_init() ... I'd have to play about with it before I could get my head around the usefulness (or otherwise) of doing so.

        Cheers,
        Rob
[reply]
[d/l]

In Section Seekers of Perl Wisdom