<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 12:18 PM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, Jun 11, 2009 at 13:06, Charles R<br>
<div class="im">Harris<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
> On Thu, Jun 11, 2009 at 11:47 AM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jun 11, 2009 at 12:39, Charles R<br>
>> Harris<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Thu, Jun 11, 2009 at 11:34 AM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Thu, Jun 11, 2009 at 12:29, Charles R<br>
>> >> Harris<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
>> >> > Oh, and slipping the new types in between 64 bit integers and floats<br>
>> >> > is<br>
>> >> > a<br>
>> >> > bit iffy.<br>
>> >><br>
>> >> Where, specifically? There are several linear orders of types in<br>
>> >> numpy. I tried to be careful to do the right thing in each. The enum<br>
>> >> numbers are after NPY_VOID, of course, for compatibility.<br>
>> ><br>
>> > I noticed. I'm not saying it's wrong, just that a linear order lacks<br>
>> > descriptive power and is difficult to maintain. I expect you ran into<br>
>> > that<br>
>> > problem when trying to make everything work as you wanted.<br>
>><br>
>> Yes. Now, which place am I slipping in the new types between 64-bit<br>
>> integers and floats?<br>
><br>
> In the ufunc generator.<br>
<br>
</div>This line from generate_umath.py?<br>
<br>
  all = '?bBhHiIlLqQtTfdgFDGO'<br>
<div class="im"><br>
> But most of the macros use the type ordering<br>
<br>
</div>Not quite. They use the order of the loops given to the ufunc. The<br>
order of the types in that string I think you are referring doesn't<br>
affect much. Basically, just the comparisons where every type has a<br>
loop.<br>
<div class="im"><br>
> and how<br>
> do you control the promotion (or lack thereof) of the various types to/from<br>
> the datetime types?<br>
<br>
</div>PyArray_CanCastSafely() in convert_datatype.c. datetime and timedelta<br>
types cannot be auto-casted to or from any datatype. They can be<br>
explicitly cast, but ufuncs won't auto-cast them when trying to find<br>
the right loop. The datetime types are a bit unique in that they need<br>
to exclude certain combinations (e.g. datetime+datetime). Allowing<br>
auto-casts prevented me from doing that.<br>
</blockquote><div><br>The implementation of  PyArray_CanCastSafely illustrates two other points that bother me.<br><br>1) The rules are encoded in the program logic. This makes them difficult to find or to see what they are and requires editing the code to make changes.<br>
<br>2) Some of the rules are maintained by the types. That is even more obscure and reminiscent of the "friend" functions in c++ that encode the same sort of thing when the operators are overloaded. I never did like that as a general system ;)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
In fact, the placement of the datetime typecodes in that string was a<br>
leftover from when I was trying to allow auto-casts between integers<br>
and datetime types. Now that I disallow them, the ordering can be<br>
changed.<br>
<div class="im"><br>
> There also seems to be some mechanism for raising errors that has been<br>
> added, maybe to loops. I'm not clear on that, did you add some such<br>
> mechanism?<br>
<br>
</div>Not really. Object loops already had such a mechanism; I just extended<br>
that to do the same thing for the datetime types, too. You will be<br>
able to raise a Python exception in the datetime loops. Of course, you<br>
pay for that a little because that means that you can't release the<br>
GIL. I don't think that will be a substantial problem.<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>Didn't say it was a problem, just that the issue of raising errors in the ufunc loops has come up before and I wondered if you were developing some mechanism for that.<br>
  <br><br>BTW, what is the metadata that is going to be added to the types? What purpose does it serve?<br><br>Chuck<br></div><br></div><br>