On Friday 11 July 2008 14:58:33 Francesc Alted wrote: > > Well, we coded something like that in our TimeSeries class: its > > __getitem__ is quite bloated, but you can use integers/dates/strings > > as indices and get your result. We implemented in Python, so that's > > slow, but it works great. > > That's nice! But it would be even nicer if that could be integrated in > general NumPy arrays after the introduction of the datetime types (just > thinking aloud ;-)
Oh yes. Matt and I have the plan to implement that part in C, but I doubt it's gonna happen anytime soon: I'd have to learn proper C first and > > About the representation (datetime vs integer): > That's ok. But my point is that this forces you to represent absolute > dates, and that's what I was trying to avoid. Mmh, it's only a matter of repr/str, in fact. Internally, your array would still be datetime64, and you'll leave the user decide how s/he wants to display it. > The proposed date/time > types could work either as absolute or relative, depending on the needs > of the user. Only when converting them to the Python > ``datetime.datetime`` containers a time origin will be set, and hence, > they represents an absolute date then. However, if you convert the > NumPy datetimes into a ``datetime.timedelta``, your times will continue > to be relative. That would be utterly important so as not to clutter > NumPy too much with another set of 'timedelta' types, IMO. +1 With DateArray, timedeltas are just integers, the behaviour depends on the objects they're added to. With a annual DateArray, +1 means "add one year". With a monthly DateArray, it means "add one month", and so forth... _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
