[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] Special Comparisons: nan == nan

From: Andrew J. Schorr
Subject: Re: [bug-gawk] Special Comparisons: nan == nan
Date: Mon, 7 Aug 2017 09:15:12 -0400
User-agent: Mutt/1.5.21 (2010-09-15)


Thanks for your bug reports.

Regarding #1:

On Sun, Aug 06, 2017 at 05:59:59PM -0700, Daniel Pettet wrote:
> 1.  A NaN is never equal to anything - including another NaN.  The
> following illustrate the problem
>     nan = 0 * 1e400
>     print nan               # nan
>     print nan == nan        # 1     should be 0
> }

This is caused by 2 issues in the code.

The eval.c:cmp_nodes function has this check at the top:

        if (t1 == t2)
                return 0;

So it has a special check for comparing a value to itself,
and always returns that they are equal.

If one disables that check and runs through the normal comparison logic, it
still returns true because of this code in node.c:cmp_awknums:

         * This routine is also used to sort numeric array indices or values.
         * For the purposes of sorting, NaN is considered greater than
         * any other value, and all NaN values are considered equivalent and 
         * This isn't in compliance with IEEE standard, but compliance w.r.t. 
         * comparison at the awk level is a different issue, and needs to be 
         * with in the interpreter for each opcode seperately.

        if (isnan(t1->numbr))
                return ! isnan(t2->numbr);

And this logic is mirrored in the MPFR version in mpfr.c:mpg_cmp.
So there are a couple of reasons why your test behaves the way
it does. I'm not sure whether or how to address your concern. I don't
imagine that too many people are using gawk with calculations involving
NaN that depend on these subtle behaviors. Arnold?

I haven't had time yet to look at issue #2.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]