Skip to content
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

ambiguity generated by default copyto! method #1097

Closed
longemen3000 opened this issue Sep 27, 2022 · 4 comments
Closed

ambiguity generated by default copyto! method #1097

longemen3000 opened this issue Sep 27, 2022 · 4 comments

Comments

@longemen3000
Copy link
Contributor

this line:

@inline Base.copyto!(dest, B::Broadcasted{<:StaticArrayStyle}) = _copyto!(dest, B)

seems that _copyto! only special handles methods that have static axes. is is correct to assume that those axes only happen on x <: AbstractArray ?. if that is the case, then other type trying to dispatch on copyto! only needs to define:

copyto!(dest::MyType,bc::Base.Broadcsast.AbstractArrayType{N})

then, if an external package needs to define
but the catchall method causes ambiguities in that regard.

I did a test run of StaticArrays on julia 1.8/windows, and removed that method. all tests passed.

@mateuszbaran
Copy link
Collaborator

I don't understand, what exactly is the problem with this method? What is x? Could you give a concrete example of an ambiguity?

I did a test run of StaticArrays on julia 1.8/windows, and removed that method. all tests passed.

There would very likely be a performance regression, you'd have to benchmark a few statically sized broadcasts to verify that.

@longemen3000
Copy link
Contributor Author

longemen3000 commented Sep 27, 2022

I don't understand, what exactly is the problem with this method? What is x? Could you give a concrete example of an ambiguity?

In general, x is any struct that needs to define implace broadcast assignment. in particular, i just tested DataFrames and it is affected:

using StaticArrays, DataFrames
df = DataFrame(A=1:3)
tup = (2,4,6)
sa = SVector(tup)
df .= tup #works
df .= sa #ambiguous method

There would very likely be a performance regression, you'd have to benchmark a few statically sized broadcasts to verify that.

at least in the coverage, that method isn't touched, because there is also:

@inline Base.copyto!(dest::AbstractArray, B::Broadcasted{<:StaticArrayStyle}) = _copyto!(dest, B)

that catches all x<:AbstractArray uses of copyto! and it's the one that is actually used

@mateuszbaran
Copy link
Collaborator

I see now, that's actually a good point -- I agree, removing that methods looks like a good idea.

@mateuszbaran
Copy link
Collaborator

Fixed by #1098 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants