<br><br><div class="gmail_quote">On Sun, Dec 4, 2011 at 6:59 PM, Geoffrey Irving <span dir="ltr"><<a href="mailto:irving@naml.us">irving@naml.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, Dec 4, 2011 at 5:18 PM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sun, Dec 4, 2011 at 5:41 PM, Geoffrey Irving <<a href="mailto:irving@naml.us">irving@naml.us</a>> wrote:<br>
>><br>
>> This may be the problem. Simple diffs are pleasant. I'm guessing<br>
>> this code doesn't get a lot of testing. Glad it's there, though!<br>
>><br>
>> Geoffrey<br>
>><br>
>> diff --git a/numpy/core/src/umath/ufunc_type_resolution.c<br>
>> b/numpy/core/src/umath/ufunc_type_resolution.c<br>
>> index 0d6cf19..a93eda1 100644<br>
>> --- a/numpy/core/src/umath/ufunc_type_resolution.c<br>
>> +++ b/numpy/core/src/umath/ufunc_type_resolution.c<br>
>> @@ -1866,7 +1866,7 @@ linear_search_type_resolver(PyUFuncObject *self,<br>
>> case -1:<br>
>> return -1;<br>
>> /* A loop was found */<br>
>> - case 1:<br>
>> + case 0:<br>
>> return 0;<br>
>> }<br>
>> }<br>
>><br>
><br>
> Heh. Can you verify that this fixes the problem? That function is only<br>
> called once and its return value is passed up the chain, but the documented<br>
> return values of that calling function are -1, 0. So the documentation needs<br>
> to be changed if this is the right thing to do.<br>
<br>
</div>Actually, that patch was wrong, since<br>
linear_search_userloop_type_resolver needs to return three values<br>
(error, not-found, success). A better patch follows. I can confirm<br>
that this gets me further, but I get other failures down the line, so<br>
more fixes may follow. I'll push the branch with all my fixes for<br>
convenience once I have everything working.<br>
<div class="im"><br>
> Speaking of tests... I was wondering if you could be talked into putting<br>
> together a simple user type for including in the tests?<br>
<br>
</div>Yep, though likely not for a couple weeks. If there's interest, I<br>
could also be convinced to sanitize my entire rational class so you<br>
could include that directly. Currently it's both C++ and uses some<br>
gcc specific features like __int128_t. Basically it's<br>
numerator/denominator, where both are 64 bit integers, and an<br>
OverflowError is thrown if anything can't be represented as such<br>
(possibly a different exception would be better in cases like<br>
(1<<64)/((1<<64)+1)). It would be easy to generalize it to rational32<br>
vs. rational64 as well.<br>
<br>
If you want tests but not rational, it would be straightforward to<br>
strip what I have down to a bare bones test case.<br>
<br></blockquote><div><br>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?<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As for the patch below, I wouldn't bother looking at it until I get<br>
the rest of the bugs out of the way (whether they're in my code or<br>
numpy).<br>
<br></blockquote><div><br><snip><br><br>Chuck <br></div><br></div>