-
Notifications
You must be signed in to change notification settings - Fork 152
Determine broadcast
element type based on actual values
#495
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
Determine broadcast
element type based on actual values
#495
Conversation
Mimic the behavior for `Array`s and only use `return_type` in the empty case.
broadcast
element type base on actual valuesbroadcast
element type based on actual values
@test_broken eltype(a - 2) == Number | ||
@test_broken eltype(a * 2) == Number | ||
@test_broken eltype(a / 2) == Number | ||
@test eltype(a + 2) == Number |
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.
Shouldn't these methods be deprecated? They are for general arrays.
julia> [1, 2, 3] + 1
ERROR: MethodError: no method matching +(::Array{Int64,1}, ::Int64)
Closest candidates are:
+(::Any, ::Any, ::Any, ::Any...) at operators.jl:502
+(::Complex{Bool}, ::Real) at complex.jl:292
+(::Missing, ::Number) at missing.jl:93
...
Stacktrace:
[1] top-level scope at none:0
julia> @SVector([1, 2, 3]) + 1
3-element SArray{Tuple{3},Int64,1,3}:
2
3
4
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.
True, but orthogonal to this issue, except that I could use the explicit broadcast in these tests as I'm touching them anyways. (And it's in the broadcast tests.)
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.
Yea, just wanted to point it out since I noticed 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.
Updated the tests locally; will push once I have feedback what to do about the empty case.
It's a very interesting question. Here's a splattering of random thoughts.
There is however a very important "covariance vs invariance" discussion involving the work that is in this PR, relating to the whole |
Ok, let's leave the discussion of the empty case to another time. So yeah, with this PR |
Done by #503. |
Mimic the behavior for
Array
s and only usereturn_type
in the empty case. I wonder, however, whether we shouldn't useUnion{}
in the empty case. We don't have to worry about the type-instability as the size is part of the type, too, and cannot e.g.push!
to anSVector
. So there seems to be little harm. Opinions?Ref. JuliaLang/julia#28981, closes #493. But note that nested broadcasts will still suffer from incomplete inference due to the recursion limiting heuristics.