A Monday 28 July 2008, Pierre GM escrigué:
> On Monday 28 July 2008 12:17:41 Francesc Alted wrote:
> > So, for allowing this to happen, we have concluded that a
> > conceptual change in our second proposal is needed: instead of
> > a 'resolution', we can introduce the 'time unit' concept.
>
> I'm all for that, thanks !
>
> > One thing that will not be possible though, is
> > to change the time unit of a relative time expressed in say, years,
> > to another time unit expressed in say, days. This is because the
> > impossibility to know how many days has a year that is relative
> > (i.e. not bound to a given year).
>
> OK, that makes sense for timedeltas. But would I still be able to add
> a timedelta['Y'] (in years) to a datetime['D'] (in days) and get the
> proper result ?
Hmmm, good point. Well, provided that we plan to set the casting rules
so that the time unit of the outcome will be the largest of the time
units of the operands, and assuming aproximate values for the number of
days in a year (365.2425, i.e. the average year length of the Gregorian
calendar) and in a month (30.436875 = 365.2425/12), I think the next
operations would be feasible:
>>> numpy.timedelta(20, unit='Y') + numpy.timedelta(365, unit='D')
20 # unit is 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?
> > More in general, it will not be possible
> > to perform 'time unit' conversions between units above and below a
> > relative week (because it is the maximum time unit that has a
> > definite number of seconds).
>
> Could you rephrase that ? You're still talking about conversion for
> timedelta, not datetime, right ?
Yes. I was talking about the relative timedelta in that case. The
initial idea was to forbid conversions among relative timedeltas with
different units that imply assumptions in the number of days. But
after largely pondering about the example above, I think now that it
would be sensible to allow conversions from time units shorter than a
week to larger than a week ones (but not the inverse), assuming the
truncation of the outcome. For example, the next would be allowed:
>>> numpy.timedelta(43, unit='D').astype("t8[M]")
1 # One complete month
>>> numpy.timedelta(365, unit='D').astype("t8[Y]")
0 # Not a complete year
But this would not:
>>> numpy.timedelta(2, unit='M').astype("t8[d]")
raise ``IncompatibleUnitError`` # How many days could have 2 months?
>>> numpy.timedelta(1, unit='Y').astype("t8[d]")
raise ``IncompatibleUnitError`` # How many days could have 1 year?
This will add more complexity to the code, but the functionality looks
sensible to my eyes. What do you think?
>
> > > >>>series.asfreq('A-MAR')
> >
> > Well, as we don't like an 'origin' to have part of our proposal,
> > you won't be able to do exactly that with the proposed plain dtype.
>
> That's what I was afraid of. Oh well, I'm sure we'll come with a
> way...
>
> Looking forward to reading the third version !
Well, as we are still discussing and changing things, we would like to
wait a bit more until all the dust has settled. But we are looking
forward to produce the third version of the proposal before the end of
this week.
Cheers,
--
Francesc Alted
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
