-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Should operations between Float16 and Integer promote to Float16? #17261
Comments
Julia doesn't need to provide a default behaviour in all cases. If there is sufficient ambiguity, requiring the user to explicitly state intent might be best, i.e. requiring explicit conversions. In this, case, code such as |
The fact that most machines can't do |
+1 |
This is a legacy behavior from the idea promoted by IEEE 754 that Float16 is a "non-computational type" only intended for storage. That's clearly not the case since people keep wanting to compute with it and GPUs actually directly support doing so. We should make Float16 behave consistently with Float32 and Float64. |
Ref: #5942 |
Currently operations mixing a
Float16
and anInteger
return aFloat32
. I know this is intended, and can be justified by the fact that computations cannot be done inFloat16
(i.e. need to go throughFloat32
). Yet, this introduces an inconsistency in the promotion rules. It makes them harder to remember.Also, since
Float16
is a corner case, some methods are type-unstable without anybody noticing. For example,^(::Complex, ::Complex)
was type-unstable in Base forComplex{Float16}
: https://github.com/JuliaLang/julia/pull/16995/files#diff-14e9aeed28aafd6fb66ae06e0cc83944R453The fix requires explicit conversion, which feels weird in the code.
So I'd advocate changing this behavior so that
Float16
follows the rules used for other floating point types. People who want aFloat32
result can still apply conversions manually before doing computations. Anyway, sinceFloat16
is mainly useful as a storage type, users may also want to work withFloat64
instead ofFloat32
to avoid precision losses in complex computations.The text was updated successfully, but these errors were encountered: