Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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: