-
Notifications
You must be signed in to change notification settings - Fork 148
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
Traits for static arrays and friends #25
Comments
FWIW, I just started experimenting with immutable VectorView{P,N,T} <: StaticArray{T, 1}
duals::SVector{P,ForwardDiff.Dual{N,T}}
end
Base.size{P,T,N}(::VectorView{P,T,N}) = (P,)
Base.size{P,T,N}(::Type{VectorView{P,T,N}}) = (P,)
Base.getindex(x::VectorView, i::Int) = x.duals[i].value
Base.setindex!(x::VectorView, v, i::Int) = error("VectorView is immutable") The indexing becomes awkward for the immutable JacobianView{P,N,T} <: StaticArray{T, 2}
duals::SVector{P,ForwardDiff.Dual{N,T}}
end
Base.size{P,N,T}(::JacobianView{P,N,T}) = (P, N)
Base.size{P,N,T}(::Type{JacobianView{P,N,T}}) = (P, N)
function Base.getindex{P,N,T}(x::JacobianView{P,N,T}, n::Int)
i = div(n-1, N) + 1
j = mod(n-1, N) + 1
x.duals[i].partials[j]
end
Base.setindex!(x::JacobianView, v, i::Int) = error("JacobianView is immutable") Since these are essentially views, I've coded Also, my definition here seems to be broken -- or maybe I've hit a bug -- not sure yet: julia> J
3×3 JacobianView{3,3,Float64}:
0.267261 0.0958315 -0.4
0.534522 0.191663 0.2
0.801784 -0.159719 0.0
julia> J'
ERROR: MethodError: First argument to `convert` must be a Type, got T
in getindex at /Users/dbeach/.julia/v0.5/StaticArrays/src/indexing.jl:136 [inlined] (repeats 9 times)
in macro expansion at /Users/dbeach/.julia/v0.5/StaticArrays/src/linalg.jl:156 [inlined]
in ctranspose(::JacobianView{3,3,Float64}) at /Users/dbeach/.julia/v0.5/StaticArrays/src/linalg.jl:145 |
Ok, that's interesting @dbeach24. As a general comment - I wouldn't do views on an So I would just run Also, I'll try to investigate the error with |
See also |
I don't have very strong opinions on appropriate traits yet. A dimensions trait does seem like a great idea in that you could avoid the clunky dispatch seen in such places as src/eigen.jl (I assume?) I think having to make the mutable vs immutable distinction is unfortunate, though it might be a useful workaround until there's a viable alternative to Heap-vs-stack seems like a no-go to me. I doubt this is even something you can really even know based on the julia language semantics. For example, the compiler is probably free to place |
Yes, indeed!
Right. There is an open issue about the expanded set of traits you might be able to pass to
I admit that was a bit of a thought bubble, a bit like |
Ah, that's a much nicer way of stating it - high level semantics instead of implementation detail. Could be useful. |
This would be a very useful thing to dispatch on for me. |
Right... can you give an example @tkoolen to give me a better idea? I have to do this in the matrix multiplication stuff, because some larger heap-allocated types with certain element types get handed off to BLAS (to compete with the speed of |
Sorry, completely forgot about this. My application is also in matrix multiplication, and it isn't specific to my package. Basically, I need products of an |
If we implement that TODO would it resolve your problem? E.g. I could do either a non-mutating SMatrix{N,M,Float64}() * Vector{Float64}(M) -> SVector{N}(Float64) or a mutating A_mul_B!(::Vector{Float64}, ::SMatrix{N,M,Float64}, ::Vector{Float64}) |
If I take that word-for-word, then |
Unfortunately, the choice of the type of the first and third argument in that function call are constrained by other requirements in my application and can't be
I definitely need that, but also the case where the second argument is a |
@tkoolen master now has an implementation of these (i.e. Matrix-vector) functions. I haven't had time to do benchmarking, so if you want to take a look that would be great. |
Wow, awesome! I'll take a look tomorrow. Thank you so much! |
It's now tagged and published, along with a couple of other improvements and fixes. |
See #58 for a first attempt at a |
To keep this thread up-to-date, the |
#534 means I suppose we still have mutability as a concern here (which ultimately should be addressed in |
Rather than stack-allocated or heap-allocated, I need to know whether an Any suggestions or ideas? |
You are running into the intrinsic non-orthogonality of intrinsically independent traits. |
One thing that was realized in the
AbstractArray
interface is that traits are a convenient and powerful way of expressing ways of interacting with different types of arrays, the prototypical exampling beingLinearFast
vsLinearSlow
. I wanted to discuss some possible traits that would be useful for StaticArrays.jl while keeping in mind that with future language enhancements (e.g. the trait system experiments of Traitor.jl) might make them easier to use and interface intoBase
in the future.Dimensions
trait (@timholy suggestedSDims
to complementBase.Dims
). Unlike FixedSizeArrays, the size isn't specified in the abstractStaticVector{T}
, while the package is meant to use thesize()
on types interface, it doesn't make it easy to allow, e.g., any 3-vector. Introducing a trait would at least allow an "official" way of doing that. Speculatively, this could be extended so thatSDims <: AbstractDimensions
andBase.Array
etc have a dimensions trait with run-time size information (but compile-time rank). The dimensions trait could be combined with the "indices" trait being proposed/used in Base for non-1-based indexing.setindex!
work? Most algorithms in Base are defined usingsimilar
but that doesn't work for immutables, and it is a pain to define alternatives here that things other thanStaticArray
can't use at all.similar
vssimilar_type
.Any thoughts appreciated. Is it a good idea to be defining types here, in this package?
The text was updated successfully, but these errors were encountered: