-
Notifications
You must be signed in to change notification settings - Fork 142
Added support for Float16
#341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 5 commits
f1315af
b6eb8d1
429bc75
e5e12ca
e51c84e
5c7b240
33dfb18
be6645b
bab0763
ef2d1a6
78a260a
861cdf4
9a7788e
6ec1cd6
ca674a8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -332,4 +332,12 @@ using Compat.String | |
| str = read(fid["test"]) | ||
| @test str == "Hello World" | ||
| end | ||
|
|
||
| # Test Float16 support | ||
| arr_float16 = Float16[1.0, 0.25, 0.5, 8.0] | ||
| h5write("test_float16.h5", "x", arr_float16) | ||
|
||
| arr_float16_2 = h5read("test_float16.h5", "x") | ||
| @test isa(arr_float16_2, Vector{Float16}) | ||
| @test arr_float16_2 == arr_float16 | ||
|
|
||
| end | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I don't really understand why this has to be in
__init__do you think you could please explain this to me?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is needed for the same reason that
H5open()is called inside__init__:make_float16()is allocating new data structures inside the underlying hdf5 library and must be called each time the library is loaded.Actually it's interesting that the rest of the code assumes the value of globals like
H5T_NATIVE_FLOAT_gwill be consistent between different runs of the julia program. Looking at the C library, these globals are allocated insideH5open(), so it seems this isn't really guaranteed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I'm wondering of a way to trigger a bug to show that.
In matlab.jl we have references https://github.com/JuliaInterop/MATLAB.jl/blob/master/src/init.jl
that are filled in with the pointers in inside
__init__ref https://github.com/JuliaInterop/MATLAB.jl/blob/master/src/MATLAB.jl#L53we might have to do the same here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea if we can trigger a bug/make a test for this... would it happen if the HDF5 binary library was updated without this package being precompiled again? And yes, to me, filling references at run-time during
__init__seems the safest possible thing to do.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To trigger this possible bug, it looks like you'd need to first load a library which creates a custom id dynamically (through a call to
H5Iregister()I guess?), beforeH5open()is called. I don't know whether the libhdf5 API contract prevents this from happening.After that, load HDF5.jl into the same process and the ids may be different from when HDF5.jl was loaded in build.jl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems quite possible. Another library (e.g. PETSc) could depend on HDF5_jll so that HDF5_jll is loaded and initialized before HDF5.jl is initialized. It would be quite difficult to trigger this in a test case though.