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. These frequencies are
> included in FAME, which makes sense since it targets financial users.
> I know Pierre likes them too for working with different seasons. I
> think it would be ok to leave them out of an initial implementation,
> but it might be worth keeping in mind during the design phase about
> how the dtype could be extended to incorporate such things.
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.
> >> As forbidding operations among absolute/absolute and
> >> relative/relative types can be unacceptable in many situations, we
> >> are proposing an explicit casting mechanism so that the user can
> >> inform about the desired time unit of the outcome. For this, a
> >> new NumPy function, called, say, ``numpy.change_unit()`` (this
> >> name is for the purposes of the discussion and can be changed)
> >> will be provided. The signature for the function will be:
> >>
> >> 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). For
> >>
> >> example, that would allow to do:
> >> >>> numpy.change_unit( numpy.array([1,2], 'T[Y]'), 'T[d]' )
> >>
> >> array([365, 731], dtype="datetime64[d]")
>
> If I understand you correctly, this is very close to the "asfreq"
> method of the Date/DateArray/TimeSeries classes in the timeseries
> module. One key element missing here (from my point of view anyway)
> is an equivalent of the 'relation' parameter in the asfreq method in
> the timeseries module. This is only used when converting from a lower
> frequency to a higher frequency (eg. annual to daily). For example...
>
> >>> a = ts.Date(freq='Annual', year=2007)
> >>> a.asfreq('Daily', 'START')
>
> <D : 01-Jan-2007>
>
> >>> a.asfreq('Daily', 'END')
>
> <D : 31-Dec-2007>
>
> This is another one of those things that I use all the time. Now
> whether it belongs in the core dtype, or some extension module I'm
> not sure... but it's an important feature in the timeseries module.
I agree that such a 'relation' parameter in the
proposed 'change_timeunit' could be handy in many situations. It
should be applicable only to absolute times though. With this, the
signature for the function would be:
change_timeunit(time_object, new_unit, relation, reference)
where 'relation' only can be used with absolute times and 'reference'
only with relative times.
Who knows, perhaps in the future one can find a way to implement such
a 'change_timeunit' function as methods without disturbing too much the
method schema of the ndarray objects.
Cheers,
--
Francesc Alted
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
