On May 6, 2012, at 12:16 PM, Charles R Harris wrote: > > > On Sun, May 6, 2012 at 6:02 AM, Tom Aldcroft <[email protected]> > wrote: > On Sun, May 6, 2012 at 3:56 AM, David Cournapeau <[email protected]> wrote: > > > > > > On Sat, May 5, 2012 at 9:43 PM, Mark Wiebe <[email protected]> wrote: > >> > >> On Sat, May 5, 2012 at 1:06 PM, Charles R Harris > >> <[email protected]> wrote: > >>> > >>> On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe <[email protected]> wrote: > >>>> > >>>> On Sat, May 5, 2012 at 11:55 AM, Charles R Harris > >>>> <[email protected]> wrote: > >>>>> > >>>>> On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft > >>>>> <[email protected]> wrote: > >>>>>> > >>>>>> On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell <[email protected]> > >>>>>> 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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
