Re: Revising numeric overflows document

• To: netcdf-hdf@xxxxxxxxxxxxxxxx
• Subject: Re: Revising numeric overflows document
• From: Quincey Koziol <koziol@xxxxxxxxxxxxx>
• Date: Tue, 13 Apr 2004 15:32:49 -0500 (CDT)

Hi Ed,

> Quincey Koziol <koziol@xxxxxxxxxxxxx> writes:
> 
> > Hi all,
> >     I've posted a short document describing the changes I think are 
> > necessary
> > to accomodate supporting netCDF-3 datatype conversions here:
> >     http://hdf.ncsa.uiuc.edu/HDF5/planning/DP/Overflow.html
> > 
> >     Please comment and send suggestions to me.  If there's enough interest, 
> > we
> > can have a separate meeting to discuss the changes.
> > 
> >     Quincey
> 
> Let me ask a question...
> 
> I would first define a dataset and set it's fill value.
    Yes.

> Then I would pass a pointer to my version of the conversion function?
> What would it do? Just copy the fill_buf to dst_buf?
    You would then need to create a dataset transfer property list and set
the conversion function to your callback routine.

> Then I would try to transfer data.
    Yes, using the dataset tranfer property list with your callback routine set
as the conversion function.  Then, during the transfer of the data, if any
exceptions occur, your callback routine would be invoked and could handle
substituting the fill value for the destination value as desired.

> Would I know that the callback function has been called? 
    It's an "event driven" architecture, so you wouldn't necessarily know it
had been invoked, unless you put in code to track that.

    Quincey
>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 13 2004 Apr -0600 17:59:50 
Message-ID: <wrxy8ozv37t.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 13 Apr 2004 17:59:50 -0600
From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
In-Reply-To: <200404132032.i3DKWnBG084229@xxxxxxxxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: Re: Revising numeric overflows document
Received: (from majordo@localhost)
        by unidata.ucar.edu (UCAR/Unidata) id i3DNxqtD022993
        for netcdf-hdf-out; Tue, 13 Apr 2004 17:59:52 -0600 (MDT)
Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu 
[128.117.140.88])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id i3DNxpCT022983
        for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Tue, 13 Apr 2004 17:59:51 -0600 (MDT)
Organization: UCAR/Unidata
Keywords: 200404132359.i3DNxpCT022983
References: <200404132032.i3DKWnBG084229@xxxxxxxxxxxxxxxxxxxxxx>
Lines: 63
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx
Precedence: bulk
Reply-To: netcdf-hdf@xxxxxxxxxxxxxxxx

Quincey Koziol <koziol@xxxxxxxxxxxxx> writes:

> Hi Ed,
> 
> > Quincey Koziol <koziol@xxxxxxxxxxxxx> writes:
> > 
> > > Hi all,
> > >     I've posted a short document describing the changes I think are 
> > > necessary
> > > to accomodate supporting netCDF-3 datatype conversions here:
> > >     http://hdf.ncsa.uiuc.edu/HDF5/planning/DP/Overflow.html
> > > 
> > >     Please comment and send suggestions to me.  If there's enough 
> > > interest, we
> > > can have a separate meeting to discuss the changes.
> > > 
> > >     Quincey
> > 
> > Let me ask a question...
> > 
> > I would first define a dataset and set it's fill value.
>     Yes.
> 
> > Then I would pass a pointer to my version of the conversion function?
> > What would it do? Just copy the fill_buf to dst_buf?
>     You would then need to create a dataset transfer property list and set
> the conversion function to your callback routine.

OK, that's cool.

> 
> > Then I would try to transfer data.
>     Yes, using the dataset tranfer property list with your callback routine 
> set
> as the conversion function.  Then, during the transfer of the data, if any
> exceptions occur, your callback routine would be invoked and could handle
> substituting the fill value for the destination value as desired.

OK, let me think about this tonight after my kids go to bed and I'll
see if I understand what is going on.
> 
> > Would I know that the callback function has been called? 
>     It's an "event driven" architecture, so you wouldn't necessarily know it
> had been invoked, unless you put in code to track that.

I need to give a range error when the fill value substitution takes
place. 

For example, if someone calls nc_put_var_float(), with a bunch of
doubles, and a fill value has to be used because some are out of
range, then nc_put_var_float needs to return NC_ERANGE instead of
NC_NOERR.

So I have to be able to detect that one or more fill value
substitutions has taken place. I could set some kind of global
variable, but that's a bit cheesy, I'm sure you agree.

It would be very handy indeed if I could somehow get back some
information about whether any overflows occured...

Thanks,

Ed