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

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.

Replies are listed 'Best First'.
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 */
    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

      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.