On Sun, Dec 4, 2011 at 5:18 PM, Charles R Harris
<charlesr.har...@gmail.com> wrote:
>
>
> On Sun, Dec 4, 2011 at 5:41 PM, Geoffrey Irving <irv...@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.
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).
Geoffrey
-----------------------------------------------------
diff --git a/numpy/core/src/umath/ufunc_type_resolution.c
b/numpy/core/src/umath/ufunc_type_resolution.c
index 0d6cf19..4e81e92 100644
--- a/numpy/core/src/umath/ufunc_type_resolution.c
+++ b/numpy/core/src/umath/ufunc_type_resolution.c
@@ -1656,7 +1656,7 @@ linear_search_userloop_type_resolver(PyUFuncObject *self,
/* Found a match */
case 1:
set_ufunc_loop_data_types(self, op, out_dtype, types);
- return 0;
+ return 1;
}
funcdata = funcdata->next;
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
