Brian,
I've been thinking a lot about the 64bit dims problem in HDS and I've
come to the conclusion that we can't seriously release the 64bit HDS
implementation without it having 64bit dims type. Releasing the 32bit DIM
version now and then in a few months releasing a whole new 64bit dim
version just seems pointless. 64bit types will always be avaialble on the
platforms that use HDS64 so going to 64bit dims seems sensible (despite
the slight increase in file size).
After some experimenting it's clear that if you use 64bit dims then
these files aren't compatible with 32bit dims (you end up with dims that
look like (200,0) presumably because the 32bit HDS reads the first 32bit
of the 64bit dims and gets "200" and then reads the next 32 bits and gets
"0"). So I think the actual thing that needs to be done is:
* _always_ use UINT_BIG as the hds dim type.
* If HDS version 3 file read and write the dims as 32bit dims
(but only at the last possible moment) warning if truncation
occurs. ie the choice of dim type can no longer be dealt with
in the c preprocessor.
* Change the fortran interface to raise an error if the INTEGER*4
is truncated when exporting dims.
* If 64bit dims are needed from the fortran interface we will need
to add new API to the Fortran layer that uses INTEGER*8. eg
DAT64_SIZE.
* The only other option is to have a header item in the HDS file that
describes whether 32bit or 64bit dim types are used in the file.
This would stop the files getting larger but may not be worth the
effort (especially since if someone adds a >32bit component to the
file you have to update all the dims in the file).
I don't think we need to specify a v4.1 HDS file format but if developers
have lots and lots of 64bit HDS files that use 32bit dims then we will
need to simply up the version number again and say that all <= v4 use
32bit int for dims.
Also, how hard is it at this point to add 128 bit doubles (quads) and
64bit integer types to HDS? I see there is code to recognize long doubles
but long doubles on my mac do not seem to be any different to normal
doubles (according to float.h).
Brian: Does this sound reasonable?
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|