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

Julia 0.6 support / updates to match StaticArrays 0.4.0 #25

Merged
merged 13 commits into from
Apr 3, 2017

Conversation

tkoolen
Copy link
Contributor

@tkoolen tkoolen commented Mar 25, 2017

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:

julia> using StaticArrays, Rotations

julia> m = eye(SMatrix{2, 2, Float32})
2×2 StaticArrays.SMatrix{2,2,Float32,4}:
 1.0  0.0
 0.0  1.0

julia> RotMatrix(m)
ERROR: MethodError: Rotations.RotMatrix{2,Float32,4}(::StaticArrays.SMatrix{2,2,Float32,4}) is ambiguous. Candidates:
  (::Type{Rotations.RotMatrix{N,T,L}})(mat) where {N, T, L} in Rotations at /Users/twan/code/julia/RigidBodyDynamics/v0.6/Rotations/src/core_types.jl:77
  (::Type{SA})(a::AbstractArray) where SA<:StaticArrays.StaticArray in StaticArrays at /Users/twan/code/julia/RigidBodyDynamics/v0.6/StaticArrays/src/convert.jl:4
Stacktrace:
 [1] Rotations.RotMatrix(::StaticArrays.SMatrix{2,2,Float32,4}) at /Users/twan/code/julia/RigidBodyDynamics/v0.6/Rotations/src/core_types.jl:77

I wasn't sure how to handle this. I guess this is an issue for any concrete StaticArray subtype whose only field is another StaticArray.


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
Copy link
Contributor

@andyferris andyferris Mar 25, 2017

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

Copy link
Contributor Author

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)


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

Copy link
Contributor

@andyferris andyferris Mar 25, 2017

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)

Copy link
Contributor

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...)

Copy link
Contributor Author

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.

@andyferris
Copy link
Contributor

Thanks @tkoolen - what I've seen so far looks good. This is really appreciated :)

@tkoolen
Copy link
Contributor Author

tkoolen commented Mar 27, 2017

The next issue is the convert methods for the Euler types. I've made some changes to RotX. Before making the same changes to all of the other Euler types, could you take a look?

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?

@tkoolen tkoolen changed the title Mindless part of adding Julia 0.6 support / updates to match StaticArrays master Julia 0.6 support / updates to match StaticArrays 0.4.0 Mar 30, 2017
@tkoolen
Copy link
Contributor Author

tkoolen commented Mar 30, 2017

I went ahead and made the same changes I made to RotX throughout. In doing so, I reduced the code duplication in euler_types.jl using some simple metaprogramming. I also worked around JuliaArrays/StaticArrays.jl#128.

@andyferris
Copy link
Contributor

You shouldn't need to work around JuliaArrays/StaticArrays.jl#128 - see JuliaArrays/StaticArrays.jl#130

@tkoolen
Copy link
Contributor Author

tkoolen commented Mar 31, 2017

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[:]
Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Member

@c42f c42f left a 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...
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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})
Copy link
Member

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 :-) ).

Copy link
Contributor Author

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?

Copy link
Member

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.

@c42f
Copy link
Member

c42f commented Apr 3, 2017

@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?

@tkoolen
Copy link
Contributor Author

tkoolen commented Apr 3, 2017

Ready to go in my opinion. There's no new StaticArrays tag yet, so the workaround is still needed for now.

@c42f
Copy link
Member

c42f commented Apr 3, 2017

Excellent.

I'm not super keen on dropping julia-0.5 support in Rotations before julia-0.6 is out... but given that StaticArrays is in a state of flux I guess we'd better just merge this and move forward :-)

@c42f c42f merged commit 1442562 into JuliaGeometry:master Apr 3, 2017
@tkoolen tkoolen deleted the tk-julia-0.6 branch April 3, 2017 02:00
@tkoolen
Copy link
Contributor Author

tkoolen commented Apr 3, 2017

Great, thanks!

@timholy
Copy link
Member

timholy commented Apr 11, 2017

Tag a new release? JuliaImages/ImageTransformations.jl#18

@timholy
Copy link
Member

timholy commented Apr 11, 2017

Oh, and many thanks, @tkoolen!

@tkoolen
Copy link
Contributor Author

tkoolen commented Apr 11, 2017

@timholy, see JuliaLang/METADATA.jl#8787.

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

Successfully merging this pull request may close these issues.

4 participants