[Numpy-discussion] Datetime branch

[Robert Kern]

On Thu, Jun 11, 2009 at 15:33, Pierre GM<pgmdevlist at gmail.com> wrote:
>
> On Jun 11, 2009, at 3:47 PM, Robert Kern wrote:
>
>> On Thu, Jun 11, 2009 at 14:37, Pierre GM<pgmdevlist at gmail.com> 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