Tools long double updates #522
Conversation
|
This is the output on jelly and hedgehog from h5dump of tldouble.h5 with current source from Allen's fork: Jelly (little endian) output hedgehog (big endian) output |
|
Hmmm....output should be the same. This doesn’t sound right.
…Sent from my iPhone
On Apr 5, 2021, at 10:11 PM, Larry Knox ***@***.***> wrote:
This is the output on jelly and hedgehog from h5dump of tldouble.h5 with current source from Allen's fork:
Jelly (little endian) output
***@***.*** tools]$ src/h5dump/.libs/h5dump ../../tools/testfiles/tldouble.h5
HDF5 "../../tools/testfiles/tldouble.h5" {
GROUP "/" {
DATASET "dset" {
DATATYPE H5T_NATIVE_LDOUBLE
DATASPACE SIMPLE { ( 3 ) / ( 3 ) }
DATA {
(0): 1, 2, 3
}
...
hedgehog (big endian) output
-bash-5.0$ src/h5dump/.libs/h5dump ../../tools/testfiles/tldouble.h5
HDF5 "../../tools/testfiles/tldouble.h5" {
GROUP "/" {
DATASET "dset" {
DATATYPE 128-bit little-endian floating-point
DATASPACE SIMPLE { ( 3 ) / ( 3 ) }
DATA {
(0): 1, 2, 3
}
...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#522 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLFT3KMKCZCT7MLDCLM7S3THJ3XVANCNFSM4Z3KACHQ>.
|
|
Yes the output is correct and the test should pass. |
|
This decision is wrong.
To everyone: native type reflects language type in memory on a particular platform. Information in the file is self-descriptive and should be portable. Native is not self-descriptive and portable. Tools should reflect that what is in the file is not supported.
…Sent from my iPhone
On Apr 6, 2021, at 6:40 AM, Allen Byrne ***@***.***> wrote:
Yes the output is correct and the test should pass.
This was the conclusion of the developers on Friday, that the tools should print NATIVE if the datatype matches that platform's NATIVE type, else print what the library knows about the type.
I might need to add more characteristics like precision.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#522 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLFT3M6KQMW2XMWSONMKETTHLXKZANCNFSM4Z3KACHQ>.
|
|
I will revert back to the removal of NATIVE_LDOUBLE in h5dump and h5ls. I will create an issue for the other native types in tools. |
|
The long double h5dump output now appears as: |
@koziol does this change satisfy your request? |
Also note that the n-bit h5dump test now shows that the datatype is of 3-bit precision: |
| /* print size, order, and sign */ | ||
| h5tools_str_append(buffer, "%lu-bit%s%s integer", (unsigned long)(8 * H5Tget_size(type)), | ||
| order_s, sign_s); | ||
| /* print size, order, sign, and precision */ |
There was a problem hiding this comment.
This is helpful, and probably sufficient for integers.
| /* print size and byte order */ | ||
| h5tools_str_append(buffer, "%lu-bit%s floating-point", (unsigned long)(8 * H5Tget_size(type)), | ||
| order_s); | ||
| /* print size. byte order, and precision */ |
There was a problem hiding this comment.
This is helpful, and not sufficient for floating-point types. There's a lot more details for floating point types: mantissa, sign bit, etc.
There was a problem hiding this comment.
Yes, but how much detail is needed? h5ls does print more and I could make h5dump match h5ls - at the very least.
There was a problem hiding this comment.
What's the output from h5ls look like?
There was a problem hiding this comment.
Opened "tldouble.h5" with sec2 driver.
dset Dataset {3/3}
Location: 1:800
Links: 1
Storage: 48 logical bytes, 48 allocated bytes, 100.00% utilization
Type: 128-bit little-endian floating-point
(80 bits of precision beginning at bit 0)
(48 zero bits at bit 80)
(significant for 64 bits at bit 0, no normalization)
(exponent for 15 bits at bit 64, bias is 0x3fff)
(sign bit at 79)
Some of this is in the right direction (more information for custom atomic types), but the H5T_NATIVE_LDOUBLE issue still isn't resolved. And now there's doxygen and Perl changes that should be in another PR, not here. |
According to Elena, NATIVE is a memory type. She has stated that h5dump/h5ls should display the file type. That reasoning suggests that h5dump/h5ls should eliminate the display of the NATIVE types and always show the file type. I agree since the NATIVE type is dependent on platform/compiler.
Well this PR is taking so long, I accidentally committed files! |
That suggests that all the "native" datatype output should be removed. Is that true? |
OK, please back out the accidental commit then. |
Please remove NATIVE type from tools' output and merge the fix. HDF5 tools display properties of data as stored in the file. If someone thinks that "NATIVE" can be used to describe portable data in the file, please justify, how "NATIVE" is portable. Thank you! |
I think that's good reasoning. :-) (Although a lot more work on this PR before it's merged) |
|
I agree, remove NATIVE display output. |
|
Created issue #551 for fixing tools to only display file datatypes. |
Added tests for tools and java testing.