Re^4: NaNs are true

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

Comment on Re^4: NaNs are true

Replies are listed 'Best First'.
Re^5: NaNs are true by jdporter (Paladin) on Feb 28, 2011 at 12:45 UTC
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]
Re^6: NaNs are true by syphilis (Archbishop) on Mar 01, 2011 at 02:56 UTC
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]
Re^7: NaNs are true by jdporter (Paladin) on Mar 01, 2011 at 03:49 UTC
... has a value of NaN, which is false. Ok, I'm confused. In your OP, you say NaNs are true. Now you're saying they're false. Update: I see, you're talking about your overloaded version, which changes the "sign" of NaN. Ok, I agree that changing that is a Bad Idea in general, because of the violation of expectations. So, I guess you'll be stuck (assuming you ditch your overloaded version) doing an explicit test for NaN... `if ( $obj == NaN or $obj ) # true if true or NaN` [download] in which case, you could wrap it in a new method: `sub isTrue # ! { my $obj = shift; $obj == NaN \|\| $obj }` [download]	[reply] [d/l] [select]
Re^5: NaNs are true by ikegami (Patriarch) on Feb 28, 2011 at 17:14 UTC
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]
Re^6: NaNs are true by syphilis (Archbishop) on Mar 01, 2011 at 02:44 UTC
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]
Re^7: NaNs are true by ikegami (Patriarch) on Mar 01, 2011 at 05:12 UTC
Possibilities include Using an external state (e.g. NULL pointer to the mpfr_t for uninitialised). Setting the value to zero on creation. Setting the value to a specific NaN that's unlikely to occur by other means on creation.	[reply]