Skip to content
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

Closed
nalimilan opened this issue Jul 3, 2016 · 5 comments
Closed

Should operations between Float16 and Integer promote to Float16? #17261

nalimilan opened this issue Jul 3, 2016 · 5 comments

Comments

@nalimilan
Copy link
Member

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
Copy link
Contributor

eschnett commented Jul 3, 2016

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
Copy link
Contributor

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
Copy link
Contributor

+1 Float16 should behave unsurprisingly

@StefanKarpinski
Copy link
Member

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
Copy link
Member

jiahao commented Jul 11, 2016

Ref: #5942

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants