Re: Double-type precision array elements acting odd

From: Dave Allured - NOAA Affiliate <dave.allured_at_nyahnyahspammersnyahnyah>
Date: Fri Apr 12 2013 - 14:49:09 MDT

This is a very common "gotcha". Inside the array constructor, you
have made a list of single precision floats because you did not
include the suffix "d". Just add the suffixes, and you should be all
set.

See "1D Double Precision Constant Array" on this page:
http://www.ncl.ucar.edu/Document/Manuals/Ref_Manual/NclDataTypes.shtml#ConstantsAndArraysOfConstants

--Dave
Please reply to user list only!

On Fri, Apr 12, 2013 at 2:21 PM, jonathan meyer <tallj03@hotmail.com> wrote:
> Good Friday to the community,
>
> I hope to have an easy question to answer regarding some odd issues I've
> stumbled across when using double precision array elements.
>
>
> I am using an equation which requires large accuracy in the coefficients,
> too long to use a float-type. I have declared a new array as type 'double',
> and issued the appropriate numbers for each element of the array.
>
> After no manipulation to the array, a print statement shows that the numbers
> have been modified, typically by adding a string of random digits of
> precision to the end of each element.
>
> No user on our end has seen (or looked) for such oddities when using double
> precision and I am wondering if this is an artifact of the way elements of
> this type are handled?
>
>
>
> My code is about as simple as it can get:
>
> begin
>
> g_coeff = new(8, double)
>
> print(g_coeff)
> g_coeff = (/ -2836.5744, -6028.076559, 1.954263612e1, -2.737830188e-2,
> 1.6261698e-5, 7.0229056e-10, -1.868009e-13, 2.7150305/)
>
> print(g_coeff)
>
>
> end
>
> The output for this code is as follows:
>
> Variable: g_coeff
> Type: double
> Total Size: 64 bytes
> 8 values
> Number of Dimensions: 1
> Dimensions and sizes: [8]
> Coordinates:
> Number Of Attributes: 1
> _FillValue : -9999
> (0) -9999
> (1) -9999
> (2) -9999
> (3) -9999
> (4) -9999
> (5) -9999
> (6) -9999
> (7) -9999
>
>
> Variable: g_coeff
> Type: double
> Total Size: 64 bytes
> 8 values
> Number of Dimensions: 1
> Dimensions and sizes: [8]
> Coordinates:
> Number Of Attributes: 1
> _FillValue : -9999
> (0) -2836.574462890625
> (1) -6028.07666015625
> (2) 19.54263687133789
> (3) -0.02737830206751823
> (4) 1.626169796509203e-05
> (5) 7.022905590403639e-10
> (6) -1.868009056899683e-13
> (7) 2.715030431747437
>
>
> ---------------------------------------------------------------
>
> As you can see, there are many digits of precision that are added onto my
> original numbers, and in a few cases, the number seems to be rounded before
> adding numbers to the end. I've tried setting the array to zero first to
> avoid any problems that might be carried over and the result is the same.
>
> In fact, if I classify 0.10000000000000000 as double, the results when
> printing are:
>
> (0) 0.1000000014901161
>
>
> Im hoping there is a more elegant solution to this than simply
> adding/subtracting small number to be on the correct side of a truncation
> call to the decimalPlaces function, and there is a good chance I'm just
> spacing something.
>
> As always,
> Thanks in advance!
>
> Jon
>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Fri Apr 12 14:49:23 2013

This archive was generated by hypermail 2.1.8 : Mon Apr 15 2013 - 20:12:25 MDT