I think adding a flag to specify the NaN behavior is a great idea. I also think that, h5diff might not be the most efficient and useful tool to find NaNs.
IMO, it might be better to create a specific tool to search an h5 file for NaNs or maybe add the ability of the library to throw an error if a NaN is written. (A diff will necessitate a bit-wise comparison of every element, whereas if you are only looking for NaNs then there's no need to read in an element twice and then perform a bitwise comparison. It may be faster to read each element in once, and then only NaNs will need to have all their bits checked--vectorization and optimization considerations neglected.) It is ultimately the burden of the developer/application to ensure that one is not chugging along computing NaNs and burning precious CPU hours, but the whole point of HDF5 is to make data manipulation easier, and data sets self descriptive. In this regard, the ability to optionally throw an exception when a NaN is written, or perhaps track NaNs and their locations would likely be useful to many users. Izaak Beekman =================================== (301)244-9367 UMD-CP Visiting Graduate Student Aerospace Engineering [email protected] [email protected]
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
