On Thu, Jun 11, 2009 at 13:06, Charles R Harris<[email protected]> wrote: > > > On Thu, Jun 11, 2009 at 11:47 AM, Robert Kern <[email protected]> wrote: >> >> On Thu, Jun 11, 2009 at 12:39, Charles R >> Harris<[email protected]> wrote: >> > >> > >> > On Thu, Jun 11, 2009 at 11:34 AM, Robert Kern <[email protected]> >> > wrote: >> >> >> >> On Thu, Jun 11, 2009 at 12:29, Charles R >> >> Harris<[email protected]> wrote: >> >> > Oh, and slipping the new types in between 64 bit integers and floats >> >> > is >> >> > a >> >> > bit iffy. >> >> >> >> Where, specifically? There are several linear orders of types in >> >> numpy. I tried to be careful to do the right thing in each. The enum >> >> numbers are after NPY_VOID, of course, for compatibility. >> > >> > I noticed. I'm not saying it's wrong, just that a linear order lacks >> > descriptive power and is difficult to maintain. I expect you ran into >> > that >> > problem when trying to make everything work as you wanted. >> >> Yes. Now, which place am I slipping in the new types between 64-bit >> integers and floats? > > In the ufunc generator.
This line from generate_umath.py? all = '?bBhHiIlLqQtTfdgFDGO' > But most of the macros use the type ordering Not quite. They use the order of the loops given to the ufunc. The order of the types in that string I think you are referring doesn't affect much. Basically, just the comparisons where every type has a loop. > and how > do you control the promotion (or lack thereof) of the various types to/from > the datetime types? PyArray_CanCastSafely() in convert_datatype.c. datetime and timedelta types cannot be auto-casted to or from any datatype. They can be explicitly cast, but ufuncs won't auto-cast them when trying to find the right loop. The datetime types are a bit unique in that they need to exclude certain combinations (e.g. datetime+datetime). Allowing auto-casts prevented me from doing that. In fact, the placement of the datetime typecodes in that string was a leftover from when I was trying to allow auto-casts between integers and datetime types. Now that I disallow them, the ordering can be changed. > There also seems to be some mechanism for raising errors that has been > added, maybe to loops. I'm not clear on that, did you add some such > mechanism? Not really. Object loops already had such a mechanism; I just extended that to do the same thing for the datetime types, too. You will be able to raise a Python exception in the datetime loops. Of course, you pay for that a little because that means that you can't release the GIL. I don't think that will be a substantial problem. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
