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)


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