[SciPy-User] scikits.timeseries: How to define frequency of15minutes
Fri Apr 16 16:17:06 CDT 2010
OK I got that, and I thank you for your clear words stating
the current situation. I have not yet analyzed the
consequences of working with missing data. But I also think
that 93% of missing data is some how waste of memory
especially with large datasets which is often the case using
I suppose I have to little background in C programming and my
experiences in C are too long ago to be able to propose an
useful C-based patch for that issue.
I will experience with the current code and will follow
closely the evolution of scikits.timeseries.
Keep doing what you are doing it is really helpful.
Pierre GM wrote:
> On Apr 16, 2010, at 2:07 PM, Matt Knox wrote:
>> Georges Schutz <georges.schutz <at> internet.lu> writes:
>>> I know that the underlying code is in C and that this is
also the reason
>>> of the fast runtime of this python modules what I
appreciate of cause.
>>> My initial question was if there exist a method to realize
>>> frequencies which seems not being the case. Know the
question is is
>>> nobody else needing such a feature or is it somewhere on a
todo list or
>>> even someone already implemented it in a one extension.
>> This isn't on my to-do list, or Pierre's either so far as I
>> Although I certainly agree it is a useful feature. As far
as major new
>> features, I am kind of waiting to see what transpires with
>> datetime data type when it matures a bit and then maybe see
how we might
>> integrate that into the time series package, at which point
it would also
>> be useful to revisit this feature.
> I agree with Matt: the new numpy dtypes may be a good lead,
but it's still
> far too early to tell how easy it'll be to merge it w/
> Keep in mind that the package was initially designed to
> convenience while analyzing data at frequencies of a day or
> that was what Matt and I had to deal with. However, like
Matt, I recognize
> that having the possibility to define specific frequencies
would be great.
> Unfortunately, we are at this point stuck with the existing
> There are a couple of ways to handle 15-min frequencies,
> suggested before, you could use a minutely frequency.
However, you'd end
> up with 93% of missing data, which can be a bit wasteful. A
> possibility is to use a hour frequency with a (n,4) series,
with n the
> number of hours. In turn, this might be a problem if you
want to convert
> the series to another frequency (nD series are not
> .convert), but that could get you started. Of course,
that'll depend on
> what you want to do. Let us know how it goes P.
More information about the SciPy-User