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

Re: 20020529: numeric conversion

>To: <address@hidden>
>From: Stacy Walters <address@hidden>
>Subject: numeric conversion
>Organization: UCAR/Unidata
>Keywords: 200205292059.g4TKxwp10408

Hi Stacy,

> I got a "Numeric conversion not representable" from a
> variation of the cgd cam1 program.  I have been running
> for some four years before the error occurred.  I believe
> this is coming from a netcdf put subroutine.  I am not
> sure at this point which exact call.  I wonder if a nan
> (not a number) could cause this result ?? Thanks.

No, it's possible to store NaNs of the right type using netCDF put
routines.  Since NaNs are often used as missing value indicators, this
is by design.  So, for example, if you got a float NaN by dividing by
zero, the result could be stored in a NC_FLOAT variable and would not
cause an error when writing.  This works for either infinite NaNs (for
example 1.0/0.0) or indefinite NaNs (0.0/0.0), and ncdump will print
these values as "Inf" or "NaN" in float arrays.

However, if you try to store a double-precision NaN in a
single-precision (NC_FLOAT) variable, you will get the "Numeric
conversion not representable" error when you call nc_put_var_double().
This error will occur if any of the values in an array of doubles are
not representable as floats and you try to write them into a netCDF
variable of type NC_FLOAT.  So the value need not be a NaN, it could
just be a double with an exponent too large to be represented in a
float, or a double too large to be represented as a 32-bit integer
written to an NC_INT variable, or an integer too large to be
represented in a 16-bit value written to an NC_SHORT variable, etc.

Another possibility is that the value is a double that is
representable as a double on whatever platform you are running on, but
is too large to be converted to an IEEE double, or similarly for float
and IEEE float.  In this case the error indicates that the value might
be OK on your platform but is not portable data, since it can't be
represented on a machine that uses IEEE floating-point.

There is also a chance that you've discovered a bug with a value that
should legitimately be representable in XDR form as an IEEE value but
the conversion fails for that particular value, perhaps something
close to the limits.  In that case, we'd appreciate a program
demonstrating the error ...

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu