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
Generating non-IEEE floats
- such as bfloat16
, bfloat32
, or various float8_*
types
#3959
Comments
floats
with width not equal to 16, 32, or 64, such as bfloat16
or bfloat32
.floats
- such as bfloat16
, bfloat32
, or various float8_*
types
As an immediately-available workaround, I'll observe that bfloat16 and bfloat32 are simply truncated versions of the standard float32 and float64 respectively - so you could generate those and throw away the lower half of the bytes (mostly mantissa), with some minimal work to fix up NaNs (which would otherwise turn into +/- inf). In the longer term, I'd like to support these increasingly popular types directly. We'll need to think of this in relation to #3921, which gives us two main options:
In either case, The user-facing API would be to generalize the current |
Thanks for the speedy response. I experimented with manually truncating the lower half of the bytes (using I definitely look forward to the continuing hypothesis development around this topic in the future, especially if adding native functionality can do that down-casting very quickly. |
"Compile to native code" is definitely on the wishlist: #3074 (comment) - glad it's working in the meantime though! |
Thank you for hypothesis! It's a wonderful library that I use frequently.
While investigating a bug report from one of the users of my extension library: qthequartermasterman/hypothesis-torch#20, I realized that there is no obvious way (at least to me) in hypothesis to build a strategy that can generate only floats of width other than 16, 32, or 64, such as
bfloat16
orbfloat32
.Is there a straightforward way to construct such a strategy?
There is a mention of a desire to support these types after the float overhaul, but I cannot find any other references to such work ever being done.
I looked into the internals of how
floats
handleswidth
currently, and it looks likefloats_of
could be extended using a similar technique of stuct packing/unpacking. Before I implement that however, I was hoping to see if there is a more straightforward way.Is there a straightforward way to generate only
bfloat16
-valid floats using hypothesis?The text was updated successfully, but these errors were encountered: