issue_comments

Yes, of course :). Sometimes still a useful way to think about things, though maybe it's better not to encourage it. I think it's a similar situation for an explicit Python loop vs Cython for groupby aggregations, but the Python loop actually works OK much of the time (e.g., we use it in xray because we haven't written nd grouped aggregated in Cython or Numba yet).

On Wed, Nov 25, 2015 at 3:43 PM, Jeff Reback notifications@github.com wrote:

it's not how it's implemented

that is MUCH slower that marginal calculations

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/issues/641#issuecomment-159756318.

@jreback probably should move discussion here back to the pandas issue :). I don't see any reason why the iteration for moving windows (with __iter__) should be to be done in Cython. Basically it is just repeated slicing in a loop, e.g., something like

def __iter__(self): for n in range(...): yield self.obj[n : n + self.window]

@jreback yes, for custom iteration like how you can use __iter__ on groupby. It's not hard to do and it seems like it makes sense for consistency.

Don't hold your breath on the pandas API changes :). This will take some dedicated effort to make it happen in pandas. Frankly, it's probably easier to do it from scratch in xray where we don't have an old API with which to worry about retaining compatibility.

@jhamman Great, looking forward to it!

Yeah, I've been thinking about this one for a while (see also https://github.com/xray/xray/issues/130)

One possibly improved API over pandas is to make a rolling a method that produces Rolling object (similar to a GroupBy). You could write something like array.rolling(time=7).mean() to do aggregation and could also iterate like for label, windowed in array.rolling(time=7).