On Sun, May 6, 2012 at 6:02 AM, Tom Aldcroft <aldcr...@head.cfa.harvard.edu>wrote:
> On Sun, May 6, 2012 at 3:56 AM, David Cournapeau <courn...@gmail.com> > wrote: > > > > > > On Sat, May 5, 2012 at 9:43 PM, Mark Wiebe <mwwi...@gmail.com> wrote: > >> > >> On Sat, May 5, 2012 at 1:06 PM, Charles R Harris > >> <charlesr.har...@gmail.com> wrote: > >>> > >>> On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe <mwwi...@gmail.com> wrote: > >>>> > >>>> On Sat, May 5, 2012 at 11:55 AM, Charles R Harris > >>>> <charlesr.har...@gmail.com> wrote: > >>>>> > >>>>> On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft > >>>>> <aldcr...@head.cfa.harvard.edu> wrote: > >>>>>> > >>>>>> On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell < > ischn...@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 <https://github.com/girving/rational>. 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. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
