-
Notifications
You must be signed in to change notification settings - Fork 44
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
Julia 0.6 support / updates to match StaticArrays 0.4.0 #25
Conversation
|
||
A statically-sized, N×N unitary (orthogonal) matrix. | ||
|
||
Note: the orthonormality of the input matrix is *not* checked by the constructor. | ||
""" | ||
immutable RotMatrix{N,T,L} <: Rotation{N,T} # which is <: AbstractMatrix{T} | ||
struct RotMatrix{N,T,L} <: Rotation{N,T} # which is <: AbstractMatrix{T} | ||
mat::SMatrix{N, N, T, L} # The final parameter to SMatrix is the "length" of the matrix, 3 × 3 = 9 |
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.
So should we override the default constructors to fix the ambiguity?
Something like
struct RotMatrix{N,T,L} <: Rotation{N,T} # which is <: AbstractMatrix{T}
mat::SMatrix{N, N, T, L} # The final parameter to SMatrix is the "length" of the matrix, 3 × 3 = 9
RotMatrix{N,T,L}(x::AbstractArray) where {N,T,L} = new{N,T,L}(convert(SMatrix{N,N,T,L}, x))
end
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.
That's a stack overflow error:
[1] macro expansion at /Users/twan/code/julia/RigidBodyDynamics/v0.6/StaticArrays/src/SMatrix.jl:65 [inlined]
[2] Type at /Users/twan/code/julia/RigidBodyDynamics/v0.6/StaticArrays/src/SMatrix.jl:61 [inlined]
[3] Type at /Users/twan/code/julia/RigidBodyDynamics/v0.6/Rotations/src/core_types.jl:86 [inlined]
[4] convert at /Users/twan/code/julia/RigidBodyDynamics/v0.6/StaticArrays/src/convert.jl:7 [inlined]
[5] Rotations.RotMatrix(::StaticArrays.SMatrix{2,2,Float32,4}) at /Users/twan/code/julia/RigidBodyDynamics/v0.6/StaticArrays/src/convert.jl:4 (repeats 80000 times)
src/core_types.jl
Outdated
|
||
A statically-sized, N×N unitary (orthogonal) matrix. | ||
|
||
Note: the orthonormality of the input matrix is *not* checked by the constructor. | ||
""" | ||
immutable RotMatrix{N,T,L} <: Rotation{N,T} # which is <: AbstractMatrix{T} | ||
struct RotMatrix{N,T,L} <: Rotation{N,T} # which is <: AbstractMatrix{T} | ||
mat::SMatrix{N, N, T, L} # The final parameter to SMatrix is the "length" of the matrix, 3 × 3 = 9 | ||
end | ||
|
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.
Then we probably need to redefine the default outer constructor (which is lost because we defined an inner constructor).
RotMatrix(x::SMatrix{N.N,T,L}) where {N,T,L} = RotMatrix{N,T,L}(x)
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.
Ideally, we could have a series of constructors to populate N
, T
, etc, so that RotMatrix{2}([1 0; 0 1])
works (maybe useful for REPL...)
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.
Adding
RotMatrix(x::SMatrix{N,N,T,L}) where {N,T,L} = RotMatrix{N,T,L}(x)
in addition to the inner constructor does fix the ambiguity and stack overflow error; sorry, I should have tried that before commenting earlier.
Thanks @tkoolen - what I've seen so far looks good. This is really appreciated :) |
The next issue is the I made sure that the following works: r = RotX(Float32(3.))
RotX(r)
RotX{Float32}(r)
RotX{Float64}(r)
convert(RotX{Float32}, r)
convert(RotX{Float64}, r)
convert(RotX, r) Given the need for these changes, I'm starting to think that the answer to this question might be 'no'... What do you think? |
I went ahead and made the same changes I made to |
You shouldn't need to work around JuliaArrays/StaticArrays.jl#128 - see JuliaArrays/StaticArrays.jl#130 |
OK. Let's undo the workaround once a new StaticArrays tag is in, so that this can target 0.4.0. |
@@ -36,7 +36,8 @@ function jacobian(::Type{RotMatrix}, q::Quat) | |||
# then R = RotMatrix(q) = RotMatrix(s * qhat) = s * RotMatrix(qhat) | |||
|
|||
# get R(q) | |||
R = q[:] |
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.
For future reference, this is the only place where JuliaArrays/StaticArrays.jl#128 was causing issues.
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.
Fixed upstream, will need a StaticArrays-0.4.1 release though
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.
Great refactor, thanks @tkoolen!
return R(2*pi*rand(T)) | ||
# Not really sure what this distribution is, but it's also not clear what | ||
# it should be! rand(RotXY) *is* invariant to pre-rotations by a RotX and | ||
# post-rotations by a RotY... |
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.
Good point. If it's not a known distribution, I'd guess
- Experts won't use it
- Naive users will use it and get something unexpected :-)
Perhaps better just to remove this entirely - people can easily write rand(RotX)*rand(RotY)
and get the same thing with improved clarity about which exact distribution they're using.
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.
This was not my comment; I just copied it from the original location.
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.
Right, I guess this PR is probably not the best place to be removing things anyway.
end | ||
end | ||
|
||
function Base.rand{R <: Union{RotX,RotY,RotZ}}(::Type{R}) |
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 wonder whether it would it be productive to define SingleAxisRotation = Union{RotX,RotY,RotZ}
, and move most of the definitions in the loop down here instead, just like rand
?
It would probably lead to more straightforward code, and a lot less entries added to method tables (though I'm not sure whether this is ultimately good or bad for the julia runtime when the methods which are added have complex union types as parameters :-) ).
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.
Either way for me. I don't currently have a good mental model for costs related to method tables. @andyferris, any thoughts?
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.
Well, let's not let this block merging the fixes.
@tkoolen what's the status of this PR now that you've added various changes? Did you sort out the queries further up the page, or do you still want another opinion? |
Ready to go in my opinion. There's no new StaticArrays tag yet, so the workaround is still needed for now. |
Excellent. I'm not super keen on dropping julia-0.5 support in |
Great, thanks! |
Tag a new release? JuliaImages/ImageTransformations.jl#18 |
Oh, and many thanks, @tkoolen! |
The easy part of adding support for Julia 0.6. See commit messages.
The problem I ran into is an ambiguity related to https://github.com/JuliaArrays/StaticArrays.jl/blob/b935326703d2aab13a33efd4b71bac07f86ea376/src/convert.jl#L4:
I wasn't sure how to handle this. I guess this is an issue for any concrete
StaticArray
subtype whose only field is anotherStaticArray
.