-
Notifications
You must be signed in to change notification settings - Fork 22
[RFC] Improve consistency of arithmetic with Bool
#153
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #153 +/- ##
==========================================
+ Coverage 84.97% 85.29% +0.31%
==========================================
Files 2 2
Lines 213 238 +25
==========================================
+ Hits 181 203 +22
- Misses 32 35 +3
Continue to review full report at Codecov.
|
299c42d
to
df9abcc
Compare
v0.9.4
❌ : to be fixed as a bug |
This only fixes return types which are clearly unreasonable. Other inconsistent return types are leaved for backward compatibility for now.
69a4b58
to
5931c44
Compare
this PR
🆙 : fixed in this PR |
Bool
Bool
sumtype(::Type{Bool}, ::Type{B}) where {B} = B <: Integer ? N0f8 : sumtype(N0f8, B) # FIXME | ||
sumtype(::Type{A}, ::Type{Bool}) where {A} = sumtype(Bool, A) | ||
sumtype(::Type{Bool}, ::Type{Bool}) = N0f8 # FIXME | ||
divtype(::Type{Bool}, ::Type{B}) where {B} = divtype(B <: Integer ? N0f8 : UInt8, B) |
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.
Will this be more friendly to the compiler?
divtype(::Type{Bool}, ::Type{B}) where {B} = divtype(B <: Integer ? N0f8 : UInt8, B) | |
divtype(::Type{Bool}, ::Type{B}) where {B} = divtype(ifelse(B <: Integer, N0f8, UInt8), B) |
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.
Do you have a specific example?
At least for me, the fewer parentheses, the friendlier it is. 😄
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.
No, but I think it's perfectly fine to evaluate both the true and false cases here as they're constant DataType.
From
?ifelse
:
In some cases, usingifelse
instead of an if statement can eliminate the branch in generated code and provide
higher performance in tight loops.
The @code_native
looks the same for this case so I don't know if it worths. Maybe Julia is just smart enough to optimize it...
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.
Even using ifelse
does not completely suppress the branches, so I simply prefer to keep it short and readable.
In the first place, since this is a matter of constant propagation (or dead code elimination), I don't think it has anything to do with the branch generation.
I will merge this and release v0.9.5. |
I'm going to create some separate PRs for the parts not related toBool
.This PR only fixes return types which are clearly unreasonable. Other inconsistent return types are leaved for backward compatibility for now.
I feel the need to make the code more generalized before we can achieve v1.0. However, I am not sure when to do that. (Edit: see #156)Mostly improved.