Should operations between Float16 and Integer promote to Float16?

[nalimilan]

Currently operations mixing a Float16 and an Integer return a Float32. I know this is intended, and can be justified by the fact that computations cannot be done in Float16 (i.e. need to go through Float32). 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 for Complex{Float16}: https://github.com/JuliaLang/julia/pull/16995/files#diff-14e9aeed28aafd6fb66ae06e0cc83944R453
The 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 a Float32 result can still apply conversions manually before doing computations. Anyway, since Float16 is mainly useful as a storage type, users may also want to work with Float64 instead of Float32 to avoid precision losses in complex computations.

[eschnett]

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 x + 10 is probably fairly common, i.e. using an integer literal in a floating-point conversion. Thus Float16 + Int should probably result in a Float16 again. Otherwise, all floating point code that needs to be Float16-safe would need to add explicit conversions to all integer literals, which is surely tedious and difficult to check.

[JaredCrean2]

The fact that most machines can't do Float16 operations is a hardware detail that Julia should abstract away. Julia may one day run on machines that support unusual data types. I definitely agree Float16 should follow the rules used for the other floating point types.

[JeffreySarnoff]

+1 Float16 should behave unsurprisingly

[StefanKarpinski]

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.

[jiahao]

Ref: #5942