-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Deprecate vectorized two-argument complex in favor of compact broadcast syntax #19712
Conversation
@@ -512,8 +512,6 @@ function copy!(S::SharedArray, R::SharedArray) | |||
return S | |||
end | |||
|
|||
complex(S1::SharedArray,S2::SharedArray) = convert(SharedArray, complex(S1.s, S2.s)) |
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.
complex.(S1, S2)
would be at the mercy of similar
s return type here, right? so would not return a SharedArray
any more unless we were to go back on similar
returning SharedArray
?
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.
Would it make sense to define a separate broadcast
method, like
broadcast{T<:SharedArray}(::typeof(complex), S1::T, S2::T) = convert(T, complex.(S1.s, S2.s))
?
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.
complex.(S1, S2) would be at the mercy of similars return type here, right? so would not return a SharedArray any more unless we were to go back on similar returning SharedArray ?
IIUC, yes, complex.(A, B)
for SharedArray
s A
and B
would yield an appropriate <:Array
rather than <:SharedArray
. Best to keep this method as a broadcast
specialization as @ararslan
suggests, or instead require the more explicit convert(SharedArray, complex.(A, B))
going forward? (Fused cases will require the latter in any case unless we build a generic broadcast
for SharedArray
s.) Thanks!
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.
I would not recommend defining broadcast(::typeof(complex), ...)
, because it will not be called in the presence of fusion etcetera.
If you want a SharedArray
output, one option is to use in-place assignment (mysharedarray .= complex.(a,b)
). Another possibility would to define Base.Broadcast.containertype
promotion methods to always produce a SharedArray
from broadcast
on SharedArray
inputs, if that is the desired behavior.
Before I spend more time on this pull request: @stevengj, are you in favor of this change (as opposed to deprecating single-argument |
Yes, for the two-argument |
… broadcast syntax.
cd0f380
to
997785b
Compare
Revised extensively. |
This pull request deprecates most remaining two-argument
complex
methods (less a few defined in base/sparse/sparsevectors.jl that depend on #19690) in favor of compactbroadcast
syntax. Best!(Two-argument vectorized
complex
methods always return a fresh array. So in contrast to one-argument vectorizedcomplex
methods (which suffer from the same controversy asfloat
, namely what to do about ad hoc aliasing semantics as in #18495), these deprecations should be uncontroversial.)