in reply to NaNs are true

Any attempt to use (a variable set to) NaN for anything, including numerical comparison with anything, including another (variable set to) NaN, or implicitly with either true or false in a conditional statement, should cause an exception.

It is the numerical equivalent of dereferencing a null pointer.

The only tests of NaN that (possibly) should not cause an exception, are for numerical equivalence with a predefined constant NaN, or (perhaps) stringified equivalence to a predefined constant NaN.

Even comparison of one variable set to NaN with another variable set to NaN should raise an exception because to do otherwise would be equivalent to allowing: 

char *a = null, *b = null; 
if( ! strcmp( a, b ) ) {
    printf( "They are the same string\n";
}

[download]
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: NaNs are true
by syphilis (Archbishop) on Feb 27, 2011 at 01:03 UTC
    Any attempt to use (a variable set to) NaN .... should cause an exception.

    That'd make it too easy ;-)

    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.

    With mpfr, there's also the matter of ANSI/IEEE-754 compliance - which has a strong influence on the things it does.

    If only the IEEE-754 standard had decreed "nans are to be consdered false in a boolean sense". (I don't think it does, but I'd love to be wrong about that ... otoh, I'd hate to learn that it decrees the converse.)

    I think I might run this by the mpfr folk. It's quite OT there, of course, but knowing if there's some compelling reason to keep NaNs as "true" is something that's probably "right up their alley", so to speak.

    Cheers,
    Rob
[reply]
      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.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        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
[reply]
[d/l]

In Section Seekers of Perl Wisdom