Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Martin Ling]

Hi Hans,

Sorry, that is actually what I implemented, I just documented it
iincorrectly. I have just pushed an update to the README. Thanks for
pointing this out!


Martin

On Sun, Jul 31, 2011 at 07:57:58AM +0200, Hans Meine wrote:
> 
> Hi Martin,
> 
> I think it would be more useful if isfinite returned true if *all* elements 
> were finite.  (Opposite of isnan and isinf.)
> 
> HTH,
>   Hans
> 
> PS: did not check the complex dtype, hopefully that one's no different. 
> 
> (The above has been typed using a small on-screen keyboard, which may account 
> for any typos,  briefness or bad formatting.)
> 
> Am 16.07.2011 um 16:50 schrieb Martin Ling :
> 
> > Hi all,
> > 
> > I have just pushed a package to GitHub which adds a quaternion dtype to
> > NumPy: https://github.com/martinling/numpy_quaternion
> > 
> > Some backstory: on Wednesday I gave a talk at SciPy 2011 about an
> > inertial sensing simulation package I have been working on
> > (http://www.imusim.org/). One component I suggested might be reusable
> > from that code was the quaternion math implementation, written in
> > Cython. One of its features is a wrapper class for Nx4 NumPy arrays that
> > supports efficient operations using arrays of quaternion values.
> > 
> > Travis Oliphant suggested that a quaternion dtype would be a better
> > solution, and got me talking to Mark Weibe about this. With Mark's help
> > I completed this initial version at yesterday's sprint session.
> > 
> > Incidentally, how to do something like this isn't well documented and I
> > would have had little hope without both Mark's in-person help and his
> > previous code (for adding a half-precision float dtype) to refer to. I
> > don't know what the consensus is about whether people writing custom
> > dtypes is a desirable thing, but if it is then the process needs to be
> > made a lot easier. That said, the fact this is doable without patching
> > the numpy core at all is really, really nice.
> > 
> > Example usage:
> > 
>  import numpy as np
>  import quaternion
>  np.quaternion(1,0,0,0)
> > quaternion(1, 0, 0, 0)
>  q1 = np.quaternion(1,2,3,4)
>  q2 = np.quaternion(5,6,7,8)
>  q1 * q2
> > quaternion(-60, 12, 30, 24)
>  a = np.array([q1, q2])
>  a
> > array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)],
> >dtype=quaternion)
>  exp(a)
> > array([quaternion(1.69392, -0.78956, -1.18434, -1.57912),
> >quaternion(138.909, -25.6861, -29.9671, -34.2481)],
> >dtype=quaternion)
> > 
> > The following ufuncs are implemented:
> > add, subtract, multiply, divide, log, exp, power, negative, conjugate,
> > copysign, equal, not_equal, less, less_equal, isnan, isinf, isfinite,
> > absolute
> > 
> > Quaternion components are stored as doubles. The package could be extended
> > to support e.g. qfloat, qdouble, qlongdouble
> > 
> > Comparison operations follow the same lexicographic ordering as tuples.
> > 
> > The unary tests isnan, isinf and isfinite return true if they would
> > return true for any individual component.
> > 
> > Real types may be cast to quaternions, giving quaternions with zero for
> > all three imaginary components. Complex types may also be cast to
> > quaternions, with their single imaginary component becoming the first
> > imaginary component of the quaternion. Quaternions may not be cast to
> > real or complex types.
> > 
> > Comments very welcome. This is my first attempt at NumPy hacking :-)
> > 
> > 
> > Martin
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Friedrich Romstedt]

2011/7/29 Benjamin Root :
> I am starting to get very interested in this quaternion concept (and maybe
> how I could use it for mplot3d), but I have never come across it before
> (beyond the typical vector math that I am familiar with).  Can anybody
> recommend a good introductory resource to get me up to speed?

The time I learned it I used the Wikipedia article, apparently it
wasn't that bad that time I used it (haven't checked now).  But it
needs some hand-crafting to get into it.  In principle, if you
decompose the operation of Quaternions manually (which involves a bit
of algebra, but doable), then you'll see how beautifully it decomposes
the vector given in to create a local rotation plane, where it is
rotated just as in ordinary polar coordinates.

Friedrich
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Hans Meine]

Hi Martin,

I think it would be more useful if isfinite returned true if *all* elements 
were finite.  (Opposite of isnan and isinf.)

HTH,
  Hans

PS: did not check the complex dtype, hopefully that one's no different. 

(The above has been typed using a small on-screen keyboard, which may account 
for any typos,  briefness or bad formatting.)

Am 16.07.2011 um 16:50 schrieb Martin Ling :

> Hi all,
> 
> I have just pushed a package to GitHub which adds a quaternion dtype to
> NumPy: https://github.com/martinling/numpy_quaternion
> 
> Some backstory: on Wednesday I gave a talk at SciPy 2011 about an
> inertial sensing simulation package I have been working on
> (http://www.imusim.org/). One component I suggested might be reusable
> from that code was the quaternion math implementation, written in
> Cython. One of its features is a wrapper class for Nx4 NumPy arrays that
> supports efficient operations using arrays of quaternion values.
> 
> Travis Oliphant suggested that a quaternion dtype would be a better
> solution, and got me talking to Mark Weibe about this. With Mark's help
> I completed this initial version at yesterday's sprint session.
> 
> Incidentally, how to do something like this isn't well documented and I
> would have had little hope without both Mark's in-person help and his
> previous code (for adding a half-precision float dtype) to refer to. I
> don't know what the consensus is about whether people writing custom
> dtypes is a desirable thing, but if it is then the process needs to be
> made a lot easier. That said, the fact this is doable without patching
> the numpy core at all is really, really nice.
> 
> Example usage:
> 
 import numpy as np
 import quaternion
 np.quaternion(1,0,0,0)
> quaternion(1, 0, 0, 0)
 q1 = np.quaternion(1,2,3,4)
 q2 = np.quaternion(5,6,7,8)
 q1 * q2
> quaternion(-60, 12, 30, 24)
 a = np.array([q1, q2])
 a
> array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)],
>dtype=quaternion)
 exp(a)
> array([quaternion(1.69392, -0.78956, -1.18434, -1.57912),
>quaternion(138.909, -25.6861, -29.9671, -34.2481)],
>dtype=quaternion)
> 
> The following ufuncs are implemented:
> add, subtract, multiply, divide, log, exp, power, negative, conjugate,
> copysign, equal, not_equal, less, less_equal, isnan, isinf, isfinite,
> absolute
> 
> Quaternion components are stored as doubles. The package could be extended
> to support e.g. qfloat, qdouble, qlongdouble
> 
> Comparison operations follow the same lexicographic ordering as tuples.
> 
> The unary tests isnan, isinf and isfinite return true if they would
> return true for any individual component.
> 
> Real types may be cast to quaternions, giving quaternions with zero for
> all three imaginary components. Complex types may also be cast to
> quaternions, with their single imaginary component becoming the first
> imaginary component of the quaternion. Quaternions may not be cast to
> real or complex types.
> 
> Comments very welcome. This is my first attempt at NumPy hacking :-)
> 
> 
> Martin
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Stéfan van der Walt]

Hi Ben

On Fri, Jul 29, 2011 at 12:57 PM, Benjamin Root  wrote:
> I am starting to get very interested in this quaternion concept (and maybe
> how I could use it for mplot3d), but I have never come across it before
> (beyond the typical vector math that I am familiar with).  Can anybody
> recommend a good introductory resource to get me up to speed?

I heard that Ch. 11 of Roger Penrose's "Road to Reality" explain
quaternions well.

11 Hypercomplex numbers
11.1 The algebra of quaternions
11.2 The physical role of quaternions?
11.3 Geometry of quaternions
11.4 How to compose rotations
11.5 Clifford algebras
11.6 Grassmann algebras

Regards
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Mark Wiebe]

On Fri, Jul 29, 2011 at 2:57 PM, Benjamin Root  wrote:

>
>
> On Fri, Jul 29, 2011 at 2:52 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jul 29, 2011 at 11:07 AM, Martin Ling wrote:
>>
>>> On Fri, Jul 29, 2011 at 09:14:00AM -0600, Charles R Harris wrote:
>>> >
>>> >Well, if the shuttle used a different definition then it was out
>>> there
>>> >somewhere. The history of quaternions is rather involved and mixed
>>> up with
>>> >vectors, so it may be the case that there were different
>>> conventions.
>>>
>>> My point is that these are conventions of co-ordinate frame, not of
>>> different representations of quaternions themselves. There's no two
>>> "handednesses" of quaternions to support. There are an infinte number of
>>> co-ordinate frames, and a quaternion can be interpreted as a rotation in
>>> any one of them. It's a matter of interpretation, not calculation.
>>>
>>> >It might also be that the difference was between vector and
>>> >coordinate rotations, but it is hard to tell without knowing how
>>> >the code actually made use of the results.
>>>
>>> Indeed, this is the other place the duality shows up. If q is the
>>> rotation of frame A relative to frame B, then a vector v in A appears
>>> in B as:
>>>
>>>v' = q * v * q.conjugate
>>>
>>> while a vector u in B appears in A as:
>>>
>>>u' = q.conjugate * u * q
>>>
>>> The former is often thought of as 'rotating the vector' versus the
>>> second as 'rotating the co-ordinate frame', but both are actually the
>>> same operation performed using a different choice of frames.
>>>
>>>
>> They are different, a vector is an element of a vector space independent
>> of coordinate frames, coordinate frames are a collection of functions from
>> the vector space to scalars. Operationally, rotating vectors is a map from
>> the vector space onto itself, however the  coordinates happen to be the same
>> when the inverse rotation is applied to the coordinate frame, it's pretty
>> much the definition of coordinate rotation. But the concepts aren't the
>> same. The similarity between the operations is how covariant vectors got to
>> be called contravariant tensors, the early workers in the field dealt with
>> the coordinates.
>>
>> But that is all to the side ;) I'm wondering about the history of the
>> 'versor' object and in which fields it was used.
>>
>> Chuck
>>
>>
> I am starting to get very interested in this quaternion concept (and maybe
> how I could use it for mplot3d), but I have never come across it before
> (beyond the typical vector math that I am familiar with).  Can anybody
> recommend a good introductory resource to get me up to speed?
>

One resource is the Visualizing Quaternions book, and an earlier paper:

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.7438

-Mark


>
> Thanks,
> Ben Root
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Charles R Harris]

On Fri, Jul 29, 2011 at 1:57 PM, Benjamin Root  wrote:

>
>
> On Fri, Jul 29, 2011 at 2:52 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jul 29, 2011 at 11:07 AM, Martin Ling wrote:
>>
>>> On Fri, Jul 29, 2011 at 09:14:00AM -0600, Charles R Harris wrote:
>>> >
>>> >Well, if the shuttle used a different definition then it was out
>>> there
>>> >somewhere. The history of quaternions is rather involved and mixed
>>> up with
>>> >vectors, so it may be the case that there were different
>>> conventions.
>>>
>>> My point is that these are conventions of co-ordinate frame, not of
>>> different representations of quaternions themselves. There's no two
>>> "handednesses" of quaternions to support. There are an infinte number of
>>> co-ordinate frames, and a quaternion can be interpreted as a rotation in
>>> any one of them. It's a matter of interpretation, not calculation.
>>>
>>> >It might also be that the difference was between vector and
>>> >coordinate rotations, but it is hard to tell without knowing how
>>> >the code actually made use of the results.
>>>
>>> Indeed, this is the other place the duality shows up. If q is the
>>> rotation of frame A relative to frame B, then a vector v in A appears
>>> in B as:
>>>
>>>v' = q * v * q.conjugate
>>>
>>> while a vector u in B appears in A as:
>>>
>>>u' = q.conjugate * u * q
>>>
>>> The former is often thought of as 'rotating the vector' versus the
>>> second as 'rotating the co-ordinate frame', but both are actually the
>>> same operation performed using a different choice of frames.
>>>
>>>
>> They are different, a vector is an element of a vector space independent
>> of coordinate frames, coordinate frames are a collection of functions from
>> the vector space to scalars. Operationally, rotating vectors is a map from
>> the vector space onto itself, however the  coordinates happen to be the same
>> when the inverse rotation is applied to the coordinate frame, it's pretty
>> much the definition of coordinate rotation. But the concepts aren't the
>> same. The similarity between the operations is how covariant vectors got to
>> be called contravariant tensors, the early workers in the field dealt with
>> the coordinates.
>>
>> But that is all to the side ;) I'm wondering about the history of the
>> 'versor' object and in which fields it was used.
>>
>> Chuck
>>
>>
> I am starting to get very interested in this quaternion concept (and maybe
> how I could use it for mplot3d), but I have never come across it before
> (beyond the typical vector math that I am familiar with).  Can anybody
> recommend a good introductory resource to get me up to speed?
>
>
Well, there is Robert's
recommendation,
which looks sort of like a reprise of Klein & Sommerfeld's Theory of
the 
Top,
but there are lots of resources out there for the application of quaternions
to graphics. The main advantage of quaternions is that they provide a simply
connected representation of rotations, there isn't a jump between rotations
of +/- 180 degrees. Also, since they exist on the surface of a 4 dimensional
ball you can interpolate rotations by a path on that surface, or even
approximate same by secant lines between nearby points.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Benjamin Root]

On Fri, Jul 29, 2011 at 2:52 PM, Charles R Harris  wrote:

>
>
> On Fri, Jul 29, 2011 at 11:07 AM, Martin Ling wrote:
>
>> On Fri, Jul 29, 2011 at 09:14:00AM -0600, Charles R Harris wrote:
>> >
>> >Well, if the shuttle used a different definition then it was out
>> there
>> >somewhere. The history of quaternions is rather involved and mixed up
>> with
>> >vectors, so it may be the case that there were different conventions.
>>
>> My point is that these are conventions of co-ordinate frame, not of
>> different representations of quaternions themselves. There's no two
>> "handednesses" of quaternions to support. There are an infinte number of
>> co-ordinate frames, and a quaternion can be interpreted as a rotation in
>> any one of them. It's a matter of interpretation, not calculation.
>>
>> >It might also be that the difference was between vector and
>> >coordinate rotations, but it is hard to tell without knowing how
>> >the code actually made use of the results.
>>
>> Indeed, this is the other place the duality shows up. If q is the
>> rotation of frame A relative to frame B, then a vector v in A appears
>> in B as:
>>
>>v' = q * v * q.conjugate
>>
>> while a vector u in B appears in A as:
>>
>>u' = q.conjugate * u * q
>>
>> The former is often thought of as 'rotating the vector' versus the
>> second as 'rotating the co-ordinate frame', but both are actually the
>> same operation performed using a different choice of frames.
>>
>>
> They are different, a vector is an element of a vector space independent of
> coordinate frames, coordinate frames are a collection of functions from the
> vector space to scalars. Operationally, rotating vectors is a map from the
> vector space onto itself, however the  coordinates happen to be the same
> when the inverse rotation is applied to the coordinate frame, it's pretty
> much the definition of coordinate rotation. But the concepts aren't the
> same. The similarity between the operations is how covariant vectors got to
> be called contravariant tensors, the early workers in the field dealt with
> the coordinates.
>
> But that is all to the side ;) I'm wondering about the history of the
> 'versor' object and in which fields it was used.
>
> Chuck
>
>
I am starting to get very interested in this quaternion concept (and maybe
how I could use it for mplot3d), but I have never come across it before
(beyond the typical vector math that I am familiar with).  Can anybody
recommend a good introductory resource to get me up to speed?

Thanks,
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Charles R Harris]

On Fri, Jul 29, 2011 at 11:07 AM, Martin Ling  wrote:

> On Fri, Jul 29, 2011 at 09:14:00AM -0600, Charles R Harris wrote:
> >
> >Well, if the shuttle used a different definition then it was out there
> >somewhere. The history of quaternions is rather involved and mixed up
> with
> >vectors, so it may be the case that there were different conventions.
>
> My point is that these are conventions of co-ordinate frame, not of
> different representations of quaternions themselves. There's no two
> "handednesses" of quaternions to support. There are an infinte number of
> co-ordinate frames, and a quaternion can be interpreted as a rotation in
> any one of them. It's a matter of interpretation, not calculation.
>
> >It might also be that the difference was between vector and
> >coordinate rotations, but it is hard to tell without knowing how
> >the code actually made use of the results.
>
> Indeed, this is the other place the duality shows up. If q is the
> rotation of frame A relative to frame B, then a vector v in A appears
> in B as:
>
>v' = q * v * q.conjugate
>
> while a vector u in B appears in A as:
>
>u' = q.conjugate * u * q
>
> The former is often thought of as 'rotating the vector' versus the
> second as 'rotating the co-ordinate frame', but both are actually the
> same operation performed using a different choice of frames.
>
>
They are different, a vector is an element of a vector space independent of
coordinate frames, coordinate frames are a collection of functions from the
vector space to scalars. Operationally, rotating vectors is a map from the
vector space onto itself, however the  coordinates happen to be the same
when the inverse rotation is applied to the coordinate frame, it's pretty
much the definition of coordinate rotation. But the concepts aren't the
same. The similarity between the operations is how covariant vectors got to
be called contravariant tensors, the early workers in the field dealt with
the coordinates.

But that is all to the side ;) I'm wondering about the history of the
'versor' object and in which fields it was used.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Martin Ling]

On Fri, Jul 29, 2011 at 09:14:00AM -0600, Charles R Harris wrote:
> 
>Well, if the shuttle used a different definition then it was out there
>somewhere. The history of quaternions is rather involved and mixed up with
>vectors, so it may be the case that there were different conventions.

My point is that these are conventions of co-ordinate frame, not of
different representations of quaternions themselves. There's no two
"handednesses" of quaternions to support. There are an infinte number of
co-ordinate frames, and a quaternion can be interpreted as a rotation in
any one of them. It's a matter of interpretation, not calculation.

>It might also be that the difference was between vector and
>coordinate rotations, but it is hard to tell without knowing how
>the code actually made use of the results.

Indeed, this is the other place the duality shows up. If q is the
rotation of frame A relative to frame B, then a vector v in A appears
in B as:

v' = q * v * q.conjugate

while a vector u in B appears in A as:

u' = q.conjugate * u * q

The former is often thought of as 'rotating the vector' versus the
second as 'rotating the co-ordinate frame', but both are actually the
same operation performed using a different choice of frames.


Martin
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Charles R Harris]

On Fri, Jul 29, 2011 at 9:03 AM, Martin Ling  wrote:

> On Thu, Jul 28, 2011 at 09:48:29PM -0500, Robert Love wrote:
> >
> > Quaternions have a "handedness" or a sign convention.  The recently
> > departed Space Shuttle used a Left versor convention while most
> > things, including Space Station, use the right versor convention, in
> > their flight software.  Made for frequent confusion.
> >
> > Let me see if I can illustrate by showing the functions I use for
> > converting a matrix to a quaternion.
> >
> > [snip]
>
> OK, the difference here is between quaternion conjugates. Your two
> matrix-to-quaternion functions return the conjugate of each other, and
> one of your rotate-vector-by-quaternion functions uses the conjugate of
> the quaternion.
>
> When quaternions are used to represent rotations, quaternion conjugates
> represent "opposite" rotations.
>
> E.g. if you have two spacecraft A and B and are considering the rotation
> between them, you can describe this as the rotation from A->B or as the
> rotation from B->A. The two quaternions will be the conjugate of each
> other.
>
> Similarly, if two systems describe the same rotation on the same axes
> but one defines rotation using the right-hand rule and the other the
> left-hand rule, their two quaternions will be the conjugate of each
> other.
>
> What this is all about is a matter of what co-ordinate frames you choose
> to interpret things in, not something about a "handedness" of quaternions.
> Quaternions themselves do not have a "handedness", they are just numbers.
>
> If you have systems using opposite co-ordinate frames, or indeed any
> other differing co-ordinate systems, then the best approach is to
> explicitly convert everything into a single chosen co-ordinate frame
> before doing any calculations. Don't entangle your representation
> changes (e.g. matrix to quaternion) and transforms (e.g. rotate vector)
> with co-ordinate frame changes.
>
> Your 'left versor' functions are the correct ones. Your 'right versor'
> functions create and use the opposite rotations. I don't know where you
> got this 'left versor' and 'right versor' terminology from. This thread
> seems to be the only hit for these terms together on Google.
>
>
Well, if the shuttle used a different definition then it was out there
somewhere. The history of quaternions is rather involved and mixed up with
vectors, so it may be the case that there were different conventions. It
might also be that the difference was between vector and coordinate
rotations, but it is hard to tell without knowing how the code actually made
use of the results. The left/right versor terminology is new to me also.
Maybe it's like economists never admitting to knowing the word 'derivative'
as in calculus, it's all marginal this and marginal that.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Martin Ling]

On Thu, Jul 28, 2011 at 09:48:29PM -0500, Robert Love wrote:
> 
> Quaternions have a "handedness" or a sign convention.  The recently
> departed Space Shuttle used a Left versor convention while most
> things, including Space Station, use the right versor convention, in
> their flight software.  Made for frequent confusion.
> 
> Let me see if I can illustrate by showing the functions I use for
> converting a matrix to a quaternion.
> 
> [snip]

OK, the difference here is between quaternion conjugates. Your two
matrix-to-quaternion functions return the conjugate of each other, and
one of your rotate-vector-by-quaternion functions uses the conjugate of
the quaternion.

When quaternions are used to represent rotations, quaternion conjugates
represent "opposite" rotations.

E.g. if you have two spacecraft A and B and are considering the rotation
between them, you can describe this as the rotation from A->B or as the
rotation from B->A. The two quaternions will be the conjugate of each
other.

Similarly, if two systems describe the same rotation on the same axes
but one defines rotation using the right-hand rule and the other the
left-hand rule, their two quaternions will be the conjugate of each
other.

What this is all about is a matter of what co-ordinate frames you choose
to interpret things in, not something about a "handedness" of quaternions.
Quaternions themselves do not have a "handedness", they are just numbers.

If you have systems using opposite co-ordinate frames, or indeed any
other differing co-ordinate systems, then the best approach is to
explicitly convert everything into a single chosen co-ordinate frame
before doing any calculations. Don't entangle your representation
changes (e.g. matrix to quaternion) and transforms (e.g. rotate vector)
with co-ordinate frame changes.

Your 'left versor' functions are the correct ones. Your 'right versor'
functions create and use the opposite rotations. I don't know where you
got this 'left versor' and 'right versor' terminology from. This thread
seems to be the only hit for these terms together on Google.


Martin
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Charles R Harris]

On Thu, Jul 28, 2011 at 8:48 PM, Robert Love wrote:

>
> On Jul 28, 2011, at 7:42 AM, Martin Ling wrote:
>
> > On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote:
> >>
> >> To use quaternions I find I often need conversion to/from matrices and
> >> to/from Euler angles.  Will you add that functionality?
> >
> > Yes, I intend to. Note that these conversions are already available in
> > the standalone (non-dtype) implementation in imusim.maths.quaternions:
> >
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix
> >
> > I should do a new release though - the Euler methods there only support
> > ZYX and ZXY order conversions, my development version supports any order.
> >
> >> Will you handle the left versor and right versor versions?
> >
> > I don't know what this means. Please enlighten me and I'll be happy to
> > try! I thought a 'right versor' was a unit quaternion representing an
> > angle of 90 degrees (as in 'right angle') - I don't see what a 'left'
> > one would be.
> >
>
> Quaternions have a "handedness" or a sign convention.  The recently
> departed Space Shuttle used a Left versor convention while most things,
> including Space Station, use the right versor convention, in their flight
> software.  Made for frequent confusion.
>
> Let me see if I can illustrate by showing the functions I use for
> converting a matrix to a quaternion.
>
>
> def Quaternion_Of(m):
>"""
>Returns a quaternion in the right versor sense.
>"""
>
>q = N.zeros(4,float)
>
>q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2])
>
>q04_inv = 1.0/(4.0*q[0])
>q[1] = (m[1,2] - m[2,1])*q04_inv
>q[2] = (m[2,0] - m[0,2])*q04_inv
>q[3] = (m[0,1] - m[1,0])*q04_inv
>
>return q
>
>
>
> def Quaternion_Of(m):
>"""
>Returns a quaternion in the left versor sense.
>"""
>
>q = N.zeros(4,float)
>
>q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2])
>
>q04_inv = 1.0/(4.0*q[0])
>q[1] = (m[2,1] - m[1,2])*q04_inv
>q[2] = (m[0,2] - m[2,0])*q04_inv
>q[3] = (m[1,0] - m[0,1])*q04_inv
>
>return q
>
>
> Or transforming a vector using the different conventions.
>
>
> def Transform(q,v):
>"""
>Returns the vector part of q*vq which transforms v from one
>coordinate system to another.  Right Versor
>"""
>u = Q.Vector_Part(q)
>return 2.0*(q[0]*N.cross(v,u) +
>N.dot(v,u)*u +
>(q[0]*q[0] - 0.5)*v)
>
>
> def Transform(q,v):
>"""
>Returns the vector part of q*vq which transforms v from one
>coordinate system to another.  Left Versor
>"""
>u = Q.Vector_Part(q)
>return 2.0*(q[0]*N.cross(u,v) +
>N.dot(u,v)*u +
>(q[0]*q[0] - 0.5)*v)
>
>
So they differ in whether the rotation about the direction of the vector
part is left handed or right handed?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Charles R Harris]

On Thu, Jul 28, 2011 at 8:48 PM, Robert Love wrote:

>
> On Jul 28, 2011, at 7:42 AM, Martin Ling wrote:
>
> > On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote:
> >>
> >> To use quaternions I find I often need conversion to/from matrices and
> >> to/from Euler angles.  Will you add that functionality?
> >
> > Yes, I intend to. Note that these conversions are already available in
> > the standalone (non-dtype) implementation in imusim.maths.quaternions:
> >
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix
> >
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix
> >
> > I should do a new release though - the Euler methods there only support
> > ZYX and ZXY order conversions, my development version supports any order.
> >
> >> Will you handle the left versor and right versor versions?
> >
> > I don't know what this means. Please enlighten me and I'll be happy to
> > try! I thought a 'right versor' was a unit quaternion representing an
> > angle of 90 degrees (as in 'right angle') - I don't see what a 'left'
> > one would be.
> >
>
> Quaternions have a "handedness" or a sign convention.  The recently
> departed Space Shuttle used a Left versor convention while most things,
> including Space Station, use the right versor convention, in their flight
> software.  Made for frequent confusion.
>
> Let me see if I can illustrate by showing the functions I use for
> converting a matrix to a quaternion.
>
>
> def Quaternion_Of(m):
>"""
>Returns a quaternion in the right versor sense.
>"""
>
>q = N.zeros(4,float)
>
>q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2])
>
>q04_inv = 1.0/(4.0*q[0])
>q[1] = (m[1,2] - m[2,1])*q04_inv
>q[2] = (m[2,0] - m[0,2])*q04_inv
>q[3] = (m[0,1] - m[1,0])*q04_inv
>
>return q
>
>
>
> def Quaternion_Of(m):
>"""
>Returns a quaternion in the left versor sense.
>"""
>
>q = N.zeros(4,float)
>
>q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2])
>
>q04_inv = 1.0/(4.0*q[0])
>q[1] = (m[2,1] - m[1,2])*q04_inv
>q[2] = (m[0,2] - m[2,0])*q04_inv
>q[3] = (m[1,0] - m[0,1])*q04_inv
>
>return q
>
>
> Or transforming a vector using the different conventions.
>
>
> def Transform(q,v):
>"""
>Returns the vector part of q*vq which transforms v from one
>coordinate system to another.  Right Versor
>"""
>u = Q.Vector_Part(q)
>return 2.0*(q[0]*N.cross(v,u) +
>N.dot(v,u)*u +
>(q[0]*q[0] - 0.5)*v)
>
>
> def Transform(q,v):
>"""
>Returns the vector part of q*vq which transforms v from one
>coordinate system to another.  Left Versor
>"""
>u = Q.Vector_Part(q)
>return 2.0*(q[0]*N.cross(u,v) +
>N.dot(u,v)*u +
>(q[0]*q[0] - 0.5)*v)
>
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Robert Kern]

On Thu, Jul 28, 2011 at 21:48, Robert Love  wrote:
>
> On Jul 28, 2011, at 7:42 AM, Martin Ling wrote:
>
>> On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote:
>>>
>>> To use quaternions I find I often need conversion to/from matrices and
>>> to/from Euler angles.  Will you add that functionality?
>>
>> Yes, I intend to. Note that these conversions are already available in
>> the standalone (non-dtype) implementation in imusim.maths.quaternions:
>>
>> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler
>> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler
>> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix
>> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix
>>
>> I should do a new release though - the Euler methods there only support
>> ZYX and ZXY order conversions, my development version supports any order.
>>
>>> Will you handle the left versor and right versor versions?
>>
>> I don't know what this means. Please enlighten me and I'll be happy to
>> try! I thought a 'right versor' was a unit quaternion representing an
>> angle of 90 degrees (as in 'right angle') - I don't see what a 'left'
>> one would be.
>>
>
> Quaternions have a "handedness" or a sign convention.  The recently departed 
> Space Shuttle used a Left versor convention while most things, including 
> Space Station, use the right versor convention, in their flight software.  
> Made for frequent confusion.

For what it's worth, I have found this paper by James Diebel to be the
most complete listing of all of the different conventions and
conversions amongst quaternions, Euler angles, and rotation vectors:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.110.5134

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Robert Love]

On Jul 28, 2011, at 7:42 AM, Martin Ling wrote:

> On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote:
>> 
>> To use quaternions I find I often need conversion to/from matrices and
>> to/from Euler angles.  Will you add that functionality?
> 
> Yes, I intend to. Note that these conversions are already available in
> the standalone (non-dtype) implementation in imusim.maths.quaternions:
> 
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix
> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix
> 
> I should do a new release though - the Euler methods there only support
> ZYX and ZXY order conversions, my development version supports any order.
> 
>> Will you handle the left versor and right versor versions?
> 
> I don't know what this means. Please enlighten me and I'll be happy to
> try! I thought a 'right versor' was a unit quaternion representing an
> angle of 90 degrees (as in 'right angle') - I don't see what a 'left'
> one would be.
> 

Quaternions have a "handedness" or a sign convention.  The recently departed 
Space Shuttle used a Left versor convention while most things, including Space 
Station, use the right versor convention, in their flight software.  Made for 
frequent confusion.

Let me see if I can illustrate by showing the functions I use for converting a 
matrix to a quaternion.


def Quaternion_Of(m):
"""
Returns a quaternion in the right versor sense.
"""

q = N.zeros(4,float)

q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2])

q04_inv = 1.0/(4.0*q[0])
q[1] = (m[1,2] - m[2,1])*q04_inv
q[2] = (m[2,0] - m[0,2])*q04_inv
q[3] = (m[0,1] - m[1,0])*q04_inv

return q



def Quaternion_Of(m):
"""
Returns a quaternion in the left versor sense.
"""

q = N.zeros(4,float)

q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2])

q04_inv = 1.0/(4.0*q[0])
q[1] = (m[2,1] - m[1,2])*q04_inv
q[2] = (m[0,2] - m[2,0])*q04_inv
q[3] = (m[1,0] - m[0,1])*q04_inv

return q


Or transforming a vector using the different conventions.


def Transform(q,v):
"""
Returns the vector part of q*vq which transforms v from one
coordinate system to another.  Right Versor
"""
u = Q.Vector_Part(q)
return 2.0*(q[0]*N.cross(v,u) +
N.dot(v,u)*u +
(q[0]*q[0] - 0.5)*v)


def Transform(q,v):
"""
Returns the vector part of q*vq which transforms v from one
coordinate system to another.  Left Versor
"""
u = Q.Vector_Part(q)
return 2.0*(q[0]*N.cross(u,v) +
N.dot(u,v)*u +
(q[0]*q[0] - 0.5)*v)





___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Martin Ling]

On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote:
> 
> To use quaternions I find I often need conversion to/from matrices and
> to/from Euler angles.  Will you add that functionality?

Yes, I intend to. Note that these conversions are already available in
the standalone (non-dtype) implementation in imusim.maths.quaternions:

http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler
http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler
http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix
http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix

I should do a new release though - the Euler methods there only support
ZYX and ZXY order conversions, my development version supports any order.

> Will you handle the left versor and right versor versions?

I don't know what this means. Please enlighten me and I'll be happy to
try! I thought a 'right versor' was a unit quaternion representing an
angle of 90 degrees (as in 'right angle') - I don't see what a 'left'
one would be.


Martin
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Robert Love]

To use quaternions I find I often need conversion to/from matrices and to/from 
Euler angles.  Will you add that functionality?  Will you handle the left 
versor and right versor versions?

I have a set of pure python code I've sketched out for my needs (aerospace) but 
would be happy to have an intrinsic Numpy solution.


On Jul 16, 2011, at 9:50 AM, Martin Ling wrote:

> Hi all,
> 
> I have just pushed a package to GitHub which adds a quaternion dtype to
> NumPy: https://github.com/martinling/numpy_quaternion
> 
> Some backstory: on Wednesday I gave a talk at SciPy 2011 about an
> inertial sensing simulation package I have been working on
> (http://www.imusim.org/). One component I suggested might be reusable
> from that code was the quaternion math implementation, written in
> Cython. One of its features is a wrapper class for Nx4 NumPy arrays that
> supports efficient operations using arrays of quaternion values.
> 
> Travis Oliphant suggested that a quaternion dtype would be a better
> solution, and got me talking to Mark Weibe about this. With Mark's help
> I completed this initial version at yesterday's sprint session.
> 
> Incidentally, how to do something like this isn't well documented and I
> would have had little hope without both Mark's in-person help and his
> previous code (for adding a half-precision float dtype) to refer to. I
> don't know what the consensus is about whether people writing custom
> dtypes is a desirable thing, but if it is then the process needs to be
> made a lot easier. That said, the fact this is doable without patching
> the numpy core at all is really, really nice.
> 
> Example usage:
> 
 import numpy as np
 import quaternion
 np.quaternion(1,0,0,0)
> quaternion(1, 0, 0, 0)
 q1 = np.quaternion(1,2,3,4)
 q2 = np.quaternion(5,6,7,8)
 q1 * q2
> quaternion(-60, 12, 30, 24)
 a = np.array([q1, q2])
 a
> array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)],
>   dtype=quaternion)
 exp(a)
> array([quaternion(1.69392, -0.78956, -1.18434, -1.57912),
>quaternion(138.909, -25.6861, -29.9671, -34.2481)],
>   dtype=quaternion)
> 
> The following ufuncs are implemented:
> add, subtract, multiply, divide, log, exp, power, negative, conjugate,
> copysign, equal, not_equal, less, less_equal, isnan, isinf, isfinite,
> absolute
> 
> Quaternion components are stored as doubles. The package could be extended
> to support e.g. qfloat, qdouble, qlongdouble
> 
> Comparison operations follow the same lexicographic ordering as tuples.
> 
> The unary tests isnan, isinf and isfinite return true if they would
> return true for any individual component.
> 
> Real types may be cast to quaternions, giving quaternions with zero for
> all three imaginary components. Complex types may also be cast to
> quaternions, with their single imaginary component becoming the first
> imaginary component of the quaternion. Quaternions may not be cast to
> real or complex types.
> 
> Comments very welcome. This is my first attempt at NumPy hacking :-)
> 
> 
> Martin
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Martin Ling]

On Sun, Jul 17, 2011 at 05:52:19PM +0200, Ralf Gommers wrote:
> 
>Looks very interesting.
> 
>One thing that is surprising to me is that the quaternion dtype is
>inserted in to the numpy namespace. For dtypes that are planned to be
>integrated with numpy later on perhaps this makes sense, but in general
>this doesn't look right I think. Can you explain your reasoning to do it
>like this?

To be honest I didn't think about it a great deal; the basic glue code
of the package was copied directly from Mark Weibe's numpy_half module.

In retrospect, the rationale is that I would like to see this dtype
integrated into NumPy, so the implementation aims to show exactly what
that would look like to the user. I would have written this as a patch
to NumPy had Mark not shown me it was possible to write it separately.

In the general case I would agree with you that application-specific
dtypes should not go into the numpy namespace. I think this is a
sufficiently general thing that it would be worth including there - it's
just another sort of number, after all. That said, I would have no major
objections to this being a separate package and not touching the numpy
namespace. The key thing is just that it's usable as a dtype.

However, if this is going to be a separate package then I'd like to be
sure that it's not going to be broken by internal changes to NumPy in
the future. At present there is no official documentation of how to
write an external dtype.


Martin
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Martin Ling]

On Sat, Jul 16, 2011 at 08:16:44PM -0400, Anne Archibald wrote:
> The next interesting question is, how well does scipy.interpolate deal
> with them? For really good rotational paths I seem to recall you want
> specialized splines, but simply interpolating in the quaternion domain
> is not a bad quick and dirty approach.

Hi Anne,

Actually that's next on my list.

The most commonly used quaternion interpolation algorithm is Ken
Shoemake's SLERP. There is an improved one called SQUAD which is
C^1-continuous, i.e defines continuous angular velocities as well as
just rotations.

For the inertial sensing simulator I mentioned we needed C^2
continuitiy, so we implemented the quaternion B-spline algorithm from:

M-J Kim, M-S Kim and S Y Shin, "A General Construction Scheme for Unit
Quaternion Curves with Simple High Order Derivatives, in "Proceedings
of the 22nd Annual Conference on Computer Graphics and Interactive
Techniques (SIG-GRAPH’95)", pp. 369-376, ACM, 1995.

At the moment this uses our Cython-based quaternion library, but my plan
once the quaternion dtype is nailed down would be to rewrite these
interpolators to use the dtype, and submit the result to
scipy.interpolate.


Martin
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Ralf Gommers]

On Sat, Jul 16, 2011 at 4:50 PM, Martin Ling  wrote:

> Hi all,
>
> I have just pushed a package to GitHub which adds a quaternion dtype to
> NumPy: https://github.com/martinling/numpy_quaternion
>
> Some backstory: on Wednesday I gave a talk at SciPy 2011 about an
> inertial sensing simulation package I have been working on
> (http://www.imusim.org/). One component I suggested might be reusable
> from that code was the quaternion math implementation, written in
> Cython. One of its features is a wrapper class for Nx4 NumPy arrays that
> supports efficient operations using arrays of quaternion values.
>
> Travis Oliphant suggested that a quaternion dtype would be a better
> solution, and got me talking to Mark Weibe about this. With Mark's help
> I completed this initial version at yesterday's sprint session.
>
> Incidentally, how to do something like this isn't well documented and I
> would have had little hope without both Mark's in-person help and his
> previous code (for adding a half-precision float dtype) to refer to. I
> don't know what the consensus is about whether people writing custom
> dtypes is a desirable thing, but if it is then the process needs to be
> made a lot easier. That said, the fact this is doable without patching
> the numpy core at all is really, really nice.
>
> Example usage:
>
>  >>> import numpy as np
>  >>> import quaternion
>  >>> np.quaternion(1,0,0,0)
>  quaternion(1, 0, 0, 0)
>  >>> q1 = np.quaternion(1,2,3,4)
>  >>> q2 = np.quaternion(5,6,7,8)
>  >>> q1 * q2
>  quaternion(-60, 12, 30, 24)
>  >>> a = np.array([q1, q2])
>  >>> a
>  array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)],
>dtype=quaternion)
>  >>> exp(a)
>  array([quaternion(1.69392, -0.78956, -1.18434, -1.57912),
>quaternion(138.909, -25.6861, -29.9671, -34.2481)],
>dtype=quaternion)
>
> The following ufuncs are implemented:
>  add, subtract, multiply, divide, log, exp, power, negative, conjugate,
>  copysign, equal, not_equal, less, less_equal, isnan, isinf, isfinite,
>  absolute
>
> Quaternion components are stored as doubles. The package could be extended
> to support e.g. qfloat, qdouble, qlongdouble
>
> Comparison operations follow the same lexicographic ordering as tuples.
>
> The unary tests isnan, isinf and isfinite return true if they would
> return true for any individual component.
>
> Real types may be cast to quaternions, giving quaternions with zero for
> all three imaginary components. Complex types may also be cast to
> quaternions, with their single imaginary component becoming the first
> imaginary component of the quaternion. Quaternions may not be cast to
> real or complex types.
>
> Comments very welcome. This is my first attempt at NumPy hacking :-)
>
> Looks very interesting.

One thing that is surprising to me is that the quaternion dtype is inserted
in to the numpy namespace. For dtypes that are planned to be integrated with
numpy later on perhaps this makes sense, but in general this doesn't look
right I think. Can you explain your reasoning to do it like this?

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Anne Archibald]

What a useful package! Apart from helping all the people who know they
need quaternions, this package removes one major family of use cases
for vectorized small-matrix operations, namely, 3D rotations.
Quaternions are the canonical way to represent orientation and
rotation in three dimensions, and their multiplication gives (with
some fiddling) composition of rotations. The next interesting question
is, how well does scipy.interpolate deal with them? For really good
rotational paths I seem to recall you want specialized splines, but
simply interpolating in the quaternion domain is not a bad quick and
dirty approach.

Anne (now awaiting octonions, though I've never heard of a practical
use for them)

On 16 July 2011 10:50, Martin Ling  wrote:
> Hi all,
>
> I have just pushed a package to GitHub which adds a quaternion dtype to
> NumPy: https://github.com/martinling/numpy_quaternion
>
> Some backstory: on Wednesday I gave a talk at SciPy 2011 about an
> inertial sensing simulation package I have been working on
> (http://www.imusim.org/). One component I suggested might be reusable
> from that code was the quaternion math implementation, written in
> Cython. One of its features is a wrapper class for Nx4 NumPy arrays that
> supports efficient operations using arrays of quaternion values.
>
> Travis Oliphant suggested that a quaternion dtype would be a better
> solution, and got me talking to Mark Weibe about this. With Mark's help
> I completed this initial version at yesterday's sprint session.
>
> Incidentally, how to do something like this isn't well documented and I
> would have had little hope without both Mark's in-person help and his
> previous code (for adding a half-precision float dtype) to refer to. I
> don't know what the consensus is about whether people writing custom
> dtypes is a desirable thing, but if it is then the process needs to be
> made a lot easier. That said, the fact this is doable without patching
> the numpy core at all is really, really nice.
>
> Example usage:
>
>  >>> import numpy as np
>  >>> import quaternion
>  >>> np.quaternion(1,0,0,0)
>  quaternion(1, 0, 0, 0)
>  >>> q1 = np.quaternion(1,2,3,4)
>  >>> q2 = np.quaternion(5,6,7,8)
>  >>> q1 * q2
>  quaternion(-60, 12, 30, 24)
>  >>> a = np.array([q1, q2])
>  >>> a
>  array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)],
>        dtype=quaternion)
>  >>> exp(a)
>  array([quaternion(1.69392, -0.78956, -1.18434, -1.57912),
>        quaternion(138.909, -25.6861, -29.9671, -34.2481)],
>        dtype=quaternion)
>
> The following ufuncs are implemented:
>  add, subtract, multiply, divide, log, exp, power, negative, conjugate,
>  copysign, equal, not_equal, less, less_equal, isnan, isinf, isfinite,
>  absolute
>
> Quaternion components are stored as doubles. The package could be extended
> to support e.g. qfloat, qdouble, qlongdouble
>
> Comparison operations follow the same lexicographic ordering as tuples.
>
> The unary tests isnan, isinf and isfinite return true if they would
> return true for any individual component.
>
> Real types may be cast to quaternions, giving quaternions with zero for
> all three imaginary components. Complex types may also be cast to
> quaternions, with their single imaginary component becoming the first
> imaginary component of the quaternion. Quaternions may not be cast to
> real or complex types.
>
> Comments very welcome. This is my first attempt at NumPy hacking :-)
>
>
> Martin
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Craig Yoshioka]

Wow, that makes for a great howto example.  Thanks.


On Jul 16, 2011, at 7:50 AM, Martin Ling wrote:

> Hi all,
> 
> I have just pushed a package to GitHub which adds a quaternion dtype to
> NumPy: https://github.com/martinling/numpy_quaternion
> 
> Some backstory: on Wednesday I gave a talk at SciPy 2011 about an
> inertial sensing simulation package I have been working on
> (http://www.imusim.org/). One component I suggested might be reusable
> from that code was the quaternion math implementation, written in
> Cython. One of its features is a wrapper class for Nx4 NumPy arrays that
> supports efficient operations using arrays of quaternion values.
> 
> Travis Oliphant suggested that a quaternion dtype would be a better
> solution, and got me talking to Mark Weibe about this. With Mark's help
> I completed this initial version at yesterday's sprint session.
> 
> Incidentally, how to do something like this isn't well documented and I
> would have had little hope without both Mark's in-person help and his
> previous code (for adding a half-precision float dtype) to refer to. I
> don't know what the consensus is about whether people writing custom
> dtypes is a desirable thing, but if it is then the process needs to be
> made a lot easier. That said, the fact this is doable without patching
> the numpy core at all is really, really nice.
> 
> Example usage:
> 
 import numpy as np
 import quaternion
 np.quaternion(1,0,0,0)
> quaternion(1, 0, 0, 0)
 q1 = np.quaternion(1,2,3,4)
 q2 = np.quaternion(5,6,7,8)
 q1 * q2
> quaternion(-60, 12, 30, 24)
 a = np.array([q1, q2])
 a
> array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)],
>   dtype=quaternion)
 exp(a)
> array([quaternion(1.69392, -0.78956, -1.18434, -1.57912),
>quaternion(138.909, -25.6861, -29.9671, -34.2481)],
>   dtype=quaternion)
> 
> The following ufuncs are implemented:
> add, subtract, multiply, divide, log, exp, power, negative, conjugate,
> copysign, equal, not_equal, less, less_equal, isnan, isinf, isfinite,
> absolute
> 
> Quaternion components are stored as doubles. The package could be extended
> to support e.g. qfloat, qdouble, qlongdouble
> 
> Comparison operations follow the same lexicographic ordering as tuples.
> 
> The unary tests isnan, isinf and isfinite return true if they would
> return true for any individual component.
> 
> Real types may be cast to quaternions, giving quaternions with zero for
> all three imaginary components. Complex types may also be cast to
> quaternions, with their single imaginary component becoming the first
> imaginary component of the quaternion. Quaternions may not be cast to
> real or complex types.
> 
> Comments very welcome. This is my first attempt at NumPy hacking :-)
> 
> 
> Martin
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Quaternion dtype for NumPy - initial implementation available

[Martin Ling]

Hi all,

I have just pushed a package to GitHub which adds a quaternion dtype to
NumPy: https://github.com/martinling/numpy_quaternion

Some backstory: on Wednesday I gave a talk at SciPy 2011 about an
inertial sensing simulation package I have been working on
(http://www.imusim.org/). One component I suggested might be reusable
from that code was the quaternion math implementation, written in
Cython. One of its features is a wrapper class for Nx4 NumPy arrays that
supports efficient operations using arrays of quaternion values.

Travis Oliphant suggested that a quaternion dtype would be a better
solution, and got me talking to Mark Weibe about this. With Mark's help
I completed this initial version at yesterday's sprint session.

Incidentally, how to do something like this isn't well documented and I
would have had little hope without both Mark's in-person help and his
previous code (for adding a half-precision float dtype) to refer to. I
don't know what the consensus is about whether people writing custom
dtypes is a desirable thing, but if it is then the process needs to be
made a lot easier. That said, the fact this is doable without patching
the numpy core at all is really, really nice.

Example usage:

 >>> import numpy as np
 >>> import quaternion
 >>> np.quaternion(1,0,0,0)
 quaternion(1, 0, 0, 0)
 >>> q1 = np.quaternion(1,2,3,4)
 >>> q2 = np.quaternion(5,6,7,8)
 >>> q1 * q2
 quaternion(-60, 12, 30, 24)
 >>> a = np.array([q1, q2])
 >>> a
 array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)],
dtype=quaternion)
 >>> exp(a)
 array([quaternion(1.69392, -0.78956, -1.18434, -1.57912),
quaternion(138.909, -25.6861, -29.9671, -34.2481)],
dtype=quaternion)

The following ufuncs are implemented:
 add, subtract, multiply, divide, log, exp, power, negative, conjugate,
 copysign, equal, not_equal, less, less_equal, isnan, isinf, isfinite,
 absolute

Quaternion components are stored as doubles. The package could be extended
to support e.g. qfloat, qdouble, qlongdouble

Comparison operations follow the same lexicographic ordering as tuples.

The unary tests isnan, isinf and isfinite return true if they would
return true for any individual component.

Real types may be cast to quaternions, giving quaternions with zero for
all three imaginary components. Complex types may also be cast to
quaternions, with their single imaginary component becoming the first
imaginary component of the quaternion. Quaternions may not be cast to
real or complex types.

Comments very welcome. This is my first attempt at NumPy hacking :-)


Martin
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion