[Numpy-discussion] The date/time dtype and the casting issue
Tue Jul 29 14:47:52 CDT 2008
On Tuesday 29 July 2008 15:14:13 Ivan Vilata i Balaguer wrote:
> Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir::
> > > Relative time versus relative time
> > > ----------------------------------
> > >
> > > This case would be the same than the previous one (absolute vs
> > > absolute). Our proposal is to forbid this operation if the time units
> > > of the operands are different.
> > Mmh, less sure on this one. Can't we use a hierarchy of time units, and
> > force to the lowest ?
> > For example:
> > >>>numpy.ones(3, dtype="t8[Y]") + 3*numpy.ones(3, dtype="t8[M]")
> > >>>array([15,15,15], dtype="t8['M']")
> > I agree that adding ns to years makes no sense, but ns to s ? min to
> > hr or days ? In short: systematically raising an exception looks a
> > bit too drastic. There are some simple unambiguous cases that sould be
> > allowed (Y+M, Y+Q, M+Q, H+D...)
> Do you mean using the most precise unit for operations with "near
> enough", different units? I see the point, but what makes me doubt
> about it is giving the user the false impression that the most precise
> unit is *always* expected. I'd rather spare the user as many surprises
> as possible, by simplifying rules in favour of explicitness (but that
> may be debated).
Let me rephrase:
Adding different relative time units should be allowed when there's no
ambiguity on the output:
For example, a relative year timedelta is always 12 month timedeltas, or 4
quarter timedeltas. In that case, I should be able to do:
>>>numpy.ones(3, dtype="t8[Y]") + 3*numpy.ones(3, dtype="t8[M]")
>>>numpy.ones(3, dtype="t8[Y]") + 3*numpy.ones(3, dtype="t8[Q]")
* an hour is always 3600s, so I could add relative s/ms/us/ns timedeltas to
hour timedeltas, and get the result in s/ms/us/ns.
* A day is always 24h, so I could add relative hours and days timedeltas and
get an hour timedelta
* A week is always 7d, so W+D -> D
* We can't tell beforehand how much days are in any month, so adding relative
days and months would raise an exception.
* Same thing with weeks and months/quarters/years
There'll be only a limited number of time units, therefore a limited number of
potential combinations between time units. It'd be just a matter of listing
which ones are allowed and which ones will raise an exception.
> > > Note: we refused to use the ``.astype()`` method because of the
> > > additional 'time_reference' parameter that will sound strange for other
> > > typical uses of ``.astype()``.
> > A method would be really, really helpful, though...
> > [...]
> Yay, but what doesn't seem to fit for me is that the method would only
> have sense to time values.
Well, what about a .tounit(new_unit, reference=None) ?
By default, the reference would be None and default to the POSIX epoch.
We could also go for .totunit (for to time unit)
> NumPy is pretty orthogonal in that every
> method and attribute applies to every type. However, if "units" were to
> be adopted by NumPy, the method would fit in well. In fact, we are
> thinking of adding a ``unit`` attribute to dtypes to support time units
> (being ``None`` for normal NumPy types). But full unit support in NumPy
> looks so far away that I'm not sure to adopt the method.
> Thanks for the insights. Cheers,
More information about the Numpy-discussion