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... _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
