On Aug 2, 2011, at 9:37 AM, Tim Michelsen wrote:
>>>> I agree. I already have 50% or more of the features in
>>>> scikits.timeseries, so this gets back to my fragmentation argument
>>>> (users being stuck with a confusing choice between multiple
>>>> libraries). Let's make it happen!
>>> So what needs to be done to move things forward?
>>> Do we need to draw up a roadmap?
>>> A table with functions that respond to common use cases in natual
>>> science, computing, and economics?
>> Having a place to collect concrete use cases (like your list from the
>> prior e-mail, but with illustrative code snippets) would be good.
>> You're welcome to start doing it here:
>>>>https://github.com/wesm/pandas/wiki> Here goes:
>https://github.com/wesm/pandas/wiki/Time-Series-Manipulation>> I will fill it with my stuff.
> Shall we file feature request directly as issues?
>>> A good place to start, which I can do when I have some time, would be
>> to start moving the scikits.timeseries code into pandas. There are
>> several key components
>>>> - Date and DateArray stuff, frequency implementations
>> - masked array time series implementations (record array and not)
>> - plotting
>> - reporting, moving window functions, etc.
>>>> We need to evaluate Date/DateArray as they relate to numpy.datetime64
>> and see what can be done. I haven't looked closely but I'm not sure if
>> all the convenient attribute access stuff (day, month, day_of_week,
>> weekday, etc.) is available in NumPy yet. I suspect it would be
>> reasonably straightforward to wrap DateArray so it can be an Index for
>> a pandas object.
>>>> I won't have much time for this until mid-August, but a couple days'
>> hacking should get most of the pieces into place. I guess we can just
>> keep around the masked array classes for legacy API support and for
>> feature completeness.
> I value very much the work of Pierre and Matt.
> But my difficulti with the scikit was that the code is too complex. So I was
> only able to contribute helper functions for doc fixes.
> Please, lets make it happen that this effort is not a on or 3 man show but
> results in something whcih can be maintained by the whole community.
The apparent complexity of the code comes likely from the fact that some features were coded directly in C (not even Cython) for efficiency. That, and that it relied on MaskedArray, of course ;)
> Nevertheless, the timeseries scikit made my work more comfortable and
> understadable than I was able to manage with R.
Great ! That was the purpose.