[RFC] Improve consistency of arithmetic with Bool#153
[RFC] Improve consistency of arithmetic with Bool#153kimikage merged 2 commits intoJuliaGraphics:masterfrom
Bool#153Conversation
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 |
BoolBool
| 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.
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.
Do you have a specific example?
At least for me, the fewer parentheses, the friendlier it is. 😄
There was a problem hiding this comment.
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, usingifelseinstead 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.
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.