<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 1:07 PM, Travis Oliphant <span dir="ltr"><<a href="mailto:oliphant@enthought.com">oliphant@enthought.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;">
<div class="im"><br>
On Jun 11, 2009, at 1:44 PM, Charles R Harris wrote:<br>
<br>
><br>
> The implementation of  PyArray_CanCastSafely illustrates two other<br>
> points that bother me.<br>
><br>
> 1) The rules are encoded in the program logic. This makes them<br>
> difficult to find or to see what they are and requires editing the<br>
> code to make changes.<br>
<br>
</div>I agree that this is all sub-optimal.     I didn't do much to fix what<br>
was there with Numeric except add a semi-orthogonal user-defined<br>
approach.<br>
<br>
I like the generic function concept that was added to the ufuncs quite<br>
a bit.   I'm wondering if most of the functions currently in the *f<br>
member of the data-type structure couldn't be implemented under that<br>
notion instead.<br>
<br>
Also, should we attach coercion information to each data-type directly<br>
and an API to extend the coercion information?   I agree that the<br>
"implicit" ordering of the data-types for coercion is wonky, but it<br>
allowed the code from Numeric to be used to dispatch in the ufunc<br>
instead of designing a new approach.   Do you have other ideas about<br>
how this might work?<br>
<div class="im"></div></blockquote><div><br>It was a fairly decent system when there were just a few numeric types, but there are more data types then datetime that might be useful so it would be nice if there was a more general way to add them without wading through all the stuff Robert had to do. The descriptors still need to be identified and a number is as good as anything, it is the reliance on ordering that is the limitation.<br>
<br>For a general solution, my thoughts have been running along the lines of a table/linked list, but not directly implemented in c. Who wants to edit a 19x19 array, maybe even several of them ;) So I'm trying to think how the rules could be encoded so that a python program could generate tables or lists. The rules could all be collected in one spot, then.<br>
<br>Actual code would still be needed for the conversions  and loops and there needs to be a way to associate the conversion with the corresponding function. So probably a name as well as a number is needed when a new type is added.<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;"><div class="im"><br>
><br>
> 2) Some of the rules are maintained by the types. That is even more<br>
> obscure and reminiscent of the "friend" functions in c++ that encode<br>
> the same sort of thing when the operators are overloaded. I never<br>
> did like that as a general system ;)<br>
<br>
</div>Are you referring to the user-defined data-types?    I agree it's<br>
pretty kludgy.    Are you envisioning a "global" coercion table?  It<br>
seems like this may need to be operation specific and extensible to<br>
allow new data-types to be added fairly easily.<br>
<div class="im"><br>
><br>
> BTW, what is the metadata that is going to be added to the types?<br>
> What purpose does it serve?<br>
<br>
</div>In the date-time case, it holds what frequency the integer in the data-<br>
type represents.    There will only be 2 new static data-types.<br>
"Datetime" and "Timedelta" that use 8 bytes each.<br>
<br>
What those 8 bytes represent will be determined by the metadata<br>
(years, months, seconds, etc...).<br>
<br>
But, generally, it will be an extra dictionary that can store anything<br>
you want (anybody want to define a "float" data-type that uses IBM<br>
format bits?).  The ufunc machinery needs to change to handle passing<br>
that information in somehow.   The approaches we take to doing that<br>
will also hopefully allow us to define ufuncs for string, unicode, and<br>
void * arrays as well.<br>
</blockquote><div><br>Might be useful for units also.<br><br>Chuck <br></div><br></div><br>