Only partially relevant, but my general reaction to Euler angles is: don't do 
it, because of gimbal lock. https://github.com/forio/Quaternions.jl and 
https://github.com/timholy/AffineTransforms.jl
have algorithms that are not vulnerable to this problem.

Take this advice with a grain of salt, of course; they're still out there, and 
may be useful under some circumstances.

--Tim

On Tuesday, August 25, 2015 08:29:08 PM [email protected] wrote:
> Hi, everyone.
> 
> I've been tinkering with creating a package for dealing with Euler angles,
> using a very recent build of v0.4.  Rather than just rehash Matlab's
> functions, I wanted to take advantage of the type system, to learn more
> about parametric types and constructors.
> 
> I definitely want the Euler rotation sequence and the angles to be bound
> together.  One straightforward way to do this would of course be:
> 
> type EulerAngles{T <: Number}
>     seq::Int
>     angles::Vector{T}
> end
> 
> Which would work fine, but I'd end up with a huge if block for every valid
> sequence.  So I thought I'd try moving the sequence into the type
> definition.  I think I would declare the type like this:
> 
> type EulerAngles{T <: Number, s}
>     angles::Vector{T}
> end
> 
> But then I can't figure out the best way to provide constructors for this
> type.  What I want is something like this:
> 
> EulerAngles{321}([1.0, 2.0, 3.0])
> 
> But I can't figure out how to get this to work.  Is this kind of
> constructor even possible with the type I showed above?
> 
> I was able to get something very similar to work, by making functions that
> look like constructors with the sequence in their names, like this:
> 
> EulerAngles321([1.0, 2.0, 3.0])
> 
> Which works, but gives the impression that EulerAngles321 is actually a
> type.  But it seems that typealiases can't have constructors, and I get an
> error trying to define a typealias and a function with the same name.  Even
> with this limitation, though, this seems like an OK solution.
> 
> If I really wanted to have types with those names, I could have an abstract
> EulerAngles type, and then have concrete types like EulerAngles321.  But
> that seems like overkill (in terms of the number of types I'd create).
>  Though it would work.
> 
> Does anyone have any guidance on how to best approach this?
> 
> Thanks for the help!
> 
> Daniel

Reply via email to