Re: 19990715: "Numeric conversion not representable"

John,

> To: address@hidden
> cc: address@hidden,
> cc: address@hidden
> From: address@hidden (John Sheldon)
> Subject: "Numeric conversion not representable"
> Organization: NOAA/FDL
> Keywords: 199907152254.QAA09656 netCDF Cray T90

In the above message, you wrote:

> We are having a problem on our Cray T90 similar to that reported
> by Sandy King on their Sun back in May.  Our "uname -a" :
>            sn7005 sn7005 10.0.0.2 roo.8 CRAY TS
> 
> A code that ran fine under netCDF 2.4.2 now gets a "Numeric conversion
> not representable" error under version 3.4.  Back when Sandy reported 
> their problem, you mentioned that you couldn't duplicate the problem.
> 
> Now, I can recreate our user's problem with the attached test code.
> It defines a REAL*8 variable that is outside the REAL*4 range and tries
> to NCVPT it.  The code runs OK using version 2.4.2, and an ncdump of
> the file shows the value of the variable as "Inf".  

It sounds like your program relied on unspecified behavior of the netCDF
library.  The netCDF specification (as found in the User's Guide)
never documented what the library would do if a too-large double value
was written into an NCFLOAT).  Thus, is would be perfectly ligitimate
for another implementation of the netCDF interface to do something
different.  Technically speaking, programs that rely on such unspecified
behavior aren't "strictly conforming" netCDF programs.

> However, under version 3.4, I get:
>  NCVPT: : Numeric conversion not representable
> and the code quits and the output file has 0 length.
> 
> While I can appreciate the consistency with respect to the behavior
> of "NF_PUT_VAR_REAL", this does seem to represent a certain lack
> of non-backward-compatibility with 2.4.2.

In version 3 of the netCDF interface, we tightened-up the specification
by, among other things, specifying what will happen in certain
value-conversion situations.  This is consistent with the previous
specification of the netCDF interface since such behavior was
previously unspecified.  netCDF implementations such as the one we
provide, however, are free to choose what to implement for unspecified
behavior.  It's regretable that your program's dependency on a
particular implementation of unspecified behavior has caused a problem
but, at this stage of the game, there's not much we can do about it.

I suggest that the maintainer of your program update it so that it no
longer depends on a particular unspecified behavior.  If the program
used the Version 2 interface and they don't want the program to exist,
then I suggest initially calling the NCPOPT subroutine with the
appropriate argument.  In this case, however, I wouldn't rely on any
particular value being written to the netCDF dataset.

Even though we should know better, all programmers with any experience
have written code that relys on unspecified behavior- (I've done it more
times than I care to remember).  If there's anything we can do to make
the update easier, please let us know.

> Thanks in advance for any help or insight!
> 
> John P. Sheldon 
> Technical Services Manager
> - ----------------------------------------------+---------------------------
>  NOAA/Geophysical Fluid Dynamics Laboratory   | Email: address@hidden
>  Princeton University/Forrestal Campus/Rte. 1 | Tel:   (609) 987-5053
>  P.O. Box 308                                 | Fax:   (609) 987-5063
>  Princeton, NJ, USA  08542                    | WWW:   http://www.gfdl.gov
> - ----------------------------------------------+---------------------------
> 
>       program test_ncvpt
>       
>       include "netcdf.inc"
>       
>       real   r8,r4plus
>       real*4 r4
>       INTEGER RCODE
>       INTEGER VDIMS(1)
>       INTEGER START(1)
>       INTEGER COUNTS(1)
>       
> 
>       print *,'Huge(r4) = ',HUGE(r4)
>       print *,'Huge(r8) = ',HUGE(r8)
>       
>       r4plus = HUGE(r4)*10.
>       
>       start(1)=1
>       counts(1)=1
>       
>       ncid = NCCRE ('test.nc', NCCLOB, rcode)
>       
>       ncvarid = NCVDEF (NCID,'junk',NCFLOAT,0,VDIMS, rcode)
>       call NCENDF (NCID, rcode)
>       
>       call NCVPT (NCID,ncvarid,START,COUNTS,r4plus, rcode)
>       
>       call NCCLOS (NCID, rcode)
>       
>       print *,'test_ncvpt finished OK'
> 
>       end
> 
> ------- End of Forwarded Message

--------
Steve Emmerson   <http://www.unidata.ucar.edu>