[Numpy-discussion] failure to register ufunc loops for user defined types

[Mark Wiebe]

On Mon, Dec 5, 2011 at 8:58 AM, David Cournapeau <cournape at gmail.com> wrote:

> On Sun, Dec 4, 2011 at 9:45 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
>
> >
> > We'll see how much interest there is. If it becomes official you may get
> > more feedback on features. There are some advantages to having some user
> > types in numpy. One is that otherwise they tend to get lost, another is
> that
> > having a working example or two provides a templates for others to work
> > from, and finally they provide test material. Because official user types
> > aren't assigned anywhere there might also be some conflicts. Maybe
> something
> > like an extension types module would be a way around that. In any case, I
> > think both rational numbers and quaternions would be useful to have and I
> > hope there is some discussion of how to do that.
>
> I agree that those will be useful, but I am worried about adding more
> stuff in multiarray. User-types should really be separated from
> multiarray. Ideally, they should be plugins but separated from
> multiarray would be a good first step.
>

I think the object and datetime dtypes should also be moved out of the core
multiarray module at some point. The user-type mechanism could be improved
a lot based on Martin's feedback after he did the quaternion
implementation, and needs further expansion to be able to support object
and datetime arrays as currently implemented.

I realize it is a bit unfair to have this ready for Geoffray's code
> changes, but depending on the timelines for the 2.0.0 milestone, I
> think this would be a useful thing to have. Otherwise, if some ABI/API
> changes are needed after 2.0, we will be dragged down with this for
> years. I am willing to spend time on this. Geoffray, does this sound
> acceptable to you ?
>

A rational type could be added without breaking the ABI, in the same way it
was done for datetime and half in 1.6. I think the revamp of the user-type
mechanism needs its own NEP design document, because changing it will be a
very delicate operation in dealing with how it interacts with the NumPy
core, and making it much more programmer-friendly will take a fair number
of design iterations.

-Mark


>
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111205/2c4b657b/attachment.html>