[Numpy-discussion] Datetime branch

[Robert Kern]

On Thu, Jun 11, 2009 at 14:37, Pierre GM<pgmdevlist at gmail.com> wrote:
>
> On Jun 11, 2009, at 3:07 PM, Travis Oliphant wrote:
>
>>> 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...).
>
> As Charles pointed out, it'd be quite useful for units as well. Or to
> store some extra information like the filling_value of a MaskedArray...
>
> So, this metadata would be attached to an array, right ?

No. The metadata is on the dtype.

> Scalars would
> be considered as 0d array for that purpose, right ? eg,  given a 1d
> array of dates w/ a given frequency, accessing a single element would
> give me a scalar w/ the same frequency ?

It should. The details still need to be worked out.

>>  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.
>
> In that case, could we also think about what Darren was suggesting for
> his units package, viz, a pre-processing function (__array_unwrap__ ?)
> that complements the current __array_wrap__ one ? The idea being that
> any operation would be performed on a ndarray, the corresponding
> metadata would be just passed along during the operation, and
> modifications to the metadata would be taken care of in the pre- and/
> or post- processing steps ?

Neither here nor there, I think.

> 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.

> So, if soon we add units
> to floats, the underneath object would still be considered float,
> dealing w/ the unit has to be let for ufuncs ?

This is why I don't think this mechanism can be used for units.

-- 
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