[Numpy-discussion] Datetime branch

Pierre GM pgmdevlist at gmail.com
Thu Jun 11 15:37:20 EDT 2009


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


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

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








More information about the NumPy-Discussion mailing list