NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On 2016/07/08 10:07 AM, Ismail SEZEN wrote:
If we put the data aside, there is a dilemma here between header outputs of netcdf file by ncdump and R:ncdf4 package. In the ncdf4 oputput, add_offset and scale_factor has extra extra digits after decimal point. I don’t know how to interpret.
This is just the way floating point works. The offset, for example, is stored in the netcdf file as single-precision. R has no single-precision; reals are double-precision. When it converts the single-precision number to double, it is no longer the closest representation of the original decimal number.
Using python:
In [1]: import numpy as np
In [2]: x1 = np.float32('187.65')
In [3]: x2 = np.float64('187.65')
In [4]: x3 = np.float64(x1)
In [5]: print(x1, x2, x3)
187.65 187.65 187.649993896
In [6]: x1
187.64999
In [7]: x2
187.65000000000001
In [8]: x3
187.64999389648438
R is showing you x3; ncdump is showing you x1, recognizing that it is
the single-precision representation of 187.65, as in the print statement
above. As you can see, x3 is not the double-precision representation of
187.65; x2 is.
Eric
netcdfgroup archives: