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/
