BUG: addtl fix for compat summary of groupby/resample with dicts

[jreback]

closes #9052
closes #12332

[jorisvandenbossche]

I don't know if this is new in this PR (or if it already worked in master), but I don't think it is needed that we allow this? (in any case it errored in 0.17.1, so we can make a choice here)
Nested dicts don't seem to make much sense for SeriesGroupBy.

[jorisvandenbossche]

And if we do this, shouldn't examples below give a MultiIndex?

In [15]: r['A'].agg({'A': ['sum', 'std']})
Out[15]:
                          sum       std
2010-01-01 09:00:00  0.629247  0.174096
2010-01-01 09:00:02  1.056440  0.356036
2010-01-01 09:00:04  1.315957  0.424492
2010-01-01 09:00:06  1.053714  0.221474
2010-01-01 09:00:08  1.275910  0.190737

In [16]: r['A'].agg({'A': ['sum', 'std'], 'B': ['mean', 'std']})
Out[16]:
                            A                   B
                          sum       std      mean       std
2010-01-01 09:00:00  0.629247  0.174096  0.314624  0.174096
2010-01-01 09:00:02  1.056440  0.356036  0.528220  0.356036
2010-01-01 09:00:04  1.315957  0.424492  0.657978  0.424492
2010-01-01 09:00:06  1.053714  0.221474  0.526857  0.221474
2010-01-01 09:00:08  1.275910  0.190737  0.637955  0.190737

[jreback]

its not a nested dict, is exactly like the example that @xflr6 gave, that was my comment. The A acts on the actual data, while the B acts on the SAME data (and NOT B), and is just 'named' B

[jreback]

In [4]: g['D'].agg({'D': np.sum, 'result2': np.mean})
Out[4]: 
          result2   D
A   B                
bar one  1.000000   1
    two  4.000000   8
foo one  3.000000   6
    two  4.333333  13

In [5]: g['D'].agg({'D': np.sum, 'C': np.mean})
Out[5]: 
                C   D
A   B                
bar one  1.000000   1
    two  4.000000   8
foo one  3.000000   6
    two  4.333333  13

(groupby and resample work the same).

That was my point though. maybe we should raise here as the user could think they are actually operating on something they are not.

[jreback]

In [7]: g.agg({'D': np.sum, 'C': np.mean})
Out[7]: 
                C   D
A   B                
bar one  1.323675   1
    two  1.946188   8
foo one  0.934114   6
    two  1.871956  13

[jreback]

I had it doing like [4] at one point in time (whether you have a 'single' result or multiple as I agree its more consistent. But its ok where it is now, so I don't think should change unless its really compelling. Its clear by what you are passing what you should get back.

[jorisvandenbossche]

It's just a bit strange and inconsistent that the key of the dict ('C') in [5] is completely ignored, while in [4] the keys of the dict are used as column names, while only the length of the dict differs

maybe we should raise here as the user could think they are actually operating on something they are not.

I would be +1 to raise here, but in the way it was in 0.17.1: raising for g['D'].agg({'C': ['sum', 'std']}) but not for g['D'].agg({'C': 'sum', 'D': 'std']})

[jreback]

In [4]: g['D'].agg({'C': ['sum', 'std']})
Out[4]: 
         sum       std
A   B                 
bar one    1       NaN
    two    8  1.414214
foo one    6  4.242641
    two   13  2.516611

In [5]: g['D'].agg({'C': 'sum', 'D' : 'std'})
Out[5]: 
          C         D
A   B                
bar one   1       NaN
    two   8  1.414214
foo one   6  4.242641
    two  13  2.516611

in 0.17.1

In [3]: g['D'].agg({'C': ['sum', 'std']})
ValueError: If using all scalar values, you must pass an index

In [4]: g['D'].agg({'C': 'sum', 'D' : 'std'})
Out[4]: 
          C         D
A   B                
bar one   1       NaN
    two   8  1.414214
foo one   6  4.242641
    two  13  2.516611

I think [3] for 0.17.1 was just a bug. It should have worked.

Looking at this again, this is very tricky. When shoulud you raise? e.g. just because the key of the dict is not in the columns isn't good enough (or even if its a column in the top-level frame), it HAS to be a renaming key.

[jreback]

ahh, but you would be ok with the current if [4] (from 0.18.0), has a multi-level index, right? (e.g. ('C','sum'),('C','std')

[jorisvandenbossche]

ahh, but you would be ok with the current if [4](from 0.18.0), has a multi-level index, right? (e.g. ('C','sum'),('C','std')

yes (so key of dict is always seen as renaming key, independent of length of dict)

When shoulud you raise? e.g. just because the key of the dict is not in the columns isn't good enough (or even if its a column in the top-level frame), it HAS to be a renaming key.

If we would want to raise, I think it should not depend on the value of the key (if it is equal to the column name or not), but on the dimension of the values (scalar -> then it is a simple renaming {'my_col_name': my_func} which is OK; when length > 1 -> then it can raise). But indeed probably easier to just allow it, but to be consistent in the handling of the keys as the column names in the multi-index