-
-
Notifications
You must be signed in to change notification settings - Fork 21
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
Rewrite SLVector #18
Rewrite SLVector #18
Conversation
There's also an error in the test script diffeq.jl when using We can either go through OrdinaryDiffEq and make sure all out-of-place do not modify the vectors in any way (which could be a big endeavor) or just use |
Similar is defined as returning a mutable type. See JuliaLang/julia#22218 . This is one of the issues referenced at https://github.com/JuliaDiffEq/ArrayInterface.jl . |
That's wrong. |
That's why it |
The behavior is different even when julia> function func(x)
println("here")
x
end
func (generic function with 1 method)
julia> func.(x)
here
here
here
3-element LVector{Int64,Array{Int64,1},(:a, :b, :c)}:
1
2
3
julia> broadcast(func, x)
here
here
here
3-element LVector{Int64,SArray{Tuple{3},Int64,1,3},(:a, :b, :c)}:
1
2
3 Could the issue be inlining then? Anyways I have come to understand that overload I think this is another place where switching to |
julia> Meta.@lower x .+ x
:($(Expr(:thunk, CodeInfo(
1 ─ %1 = (Base.broadcasted)(+, x, x) │
│ %2 = (Base.materialize)(%1) │
└── return %2 │
)))) |
That is the reason that they are different. |
No, that's just an internal function from the broadcast handling: @andyferris do you know why that would happen? |
https://github.com/JuliaLang/julia/blob/master/base/broadcast.jl#L767 Normally, |
Maybe we can overload |
Oops... wasn't looking carefully when doing the diffeq.jl test error analysis.
What is actually happening here is:
But this reminded me that we should go through StaticArrays and copy all the overloaded methods also to here. Julia base is really not friendly towards immutable arrays :( kinda wish it includes a |
See and use ArrayInterface.jl
For now we can |
I can see the appeal to this. On the other hand I really like Yingbo's proposed solution since it treats
What's this |
Closed in favor of #19. |
This is based on @YingboMa's new
SLVector
implementation and the focus is on fixing the general conversion behavior of anSLVector
:convert(AbstractVector{S}, x)
and the broadcastedS.(x)
/convert.(S, x)
.My attempt is to define a
UnionAll
typeSLVector
and have special methods defined on that. For example, I overwroteAbstractVector{S}(x::SLVector)
(which is called byconvert(AbstractVector{S}, x)
by default) because the default implementation usescopyto!
on a similar vector, but sinceSVector
s are immutable this is problematic, so I completely overhauled the behavior.(On a side note, the fact the
AbstractVector{S}(x)
usescopyto!
has prompted StaticArrays to implementsimilar(x::SVector)
to return anMVector
(so it can be copied to). I don't really like this but I understand that they're trying to keep the behavior consistent with Base. Similar story goes to broadcast handling, which I also overwrote.)The broadcasting implementation is broken at the moment: for some reason calling
broadcast
as a function yields the correct result, but using the dot syntax doesn't.This seems really bizzare to me as the Julia docs state that
f.(x)
andbroadcast(f, x)
are equivalent (https://docs.julialang.org/en/v1/manual/arrays/#Broadcasting-1).