A Thursday 31 July 2008, Alan G Isaac escrigué: > > A Thursday 31 July 2008, Matt Knox escrigué: > >> While on the topic of FAME... being a financial analyst, I really > >> am quite fond of the multitude of quarterly frequencies we have in > >> the timeseries package (with different year end points) because > >> they are very useful when doing things like "calenderizing" > >> earnings from companies with different fiscal year ends. > > On Thu, 31 Jul 2008, Francesc Alted apparently wrote: > > Well, introducing a quarter should not be difficult. We just > > wanted to keep the set of supported time units under a minimum (the > > list is already quite large). We thought that the quarter fits > > better as a 'derived' time unit, similarly as biweekly, semester or > > biyearly (to name just a few examples). However, if quarters are > > found to be much more important than other derived time units, they > > can go into the proposal too. > > Quarterly frequency is probably the most analyzed frequency > in macroeconometrics. > > Widely used macroeconometrics packages (e.g., EViews) > traditionally support only three explicit frequencies: > annual, quarterly, and monthly.
I see. However, I forgot to mention that another reason for not including the quarters is that they normally need flexibility to be defined as starting in *any* month of the year. As we don't wanted to provide an ``origin`` metadata in the proposal (things got too complex already, as you can see in the third proposal that I sent to this list yesterday), then the usefulness of such an 'unflexible' quarters would be rather limited. So, in the end, I think it is best to avoid them for the dtype (and add support for them in the ``Date`` class). Cheers, -- Francesc Alted _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
