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

Re: nc_test and floating point equality

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: nc_test and floating point equality
  • Date: Wed, 22 Nov 2006 11:18:19 -0700
Hi James,

Ed forwarded your message to me:

> I'm getting back results like:
>
> *** Testing nc_get_att_float ...
>          FAILURE at line 6136 of test_get.c: value read not that expected
> varid: -1, att_name: Gf, element number: 0 expect: -3.40282e+38got:
> -3.40282e+38
>
> And
>
> *** Testing nc_get_att ...
>          FAILURE at line 1367 of test_read.c: value read not that expected
> varid: -1, var_name: Global, att_name: Gf, element number: 0
> expect: -3.4028234663852886e+38
>     got: -3.4028200183756560e+38
>          FAILURE at line 1367 of test_read.c: value read not that
>
>  From nc_test. Is there a way I can tune the test driver to accept
> less percision for eqality? I thought I found something like that a
> while ago

There is a way to tune the precision of this test, but as far as I
know it has never been necessary on any other platform, so I'm
wondering if this is a symptom of some other problem.  The function
used is in nc_test/util.c:

/* 
 *  Does x == y, where one is internal and other external (netCDF)?  
 *  Use tolerant comparison based on IEEE FLT_EPSILON or DBL_EPSILON.
 */
int
equal(
    const double x, 
    const double y, 
    nc_type extType,    /* external data type */
    nct_itype itype)
{
    const double flt_epsilon = 1.19209290E-07;
    const double dbl_epsilon = 2.2204460492503131E-16;
    double epsilon;

    epsilon = extType == NC_FLOAT || itype == NCT_FLOAT ? flt_epsilon : 
dbl_epsilon;
    return ABS(x-y) <= epsilon * MAX( ABS(x), ABS(y));
}

so you could just change the last statement to something like

    return ABS(x-y) <= 2.0 * epsilon * MAX( ABS(x), ABS(y));

But since the failures you're seeing are with floats and the
conversions to XDR form for floats shouldn't be doing any arithmetic
on most platforms, just byte swapping, I'm puzzled why this should be
necessary.  Maybe the test for whether the min float at the extreme
range of floats can be written out and read back without its value
changing is tickling some bug with extreme floats on your platform.
What compiler and machine are you using?

--Russ