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

[netCDF #DHW-277522]: ncdump doesn't display enough digits

Hello Ryo,

In addition to the response from Dennis, I think I can clarify the ncdump 
issue.  The default precision (which I don't have off the top of my head) is 
causing the rounding/issue you have reported.  You can correct this using the 
'-p' argument.  For example, when I run the following on the file you've 
provided, I see more precise output:

    $ ncdump -p 20,20 -v Z_ISO ncdump-bug-precision.nc

(...)

 Z_ISO =
  -9.9900000981736855962e+20, -9.9900000981736855962e+20, 

(...)

So, the precision displayed can be modified.  It's important to note that this 
is not affecting the underlying data in the file, it is only a cosmetic issue 
issue.

I notice you are doing a straight equality check on your values in the sample 
file you provided; this is typically not a good idea, for the reasons outlined 
here:

* http://floating-point-gui.de/errors/comparison/
* http://wiki.seas.harvard.edu/geos-chem/index.php/Floating_point_math_issues

When comparing floating point values, you must often take additional steps to 
ensure a very small difference in values, such as you've observed here, due to 
rounding errors.  Granted, I am coming at this from a C developer standpoint, 
as I am not a Fortran expert, but I believe the issue remains the same with 
programming in Fortran (as supported by the second link above).

I hope this information is helpful,

-Ward

> Dear netCDF maintainers,
> 
> I've found ncdump doesn't always display enough digits. If you display the
> attached netCDF file, you'll see
> 
> Z_ISO:_FillValue = -9.99000009817369e+20 ;
> 
> and
> 
> Z_ISO =
> -9.99000009817369e+20, [ . . . elided . . .]
> 
> How is that possible?  _Fillvalue doesn't work.  Actually the value of the
> variable is -9.9900000981736856e+20 .
> 
> This is confusing at least.  Moreover, because the output from ncdump can
> be used to generate another netCDF file, this problem can be the source of
> a subtle bug.  As the attached Fortran program demonstrates, gfortran is
> designed in such a way that ascii output retains enough digits to exactly
> recover the original value.
> 
> The Fortran program also illustrates how I was hit by this problem.  An
> application program converted my original single-precision data to double
> precision and as a result, it was difficult to set a correct fill value.
> But that's an aside.
> 
> Regards,
> 
> Ryo
> ------------------------------------------------------------
> ! The following program will print
> !
> ! -9.9900000981736856E+020  -9.9900000000000000E+020
> -9.9900000000000000E+020
> ! d1 == d2
> !
> ! using gfortran 4.8  .
> !
> program tmp
> implicit NONE
> real(8):: d, d1, d2 ! double precision variables
> character(16):: str = "-9.99e20"
> 
> d  = -9.99e20 ! single-precision constant
> d1 = -9.99d20 ! doulbe-precision constant
> read(str, *) d2 ! double precision read
> 
> write(*,*) d, d1, d2
> if (d1 == d ) write(*,*) "d1 == d"
> if (d2 == d ) write(*,*) "d2 == d"
> if (d1 == d2) write(*,*) "d1 == d2"
> end program tmp
> 
> 


Ticket Details
===================
Ticket ID: DHW-277522
Department: Support netCDF
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.