[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: address@hidden*Subject*: [netCDF #AEB-315486]: nf90_float too accurate...*From*: "Unidata netCDF Support" <address@hidden>*Date*: Wed, 16 Mar 2011 12:59:55 -0600

George, > Thanks very much for your help. > Ok, maybe I was just getting a little confused here. If I do an ncdump > and look at my (typical) variable dd12_3d this is what I see (below). > The numbers have 6 decimal places and are denoted as float. Is this > what is stored in the file (ie, a 6 decimal place number) - ie, is the > ncdump command showing the actual number (as opposed to a truncated > version) ? If so then I think I'm fine - if I really need to cut down > the filesize I can use the integer data packing method you describe - > that is clear. No what is actually stored in the file is a binary 32-bit floating-point IEEE-754 representation of the value, which typically has 24 bits of precision in the mantissa. The 7 significant digits that ncdump shows are usually enough for all the precision, but if you really want every last bit of precision represented in the ncdump output for all possible floating-point values, you will have to specify "-p 9" to ncdump, according to Theorem 15 of the paper: What Every Computer Scientist should Know About Floating-Point Arithmetic, D. Goldberg, ACM Computing Surveys, Vol. 23, No. 1, March 1991, pp. 5-48. which says When a binary IEEE single-precision number is converted to the closest eight digit decimal number, it is not always possible to recover the binary number uniquely from the decimal one. If nine decimal digits are used, however, then converting the decimal number to the closest binary number will recover the original floating-point number. Sorry to be pedantic, but binary-to-decimal conversion has those sorts of extreme corner cases! --Russ > >>>>>>>>>>>>>>>>>>>>>>>>>> > > > netcdf wsa_enlil.latest.suball { > dimensions: > x = 512 ; > y = 60 ; > z = 180 ; > t = 169 ; > variables: > float x_coord(x) ; > float y_coord(y) ; > float z_coord(z) ; > float time(t) ; > float dd12_3d(t, y, x) ; > > ...... > > data: > > dd12_3d = > 4.689313e-19, 4.519964e-19, 4.336969e-19, 4.148909e-19, 3.958285e-19, > 3.771553e-19, 3.594542e-19, 3.427877e-19, 3.272004e-19, 3.126775e-19, > 2.991249e-19, 2.864187e-19, 2.744344e-19, 2.631388e-19, 2.524795e-19, > 2.42441e-19, 2.330259e-19, 2.242003e-19, 2.159138e-19, 2.081488e-19, > 2.008492e-19, 1.939533e-19, 1.874012e-19, 1.811512e-19, 1.751806e-19, > 1.694775e-19, 1.64039e-19, 1.588641e-19, 1.539523e-19, 1.492887e-19, > > > > > > On 3/15/2011 3:56 PM, Unidata netCDF Support wrote: > > Hi George, > > > >> Hi there, > >> > >> I was wondering if you could help me. I have searched the mailing lists > >> but can't find anything suitable. > >> > >> I am using netcdf as the format for output from an atmospheric model. > >> The data in the netcdf is used solely for color contour plotting using > >> IDL. The problem I have is that the nf90_float data is much larger than > >> it needs to be. For instance a typical number written out from my idl > >> code is: > >> > >> 2.43866705894470210000e+000 > >> > >> There is way more accuracy in this number than needed for color > >> applications - a simple: > >> > >> 2.439e+00 would be perfectly adequate. > >> > >> Why this is a problem is that the datafiles are very large - because > >> they are large 2D arrays so the nf90_float accuracy is a problem. > >> > >> What I would ideally like is something like an NF90_smallfloat or > >> something. Or is there another way of doing this ? > >> > >> I am using netcdf 3.5 right now btw. > > > > The nf90_float type is only a 32-bit float, with about 5 significant > > digits of precision, as documented here: > > > > > > http://www.unidata.ucar.edu/netcdf/old_docs/really_old/f90-html-docs/guide7.html > > > > If you're seeing more precision than that, it may be the result of > > printing the values as double-precision. > > > > Arrays of nf90_float values require 4 bytes of storage for each value > > in a binary netCDF file. If you want to use less storage than that, > > you could pack the values into 2-byte nf90_short values, as described > > here: > > > > > > http://www.unidata.ucar.edu/netcdf/docs/BestPractices.html#Packed%20Data%20Values > > > > using the add_offset and scale_factor attributes for the packed variable. > > > > If you want to see the values with less precision when you print them out > > with the ncdump utility, you can use the "-p float_digits[,double_digits]" > > option to ncdump, as documented here: > > > > http://www.unidata.ucar.edu/netcdf/docs/ncdump-man-1.html > > > > If we've misunderstood your question, please let us know. > > > > --Russ > > > > Russ Rew UCAR Unidata Program > > address@hidden http://www.unidata.ucar.edu > > > > > > > > Ticket Details > > =================== > > Ticket ID: AEB-315486 > > Department: Support netCDF > > Priority: Normal > > Status: Closed > > > > -- > ---------------------------------------------------------------- > Dr. George Millward > Cooperative Institute for Research in Environmental Sciences (CIRES) > University of Colorado, Boulder > > Visiting scientist at > NOAA Space Weather Prediction Center > 325 Broadway, Boulder, CO 80305 > Tel: 303-497-6775 > > address@hidden > ---------------------------------------------------------------- > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: AEB-315486 Department: Support netCDF Priority: Normal Status: Closed

- Prev by Date:
**[netCDF #QGV-335526]: Problem with netcdf and fortran 90** - Next by Date:
**[netCDF #FYY-183264]: netcdf4.1.1 with hdf5-1.8.4-patch1** - Previous by thread:
**[netCDF #AEB-315486]: nf90_float too accurate...** - Next by thread:
**[netCDF #KPC-572697]: segmentation fault when writing** - Index(es):

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.