issue_comments

@spencerahill as I said above, you should not need to subclass at all, just define a new frequency,

maybe something like Month30 or somesuch, which then will slot right into PeriodIndex

@jhamman you just need a different frequency, in fact this one is pretty close: https://github.com/pandas-dev/pandas/blob/master/pandas/tseries/offsets.py#L2257

just a matter of defining a fixed-day month frequency (numpy has this by default anyhow). PeriodIndex would then happily take this.

just my 2c here. You are going to end up writing a huge amount of code to re-implement essentially PeriodIndex. not really sure why you are going down this path.

makes sense about dask.array.dropna

though I think you should dropna if at all possible (or have an option at least)

it IS a bit suprising to get back the full index not sure how common that will be in practice esp if u r stacking multiple levels

finally - think about only supporting sequential stacking as it conceptually makes more sense

hmm, is dask.array dropna not implemented? I don't see why it couldn't conceptually be done (though a bit unfamiliar with the impl) - set_index takes 'data' and makes it an 'index', so that is orthogonal. It would make a new Coordinate. reset_index would do the converse. - stack/unstack effectively take existing Coordinates and transform between them.

ok makes sense.

couple of comments: - I think the repr, though technically accurate, is a bit misleading. lists of tuples is really only useful as a MI, so why not actually indicate that - stack/unstack (as in [9]) is not idempotent, as you are reconstituting the full cartesian product of levels. This seems a bit odd though (pandas can do this because its is separately tracking what is actually in the index, via the labels), I don't think you have this though? - these ops are really analogs of set_index/reset_index, rather than stack/unstack, so might be a bit confusing (though I think I get why you are doing it this way), it makes more sense esp for multi-dim. Maybe explain this in the pandas guide?

yeh, this is fine. maybe just note which dtypes are lossless and which are not. Yeah if you store things as Index objects, then this would go away.

ok, closing.

also FYI, these seem reasonable as a default.

``` In [9]: p = tm.makePanel()

In [10]: p Out[10]: <class 'pandas.core.panel.Panel'> Dimensions: 3 (items) x 30 (major_axis) x 4 (minor_axis) Items axis: ItemA to ItemC Major_axis axis: 2000-01-03 00:00:00 to 2000-02-11 00:00:00 Minor_axis axis: A to D

In [11]: p.to_xray() Out[11]: <xray.Dataset> Dimensions: (items: 3, major_axis: 30, minor_axis: 4) Coordinates: * items (items) object 'ItemA' 'ItemB' 'ItemC' * major_axis (major_axis) datetime64[ns] 2000-01-03 2000-01-04 2000-01-05 ... * minor_axis (minor_axis) object 'A' 'B' 'C' 'D' Data variables: None (items, major_axis, minor_axis) float64 -0.5374 0.5918 ...

In [12]: p = tm.makePanel4D()

In [13]: p Out[13]: <class 'pandas.core.panelnd.Panel4D'> Dimensions: 3 (labels) x 3 (items) x 30 (major_axis) x 4 (minor_axis) Labels axis: l1 to l3 Items axis: ItemA to ItemC Major_axis axis: 2000-01-03 00:00:00 to 2000-02-11 00:00:00 Minor_axis axis: A to D

In [14]: p.to_xray() Out[14]: <xray.Dataset> Dimensions: (items: 3, labels: 3, major_axis: 30, minor_axis: 4) Coordinates: * labels (labels) object 'l1' 'l2' 'l3' * items (items) object 'ItemA' 'ItemB' 'ItemC' * major_axis (major_axis) datetime64[ns] 2000-01-03 2000-01-04 2000-01-05 ... * minor_axis (minor_axis) object 'A' 'B' 'C' 'D' Data variables: None (labels, items, major_axis, minor_axis) float64 -0.5523 ... ```

ahh I c, so this is actually a 1-dim (len of 3), ok.

yep, agreed. anyhow I created a new issue for it https://github.com/pydata/pandas/issues/11704

it's not how it's implemented

that is MUCH slower that marginal calculations

right, I think I will open a new issue for that. its actually a bit tricky as the iteration is done in cython itself, and its a marginal calculation anyhow (e.g. you just keep adding the new value, subtracting values that fall off the window).

ohh, @shoyer you are thinking about defining __iter__ on the Rolling, for a custom aggregation? or other reason

@shoyer breath holding :) https://github.com/pydata/pandas/pull/11603

FYI in the pointed to PR joblib does work (w/o dill actually). but IPython.parallel still is not working how I want it.