On Thu, Jun 11, 2009 at 15:33, Pierre GM<[email protected]> wrote: > > On Jun 11, 2009, at 3:47 PM, Robert Kern wrote: > >> On Thu, Jun 11, 2009 at 14:37, Pierre GM<[email protected]> wrote:
>>> Oh, just another question: why trying to put datetime and timedelta >>> in >>> the type ordering ? My understanding is that underneath, they're just >>> long/longlong. It's only because they have a particular metadata that >>> they should be processed differently, right ? >> >> No. They need to be different types such that the ufunc mechanism can >> find the right loop implementations. > > Meh. I'm not familiar enough with the details of C ufuncs, so bear > with me for a minute. > > A datetime is basically a long + a frequency attribute. All the > operations recognized as valid for a datetime object will deal w/ the > long part, the frequency are just patched back at the end, right ? So, > a ufunc could first check the underlying type (here, long or > longlong), then check whether there's a value for the 'unit': if > there's one, choose the corresponding loop, if None, use the default > (the one we currently have). That's a much more invasive change to the ufunc dispatch mechanism than I wanted to implement. You would need to store these other loops somewhere on the ufunc object along with more complicated metadata about each loop. > I really fail to see why we need to see datetime/timedelta as > intrinsically different from the other types (apart that they carry > some extra info), and why the mechanism should be different for > datetime/timedelta than for units, say. I would want to apply units to any dtype rather than have reserved dtypes for unitted arrays. If you relax that restriction and only consider unitted double arrays, then you could probably use the same mechanism. -- 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
