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

[Charles R Harris]

On Sun, Dec 4, 2011 at 6:59 PM, Geoffrey Irving <irving at naml.us> wrote:

> On Sun, Dec 4, 2011 at 5:18 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Sun, Dec 4, 2011 at 5:41 PM, Geoffrey Irving <irving at naml.us> wrote:
> >>
> >> This may be the problem.  Simple diffs are pleasant.  I'm guessing
> >> this code doesn't get a lot of testing.  Glad it's there, though!
> >>
> >> Geoffrey
> >>
> >> diff --git a/numpy/core/src/umath/ufunc_type_resolution.c
> >> b/numpy/core/src/umath/ufunc_type_resolution.c
> >> index 0d6cf19..a93eda1 100644
> >> --- a/numpy/core/src/umath/ufunc_type_resolution.c
> >> +++ b/numpy/core/src/umath/ufunc_type_resolution.c
> >> @@ -1866,7 +1866,7 @@ linear_search_type_resolver(PyUFuncObject *self,
> >>             case -1:
> >>                 return -1;
> >>             /* A loop was found */
> >> -            case 1:
> >> +            case 0:
> >>                 return 0;
> >>         }
> >>     }
> >>
> >
> > Heh. Can you verify that this fixes the problem? That function is only
> > called once  and its return value is passed up the chain, but the
> documented
> > return values of that calling function are -1, 0. So the documentation
> needs
> > to be changed if this is the right thing to do.
>
> Actually, that patch was wrong, since
> linear_search_userloop_type_resolver needs to return three values
> (error, not-found, success).  A better patch follows.  I can confirm
> that this gets me further, but I get other failures down the line, so
> more fixes may follow.  I'll push the branch with all my fixes for
> convenience once I have everything working.
>
> > Speaking of tests... I was wondering if you could be talked into putting
> > together a simple user type for including in the tests?
>
> Yep, though likely not for a couple weeks.  If there's interest, I
> could also be convinced to sanitize my entire rational class so you
> could include that directly.  Currently it's both C++ and uses some
> gcc specific features like __int128_t.  Basically it's
> numerator/denominator, where both are 64 bit integers, and an
> OverflowError is thrown if anything can't be represented as such
> (possibly a different exception would be better in cases like
> (1<<64)/((1<<64)+1)).  It would be easy to generalize it to rational32
> vs. rational64 as well.
>
> If you want tests but not rational, it would be straightforward to
> strip what I have down to a bare bones test case.
>
>
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. Rationals may be a
bit trickier than quaternions though, as usually they are used to provide
exact arithmetic without concern for precision. I don't know how
restrictive the 64 bit limitation will be in practice. What are you using
them for?


> As for the patch below, I wouldn't bother looking at it until I get
> the rest of the bugs out of the way (whether they're in my code or
> numpy).
>
>
<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111204/81fd3909/attachment.html>