[Numpy-discussion] The date/time dtype and the casting issue
Pierre GM
pgmdevlist@gmail....
Tue Jul 29 11:38:19 CDT 2008
Francesc,
> Absolute time versus relative time
> ----------------------------------
>
> We think that in this case the absolute time should have priority for
> determining the time unit of the outcome.
+1
> Absolute time versus absolute time
> ----------------------------------
>
> When operating (basically, only the substraction will be allowed) two
> absolute times with different unit times, we are proposing that the
> outcome would be to raise an exception.
+1
(However, I don't think that np.zeros(3, dtype="T8[Y]") is the most useful
example ;))
> 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...)
> Introducing a time casting function
> -----------------------------------
> change_unit(time_object, new_unit, reference)
>
> where 'time_object' is the time object whose unit is to be
> changed, 'new_unit' is the desired new time unit, and 'reference' is an
> absolute date that will be used to allow the conversion of relative
> times in case of using time units with an uncertain number of smaller
> time units (relative years or months cannot be expressed in days).
reference default to the POSIX epoch, right ?
So this function could be a first step towards our problem of frequency
conversion...
> 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...
Back to a previous email:
> >>> numpy.timedelta(20, unit='Y') + numpy.timedelta(365, unit='D')
> 20 # unit is Year
I would have expected days, or an exception (as there's an ambiguity in the
length in days of a year)
> >>> numpy.timedelta(20, unit='Y') + numpy.timedelta(366, unit='D')
> 21 # unit is Year
> >>> numpy.timedelta(43, unit='M') + numpy.timedelta(30, unit='D')
> 43 # unit is Month
>
> >>> numpy.timedelta(43, unit='M') + numpy.timedelta(31, unit='D')
> 44 # unit is Month
> Would that be ok for you?
Gah, I dunno. Adding relative values is always tricky... I understand the last
statement as 43 months and 31 days, which could be 44 months if we're
speaking in months, or 3 years, 7 months, and 31 days...
More information about the Numpy-discussion
mailing list