[Numpy-discussion] Quaternion data type

Travis Oliphant travis at continuum.io
Mon May 7 01:11:30 EDT 2012


On May 6, 2012, at 12:16 PM, Charles R Harris wrote:

> 
> 
> On Sun, May 6, 2012 at 6:02 AM, Tom Aldcroft <aldcroft at head.cfa.harvard.edu> wrote:
> On Sun, May 6, 2012 at 3:56 AM, David Cournapeau <cournape at gmail.com> wrote:
> >
> >
> > On Sat, May 5, 2012 at 9:43 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> >>
> >> On Sat, May 5, 2012 at 1:06 PM, Charles R Harris
> >> <charlesr.harris at gmail.com> wrote:
> >>>
> >>> On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> >>>>
> >>>> On Sat, May 5, 2012 at 11:55 AM, Charles R Harris
> >>>> <charlesr.harris at gmail.com> wrote:
> >>>>>
> >>>>> On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft
> >>>>> <aldcroft at head.cfa.harvard.edu> wrote:
> >>>>>>
> >>>>>> On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell <ischnell at enthought.com>
> >>>>>> wrote:
> >>>>>> > Hi Chuck,
> >>>>>> >
> >>>>>> > thanks for the prompt reply.  I as curious because because
> >>>>>> > someone was interested in adding
> >>>>>> > http://pypi.python.org/pypi/Quaternion
> >>>>>> > to EPD, but Martin and Mark's implementation of quaternions
> >>>>>> > looks much better.
> >>>>>>
> >>>>>> Hi -
> >>>>>>
> >>>>>> I'm a co-author of the above mentioned Quaternion package.  I agree
> >>>>>> the numpy_quaternion version would be better, but if there is no
> >>>>>> expectation that it will move forward I can offer to improve our
> >>>>>> Quaternion.  A few months ago I played around with making it accept
> >>>>>> arbitrary array inputs (with similar shape of course) to essentially
> >>>>>> vectorize the transformations.  We never got around to putting this in
> >>>>>> a release because of a perceived lack of interest / priorities... If
> >>>>>> this would be useful then let me know.
> >>>>>>
> >>>>>
> >>>>> Would you be interested in carrying Martin's package forward? I'm not
> >>>>> opposed to having quaternions in numpy/scipy but there needs to be someone
> >>>>> to push it and deal with problems if they come up. Martin's package
> >>>>> disappeared in large part because Martin disappeared. I'd also like to hear
> >>>>> from Mark about other aspects, as there was also a simple rational user type
> >>>>> proposed that we were looking to put in as an extension 'test' type. IIRC,
> >>>>> there were some needed fixes to Numpy, some of which were postponed in favor
> >>>>> of larger changes. User types is one of the things we want ot get fixed up.
> >>>>
> >>>>
> >>>> I kind of like the idea of there being a package, separate from numpy,
> >>>> which collects these dtypes together. To start, the quaternion and the
> >>>> rational type could go in it, and eventually I think it would be nice to
> >>>> move datetime64 there as well. Maybe it could be called numpy-dtypes, or
> >>>> would a more creative name be better?
> >>>
> >>>
> >>> I'm trying to think about how that would be organized. We could create a
> >>> new repository, numpy-user-types (numpy-extension-types), under the numpy
> >>> umbrella. It would need documents and such as well as someone interested in
> >>> maintaining it and making releases. A branch in the numpy repository
> >>> wouldn't work since we would want to rebase it regularly. It could maybe go
> >>> in scipy but a new package would need to be created there and it feels too
> >>> distant from numpy for such basic types as datetime.
> >>>
> >>> Do you have thoughts about the details?
> >>
> >>
> >> Another repository under the numpy umbrella would best fit what I'm
> >> imagining, yes. I would imagine it as a package of additional types that
> >> aren't the core ones, but that many people would probably want to install.
> >> It would also be a way to continually exercise the type extension system, to
> >> make sure it doesn't break. It couldn't be a branch of numpy, rather a
> >> collection of additional dtypes and associated useful functions.
> >
> >
> > I would be in favor of this as well. We could start the repository by having
> > one "trivial" dtype that would serve as an example. That's something I have
> > been interested in, I can lock a couple of hours / week to help this with.
> >
> 
> How about if I start by working on adding tests within
> numpy_quaternion, then this can be migrated into an extended dtypes
> package when it is set up.
> 
> Sounds like a good start. You might want to ping Martin too.
>  
> 
> A nice "trivial" dtype example would be very useful, as I mentioned
> just last week our group was wondering how to make a new dtype.
> 
> 
> There is the rational dtype. I expect there will be some interaction between numpy and the extension types as the bugs are worked out. Extension types for numpy haven't been much used.

Actually, they have been used fairly extensively in multiple projects that I am aware of.   They have just not been discussed enough, nor is there a good open-source collection of extension dtypes.   It is also harder than it really should be to create extension dtypes. 

-Travis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120507/a9297a05/attachment.html>


More information about the NumPy-Discussion mailing list