Re: Double-type precision array elements acting odd

From: Rick Brownrigg <brownrig_at_nyahnyahspammersnyahnyah>
Date: Fri Apr 12 2013 - 14:49:31 MDT

Hi Jonathan,

Try appending your literals with a "d" to force double-precision literal. (It seemed to work for me)

Hope that helps…
Rick

On 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,
>
> 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:39 2013

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