Dave Hirschfeld wrote: > Robert Kern <robert.kern <at> gmail.com> writes:
>> Well, [D/100] doesn't represent [864s]. It represents something that >> happens 100 times a day, but not necessarily at precise regular >> intervals. >> For example, suppose that I am representing payments that >> happen twice a month, say on the 1st and 15th of every month, or the >> 5th and 20th. I would use [M/2] to represent that. It's not [2W], and >> it's not [15D]. It's twice a month. Got it -- very useful concept, of course. >> The default conversions may seem to imply that [D/100] is equivalent >> to [864s], but they are not intended to. They are just a starting >> point for one to write one's own, more specific conversions. Here is my issue -- I don't think there should be default conversions at all -- as you point out, "twice a month" is a well defined concept, but it is NOT the same as every 15 days (or any other set interval). I'm not sure it should be possible to "convert" to a regular interval at all. > That would be one way of dealing with irregularly spaced data. I would argue > that the example is somewhat back-to-front though. If something happens > twice a month it's not occuring at a monthly frequency, but at a higher > frequency. And that frequency is 2/month. > In this case the lowest frequency which can capture this data is > daily frequency so it should be stored at daily frequency I don't think it should, because it isn't 1/15 days, or, indeed, an frequency that can be specified as days. Sure you can specify the 5th and 20th of each month in a given time span in terms of days since an epoch, but you've lost some information there. When you want to do math -- like add a certain number of 1/2 months -- when is the 100th payment due? It seems keeping it in M/2 is the most natural way to deal with that -- then you don't need special code to do that addition, only when converting to a string (or other format) datetime. Anyway, my key point is that converting to/from calendar-based units and "linear time" units is fraught with peril -- it needs to be really clear when that is happening, and the user needs to have a clear and ideally easy way to define how it should happen. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
