[Numpy-discussion] Datetime branch
Thu Jun 11 14:47:51 CDT 2009
On Thu, Jun 11, 2009 at 14:37, Pierre GM<email@example.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
>> 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.
"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
More information about the Numpy-discussion