The mpfr library actually initialises the mpfr_t data type with a value of NaN. It's something I sort of like - it implies (to me, anyway) that the developers, having no idea what value should be assigned initially, have quite appropriately assigned no value. It's up to the program to assign a value to the mpfr_t variable - and until that variable is assigned a value, it stays as NaN.

That, to me, makes perfect sense. If the programmer creates an mpfr_t variable, and subsequently tries to perform an operation upon it withouthaving initialised it, the operation raises an exception.

That seems to me to be directly analogous to:

my $x; 
$x *= 2;

Use of uninitialized value $x in multiplication (*) at ...
[download]

Albeit that's a warning rather than fatal.

And equivalent to the trap that occurs when:

void something( char *x ) {
    printf( "%s\n", *x );
}

...
char *s;
something( s );
[download]

Raising an exception if teh programmer attempt to use a NaN value in an operation means that he will know about it if it happens, but can deal with it if it is a possibility and there is something sensible that he can do.

my $x;
$x *= 2;

Use of uninitialized value $x in multiplication (*) at ...

Good analogy. With the mpfr library (as with perl), such an operation does not cause a fatality - but a warning *is* provided (if the program explicitly looks for it) in that the nan flag is set:

#!perl -swl
use Math::MPFR qw(:mpfr);

my $fr = Math::MPFR->new();
print $fr;
warn "nan flag not set\n" unless Rmpfr_nanflag_p();

$fr *= 2;
warn "nan flag set\n" if Rmpfr_nanflag_p();
print $fr;
Rmpfr_clear_nanflag(); # Clear nan flag


__END__

Outputs:

@NaN@
nan flag not set
nan flag set
@NaN@
[download]

Maybe the Math::MPFR/Math::MPC overloading of the arithmetic operators should warn about operations involving NaN's by default (at least if warnings are enabled) ... that would be quite a perlish thing to do!

Cheers,
Rob