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.
Thank you Eric. This explanation was very good. > On 08 Jul 2016, at 23:46, Eric Firing <efiring@xxxxxxxxxx> wrote: > > 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 > > _______________________________________________ > NOTE: All exchanges posted to Unidata maintained email lists are > recorded in the Unidata inquiry tracking system and made publicly > available through the web. Users who post to any of the lists we > maintain are reminded to remove any personal information that they > do not want to be made public. > > > netcdfgroup mailing list > netcdfgroup@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
netcdfgroup
archives: