Re: automatic type conversion issues: range errors

Hi Ed,

> > Hi Ed,
> >     HDF5 provides the user with a method of catching these sort of errors,
> > using the H5T{get|set}_overflow() routines.  The overflow routine is called
> > any time that a value in the source can't be represented exactly in the
> > destination, with the datatypes provided.  This allows a user application to
> > catch range errors and potentially change the value set for the destination
> > value.
> 
> Perfect! Thanks. I will start checking this.
> 
> >     Currently, there isn't a way to pass the information about the fill 
> > value
> > along to the user's callback routine, which looks like it would be 
> > necessary to
> > fulfill the current netCDF-3 functionality.  Additionally, I think it would 
> > be
> > better to have these routines set on an individual data transfer, instead of
> > globally for the library, so I think we should move them to be get|set 
> > routines
> > on a data transfer property list.
> 
> OK.
> 
> >     For now, you can use the current H5Tset_overflow routine to trap any
> > overflows and set them to be zero and when I've fixed this up better, you 
> > will
> > have access to the actual fill value the user set for the dataset.
> > 
> 
> So right now it will substitute a zero for a value that has overflowed?
    No. (see below)

> If one is storing temperature data, for example, zero is a perfectly
> valid value, so that would be a real problem. The very extremes
> (i.e. values which overflowed the expected type) will be plopped right
> in the center of the data distribution, at zero.
> 
> I think that the use of the fill value is mandatory in this case. I
> can't imagine a case where I would prefer overflowed values to be
> zero.
    Right now, any overflow routine that is register just gets called
with the source and destination datatypes and pointers to the source and
destination values.  It is up to the user's overflow routine to perform
whatever action is necessary.  (I was just suggesting zero for the moment,
until I fix the callback information to include the actual fill value).

    Quincey