On Jun 11, 2009, at 1:44 PM, Charles R Harris wrote: > > The implementation of PyArray_CanCastSafely illustrates two other > points that bother me. > > 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.
I agree that this is all sub-optimal. I didn't do much to fix what was there with Numeric except add a semi-orthogonal user-defined approach. I like the generic function concept that was added to the ufuncs quite a bit. I'm wondering if most of the functions currently in the *f member of the data-type structure couldn't be implemented under that notion instead. Also, should we attach coercion information to each data-type directly and an API to extend the coercion information? I agree that the "implicit" ordering of the data-types for coercion is wonky, but it allowed the code from Numeric to be used to dispatch in the ufunc instead of designing a new approach. Do you have other ideas about how this might work? > > 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 ;) Are you referring to the user-defined data-types? I agree it's pretty kludgy. Are you envisioning a "global" coercion table? It seems like this may need to be operation specific and extensible to allow new data-types to be added fairly easily. > > BTW, what is the metadata that is going to be added to the types? > What purpose does it serve? In the date-time case, it holds what frequency the integer in the data- type represents. There will only be 2 new static data-types. "Datetime" and "Timedelta" that use 8 bytes each. What those 8 bytes represent will be determined by the metadata (years, months, seconds, etc...). But, generally, it will be an extra dictionary that can store anything you want (anybody want to define a "float" data-type that uses IBM format bits?). The ufunc machinery needs to change to handle passing that information in somehow. The approaches we take to doing that will also hopefully allow us to define ufuncs for string, unicode, and void * arrays as well. Thanks, -Travis _______________________________________________ Numpy-discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
