NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: automatic type conversion issues: future development

NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.

Hi Ed,

> There is an obvious combination of the code I posted, and the
> "odometer algorithm" in the original netcdf code. I haven't yet
> combined these, but when I do it will fix a number of bugs, and also
> give me support for the mapping functions as well. (And I still don't
> understand how those are meant to be used!)
> 
> In the HDF5 world, I would like to see your type conversion meet the
> following requirements:
> 
> 1 - Convert types like C does.
> 2 - Check for range errors, and give an error if one or more occur,
> but continue the operation anyway, substituting fill values for the
> out of range values.
> 3 - Obviously, only check the subset of the data actually
> read/written. That is,  if a hyperslab is to be written, don't check
> range or convert types of values not in the hyperslab.
> 
> Quincey, what do you think of all that?
    Yes, that is exactly what will happen for the int <-> float conversion.
(and can happen now, with the use of the H5Tset_overflow() routine, for
int <-> int and float <-> float conversions)

    Quincey

  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-hdf archives: