-
-
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
Reconsider uses of promote_op #19669
Comments
As a quick test, I did
which at least gives julia> x + x
1-element Array{Int64,1}:
2 for |
Poking around a bit, the code lines for mixed scalar/array cases pointed out by @andreasnoack in JuliaLang/LinearAlgebra.jl#388 are more interesting. They are responsible e.g. for julia> 1.0 + Float32[1.0]
1-element Array{Float32,1}:
2.0
julia> 1.0 + [1]
1-element Array{Float64,1}:
2.0 Preserving the array element type is a no-go for the second example. Blindly using |
Regarding the preservation of the array element type, I believe we should consider the following for a scalar
This and the fact that the code would be more easily maintainable, as @martinholters has mentioned before, makes me think that we should follow the route proposed in this issue (point 1 above). |
I don't think that |
I have collected some of the low-hanging fruit in this branch. I probably won't spend time on this during the holiday season, so if anyone wants to pick up from here, feel free. (Note the remarks in the commit regarding Diagonal!) Edit: I have delete the branch as most of the work there has made it into master, and the work on |
I think that the performance issues with using |
@stevengj, is that in response to the changes in the mentioned branch? Then no, the problem is that transposition cannot be fused into |
Another voice of support for this thread's proposal and the overall direction in the branch linked above. (Re. the first commit on that branch / |
This is quite convincing. I think we should just list the typical cases where preserving abstract element types could have been useful (if any), just to be sure we won't regret losing this feature too much. |
@martinholters, ah, I see. Once we have some kind of |
I would prefer So |
We already tried deprecating |
The (*)(A::AbstractMatrix, D::Diagonal) =
scale!(similar(A, promote_op(*, eltype(A), eltype(D.diag))), A, D.diag) Here, That would allow (*)(A::AbstractMatrix, D::Diagonal) = function_to_be_named(*, A, A, D.diag.') |
Couldn't some of this logic go into |
Certainly. Replacing |
starting to sound a bit like #16740 again |
A bit like it, but different in two aspects: The |
The OP doesn't use promote_op anymore, but the discussion seems to have strayed a bit from there. Is there anything left here, or has everything mentioned here eventually covered by the implementation and changes surrounding broadcast? |
I don't know whether to open another issue for this, so I am commenting here: the docstring of
while the design pattern section encourages it: https://docs.julialang.org/en/v1.4-dev/manual/methods/#Output-type-computation-1 I think this is confusing. |
We can perhaps never quite eliminate that discrepancy, but (as mentioned above), seem to be in a decent place now with it |
At the moment, the result's element type of
broadcast
is determined in a straight-forward way bytypejoin
ing the type of all the result's elements. (Exception: The empty case, where inference is invoked.) However, for certain operations, the more elaborate mechanism ofpromote_op
is used, which especially aims at doing magical stuff if the input arrays have non-leaf element types. E.g.While the behavior of
+
here does look useful, I wonder whether it is worth the inconsistency and the effort. I tend to say no, but before starting any real work on the issue, I'd like some feedback.The text was updated successfully, but these errors were encountered: