Pandas: Groupby.agg में डिक्ट्स को फिर से लेबल करने का बहिष्करण कई मुद्दों को लाता है

@zertrin : इसे एक साथ रखने के लिए धन्यवाद। मैंने देखा कि इस बारे में #15931 में काफी चर्चा हुई थी। चूंकि मैं इसे पूरा नहीं पढ़ पाया हूं, इसलिए मैं इस समय कोई टिप्पणी नहीं कर सकता। फिर भी, मुझे पिंग करने दो:

@jreback @jorisvandenbossche @TomAugspurger @chris-b1

मैं मानता हूं कि वर्तमान agg कार्यान्वयन के साथ नाम बदलना इस उदाहरण में बहुत ही भद्दा और टूटा हुआ है। नेस्टेड डिक्ट्स कुछ जटिल हैं लेकिन उन्हें लिखने से यह स्पष्ट हो जाता है कि क्या हो रहा है।

मुझे लगता है कि names पैरामीटर को agg जोड़ा जा सकता है जो शब्दकोष को उनके नए नामों में समेकित कॉलम मैपिंग ले जाएगा। ऊपरी सूचकांक स्तर को बनाए रखना है या नहीं यह निर्धारित करने के लिए आप बूलियन के रूप में एक और पैरामीटर drop_index भी जोड़ सकते हैं।

तो वाक्यविन्यास में बदल जाएगा:

agg_dict = {'energy': ['sum',
                       lambda x: np.percentile(x, 98), # lambda
                       lambda x: np.percentile(x, 17), # lambda
                      ],
            'distance': ['sum',
                         'mean',
                         smrb.mad, # original function
                         mad_c1,   # partial function wrapping the original function
                        ]
           }

name_dict = {'energy':['energy_sum', 'energy_p98', 'energy_p17'],
             'distance':['distance_sum', 'distance_mean', 'distance_mad', 'distance_mad_c1']}


mydf.groupby('cat').agg(agg_dict, names=name_dict, drop_index=True)

या हो सकता है, एक पूरी नई विधि agg_assign बनाई जा सकती है, जो DataFrame.assign समान काम करेगी:

mydf.groupby('cat').agg_assign(energy_sum=lambda x: x.energy.sum(),
                               energy_p98=lambda x: np.percentile(x.energy, 98),
                               energy_p17=lambda x: np.percentile(x.energy, 17),
                               distance_sum=lambda x: x.distance.sum(),
                               distance_mean=lambda x: x.distance.mean(),
                               distance_mad=lambda x: smrb.mad(x.distance),
                               distance_mad_c1=lambda x: mad_c1(x.distance))

मुझे वास्तव में यह विकल्प बहुत बेहतर लगता है।

इसके लायक क्या है, मैं भी कार्यक्षमता को कम न करने के पक्ष में हूं।

मेरे लिए एक बड़ा कारण यह है कि पाइथन के फ़ंक्शन नाम-स्थान (विशेष कार्यान्वयन के साथ कुछ करने के लिए) को कॉलम नामों (कुछ ऐसा जो निश्चित रूप से कार्यान्वयन के बारे में नहीं पता होना चाहिए) के साथ मिश्रण करने के बारे में कुछ गहरा है। तथ्य यह है कि हम '<lambda>' नाम के कॉलम (संभावित रूप से कई कॉलम) देख रहे हैं, यह मुझे गंभीर संज्ञानात्मक असंगति का कारण बनता है।

नाम बदलने का तरीका महत्वपूर्ण है, क्योंकि यह मध्यस्थ कदम है जहां अनावश्यक (और उजागर) कॉलम नामों को इधर-उधर ले जाया जाता है। इसके अलावा, उन्हें मज़बूती से, व्यवस्थित रूप से नाम बदलना मुश्किल है क्योंकि कार्यान्वयन पर संभावित निर्भरताएँ हैं।

इसके अलावा, नेस्टेड dict कार्यक्षमता स्वीकार्य रूप से जटिल है, लेकिन यह एक जटिल ऑपरेशन है जिसे किया जा रहा है।

टीएल; डीआर कृपया मूल्यह्रास न करें। :)

मेरा योगदान दो चीजों से प्रेरित है।

1. मैं पंडों के फूला हुआ एपीआई को कम करने की प्रेरणा से अवगत हूं और इससे सहमत हूं। भले ही मैं "फूला हुआ" एपीआई तत्वों को कम करने के लिए कथित प्रेरणा के संबंध में गुमराह हूं, फिर भी मेरी राय है कि पंडों के एपीआई को सुव्यवस्थित किया जा सकता है।
2. मुझे लगता है कि हर किसी की इच्छाओं और इच्छाओं को पूरा करने के लिए एपीआई प्रदान करने की तुलना में अच्छे व्यंजनों के साथ एक अच्छी कुकबुक होना बेहतर है। मैं यह दावा

इसके अलावा, पांडस सीरीज़ और डेटाफ़्रेम ऑब्जेक्ट्स में पाइपलाइनिंग की सुविधा के लिए pipe तरीके हैं। इस दस्तावेज़ खंड में यह चर्चा की गई है कि हम उपवर्ग के बदले में तरीकों के लिए प्रॉक्सी के लिए pipe का उपयोग कर सकते हैं। उसी भावना में, हम समान भूमिका निभाने के लिए नए GroupBy.pipe का उपयोग कर सकते हैं और हमें ग्रुपबाय ऑब्जेक्ट्स के लिए प्रॉक्सी विधियों का निर्माण करने की अनुमति दे सकते हैं।

मैं @zertrin के उदाहरण का उपयोग

import numpy as np
import statsmodels.robust as smrb
from functools import partial

# The DataFrame offered up above
mydf = pd.DataFrame(
    {
        'cat': ['A', 'A', 'A', 'B', 'B', 'C'],
        'energy': [1.8, 1.95, 2.04, 1.25, 1.6, 1.01],
        'distance': [1.2, 1.5, 1.74, 0.82, 1.01, 0.6]
    },
    index=range(6)
)

# Identical dictionary passed to `agg`
funcs = {
    'energy': {
        'total_energy': 'sum',
        'energy_p98': lambda x: np.percentile(x, 98),  # lambda
        'energy_p17': lambda x: np.percentile(x, 17),  # lambda
    },
    'distance': {
        'total_distance': 'sum',
        'average_distance': 'mean',
        'distance_mad': smrb.mad,   # original function
        'distance_mad_c1': mad_c1,  # partial function wrapping the original function
    },
}

# Write a proxy method to be passed to `pipe`
def agg_assign(gb, fdict):
    data = {
        (cl, nm): gb[cl].agg(fn)
        for cl, d in fdict.items()
        for nm, fn in d.items()
    }
    return pd.DataFrame(data)

# All the API we need already exists with `pipe`
mydf.groupby('cat').pipe(agg_assign, fdict=funcs)

जिसके परिणामस्वरूप

            distance                                                 energy                        
    average_distance distance_mad distance_mad_c1 total_distance energy_p17 energy_p98 total_energy
cat                                                                                                
A              1.480     0.355825           0.240           4.44     1.8510     2.0364         5.79
B              0.915     0.140847           0.095           1.83     1.3095     1.5930         2.85
C              0.600     0.000000           0.000           0.60     1.0100     1.0100         1.01

pipe विधि कई मामलों में नए एपीआई को अनावश्यक जोड़ देती है। यह उस पदावनत कार्यक्षमता के प्रतिस्थापन के लिए साधन भी प्रदान करता है जिसकी हम चर्चा कर रहे हैं। इसलिए, मैं बहिष्करण के साथ आगे बढ़ने के लिए इच्छुक हूं।

मुझे वास्तव में tdpetro का विचार पसंद है - उपयोग करने के लिए: names=name_dict ।

यह सभी को खुश कर सकता है। यह हमें अपनी इच्छानुसार आसानी से कॉलम का नाम बदलने की संभावना देता है।

वास्तव में नहीं, जैसा कि मेरी प्रारंभिक पोस्ट में बताया गया है, यह उस स्थान को डीकॉप्लिंग करने के मुद्दे को हल नहीं करेगा जहां परिणामी कॉलम के नाम से कुल ऑपरेशन परिभाषित किया गया है, यह सुनिश्चित करने के लिए अतिरिक्त प्रयास की आवश्यकता है कि दोनों "सिंक्रनाइज़" हैं।

मैं यह नहीं कहता कि यह एक बुरा समाधान है (आखिरकार यह अन्य मुद्दों को हल करता है), लेकिन यह उतना आसान और स्पष्ट नहीं होगा जितना कि तानाशाही दृष्टिकोण। मेरा मतलब यहां है कि लेखन के समय आपको सूचियों के दोनों डिक्ट्स को सिंक्रनाइज़ करने की आवश्यकता होती है, और स्रोत को पढ़ते समय, पाठक को सूचियों के पहले निर्देश में कुल परिभाषा के साथ सूचियों के दूसरे निर्देश में नामों का मिलान करने का प्रयास करना चाहिए। यह प्रत्येक मामले में दो बार प्रयास है।

नेस्टेड डिक्ट्स कुछ जटिल हैं लेकिन उन्हें लिखने से यह स्पष्ट हो जाता है कि क्या हो रहा है।

मुझे अभी भी समझ में नहीं आया कि हर कोई ऐसा क्यों कहता है कि तानाशाही जटिल है। मेरे लिए यह करने का यह सबसे स्पष्ट तरीका है।

उस ने कहा, यदि names कीवर्ड एकमात्र समाधान है जिसके साथ पांडा टीम सहज है, तो यह अभी भी वर्तमान स्थिति में सुधार होगा।

@pirsquared वर्तमान एपीआई के साथ दिलचस्प समाधान। यद्यपि मेरी राय में समझना काफी आसान नहीं है (मैं वास्तव में यह नहीं समझता कि यह कैसे काम करता है: भ्रमित:)

मैंने डेटासाइंस सब्रेडिट पर एक सूत्र शुरू किया - आप पांडा के बारे में क्या नफरत करते हैं? . किसी ने groupby बाद लौटे मल्टीइंडेक्स के लिए अपनी अवमानना ​​​​को लाया और dplyr do क्रिया की ओर इशारा किया जिसे plydata में लागू किया गया है । यह बिल्कुल agg_assign रूप में काम करता है, इसलिए यह काफी दिलचस्प था।

@zertrin agg_assign आपके तानाशाही दृष्टिकोण से बेहतर होगा और sql एग्रीगेशन के समान होगा और साथ ही कई कॉलम को एग्रीगेशन के भीतर एक दूसरे के साथ इंटरैक्ट करने की अनुमति देगा। यह समान रूप से DataFrame.assign भी काम करेगा।

कोई विचार @jreback @TomAugspurger ?

...
mydf.groupby('cat').agg(agg_dict, name=name_dict, drop_index=True)

यद्यपि यह समस्या को हल करता है, किसी को दो स्थानों पर कुंजियों और मूल्यों को संरेखित करने की आवश्यकता होती है। मुझे लगता है कि एक एपीआई (जैसा कि .agg_assign लिए सुझाया गया है) जिसे ऐसे बुक-कीपिंग कोड की आवश्यकता नहीं है, कम त्रुटि प्रवण है।

एपीआई का उपयोग करने के बाद क्लीन अप कोड का मुद्दा भी है। जब groupby संचालन MultiIndex डेटाफ़्रेम लौटाता है, तो अधिकांश मामलों में उपयोगकर्ता MultiIndex पूर्ववत कर देता है। .agg_assign का उपयोग करने का सीधा आगे की घोषणात्मक तरीका, कोई पदानुक्रम नहीं, कोई MultiIndex आउटपुट नहीं, बाद में कोई सफाई नहीं करता है।

उपयोग पैटर्न के आधार पर, मुझे लगता है कि बहु-सूचकांक आउटपुट सख्ती से ऑप्ट-इन होना चाहिए और ऑप्ट-आउट नहीं होना चाहिए।

मैं शुरू में agg_assign प्रस्ताव के बारे में उलझन में था, लेकिन पिछली दो टिप्पणियों ने मुझे आश्वस्त किया है कि यह एक अच्छा समाधान हो सकता है।

विशेष रूप से agg_assign(**relabeling_dict) के रूप में इसका उपयोग करने की संभावना के बारे में सोचते हुए और इस प्रकार मेरे relabeling_dict को इस तरह परिभाषित करने में सक्षम हो:

relabeling_dict = {
    'energy_sum': lambda x: x.energy.sum(),
    'energy_p98': lambda x: np.percentile(x.energy, 98),
    'energy_p17': lambda x: np.percentile(x.energy, 17),
    'distance_sum': lambda x: x.distance.sum(),
    'distance_mean': lambda x: x.distance.mean(),
    'distance_mad': lambda x: smrb.mad(x.distance),
    'distance_mad_c1': lambda x: mad_c1(x.distance)
}

यह काफी लचीला होगा और मेरे ओपी में उल्लिखित सभी मुद्दों को हल करेगा।

@Zertrin @has2k1

मैं इसके बारे में कुछ और सोच रहा था और यह कार्यक्षमता पहले से मौजूद है apply । आप बस एक श्रृंखला को इंडेक्स के साथ नए कॉलम नामों और मूल्यों के रूप में एकत्रीकरण के रूप में वापस कर देते हैं। यह नाम में रिक्त स्थान की अनुमति देता है और आपको कॉलम को ठीक उसी तरह ऑर्डर करने की क्षमता देता है जैसे आप चाहते हैं:

def my_agg(x):
    data = {'energy_sum': x.energy.sum(),
            'energy_p98': np.percentile(x.energy, 98),
            'energy_p17': np.percentile(x.energy, 17),
            'distance sum' : x.distance.sum(),
            'distance mean': x.distance.mean(),
            'distance MAD': smrb.mad(x.distance),
            'distance MAD C1': mad_c1(x.distance)}
    return pd.Series(data, index=list_of_column_order)

mydf.groupby('cat').apply(my_agg)

इसलिए, एक नई विधि की आवश्यकता नहीं हो सकती है और इसके बजाय डॉक्स में सिर्फ एक बेहतर उदाहरण है।

@tdpetrou , आप सही हैं। मैं भूल गया था कि कैसे apply काम करता है क्योंकि मैं अपने स्वयं के संस्करण का उपयोग करता हूं क्योंकि तेज-धीमी पथ चयन प्रक्रिया में दोहरे निष्पादन के कारण।

हम वास्तव में, कोई मौका नहीं है कि मैंने इसे केवल दस्तावेज़ को पढ़कर एकत्रीकरण संदर्भ में उपयोग करने के बारे में सोचा होगा ...
इसके अलावा, मैं अभी भी apply थोड़ा बहुत जटिल समाधान ढूंढता हूं। agg_assign दृष्टिकोण अधिक सीधा और समझने योग्य लग रहा था।

चूंकि इसके बारे में वास्तव में कोई बयान नहीं था, क्या dict-of-dict दृष्टिकोण (जो वर्तमान में बहिष्कृत है, पहले से ही लागू है और इन सभी मुद्दों को हल करता है) वास्तव में निश्चित रूप से सवाल से बाहर है?

agg_assign दृष्टिकोण को छोड़कर, dict-of-dict अभी भी सबसे सरल लगता है, और किसी भी कोडिंग की आवश्यकता नहीं है, बस गैर-पदावनत करना।

agg_assign दृष्टिकोण का लाभ और दोष यह है कि यह स्तंभ चयन को एकत्रीकरण विधि में धकेलता है। सभी उदाहरणों में, x करने के लिए पारित कर दिया lambda की तरह कुछ है self.get_group(group) में प्रत्येक समूह के लिए self , एक DataFrameGroupBy वस्तु। यह अच्छा है क्योंकि यह नामकरण को स्पष्ट रूप से अलग करता है, जो कि **kwargs , चयन से , जो कि फ़ंक्शन में है।

दोष यह है कि आपके अच्छे, सामान्य एकत्रीकरण कार्यों को अब कॉलम चयन से संबंधित होना चाहिए। कोई मुफ्त लंच नहीं है! इसका मतलब है कि आप lambda x: x[col].min जैसे कई सहायकों के साथ समाप्त हो जाएंगे। आपको np.min जैसी चीजों से भी सावधान रहने की आवश्यकता होगी, जो सभी आयामों को कम करता है, बनाम pd.DataFrame.min , जो axis=0 से अधिक कम करता है। यही कारण है कि जैसे कुछ agg_assign के बराबर नहीं होगा apply । apply अभी भी कुछ तरीकों के लिए कॉलम-वार संचालित होता है।

मैं इन ट्रेडऑफ़ बनाम तानाशाही पद्धति के बारे में निश्चित नहीं हूं, लेकिन मैं अन्य लोगों के विचारों को सुनने के लिए उत्सुक हूं। यहां agg_assign का एक मोटा स्केच दिया गया है, जिसे मैंने कॉल किया है जिसे मैंने agg_table ताकि इस बात पर जोर दिया जा सके कि फ़ंक्शन टेबल पास किए जा रहे हैं, कॉलम नहीं:

from collections import defaultdict

import pandas as pd
import numpy as np
from pandas.core.groupby import DataFrameGroupBy

mydf = pd.DataFrame(
    {
        'cat': ['A', 'A', 'A', 'B', 'B', 'C'],
        'energy': [1.8, 1.95, 2.04, 1.25, 1.6, 1.01],
        'distance': [1.2, 1.5, 1.74, 0.82, 1.01, 0.6]
    },
    index=range(6)
)


def agg_table(self, **kwargs):
    output = defaultdict(dict)
    for group in self.groups:
        for k, v in kwargs.items():
            output[k][group] = v(self.get_group(group))

    return pd.concat([pd.Series(output[k]) for k in output],
                     keys=list(output),
                     axis=1)

DataFrameGroupBy.agg_table = agg_table

प्रयोग

>>> gr = mydf.groupby("cat")
>>> gr.agg_table(n=len,
                 foo=lambda x: x.energy.min(),
                 bar=lambda y: y.distance.min())

   n   foo   bar
A  3  1.80  1.20
B  2  1.25  0.82
C  1  1.01  0.60

मुझे संदेह है कि हम इस प्रदर्शन को कम भयानक बनाने के लिए कुछ कर सकते हैं, लेकिन लगभग उतना नहीं जितना .agg करता है...

क्या पंडों की कोर टीम में से कोई कृपया बता सकता है कि groupby.agg में डिक्ट्स को फिर से लेबल करने का मुख्य कारण क्या है?

मैं आसानी से समझ सकता था कि क्या यह कोड को बनाए रखने के लिए बहुत अधिक समस्याएं पैदा करता है, लेकिन अगर यह अंतिम उपयोगकर्ता के लिए जटिलता के बारे में है - तो मैं इसे वापस लाने का विकल्प भी चुनूंगा, क्योंकि यह आवश्यक कामकाज की तुलना में बहुत स्पष्ट है ...

आपको धन्यवाद!

क्या पंडों की कोर टीम में से कोई कृपया बता सकता है कि groupby.agg में डिक्ट्स को फिर से लेबल करने का मुख्य कारण क्या है?

क्या आपने https://github.com/pandas-dev/pandas/pull/15931/files#diff -52364fb643114f3349390ad6bcf24d8fR461 देखा?

प्राथमिक कारण यह था कि दो काम करने के लिए तानाशाही चाबियों को अतिभारित किया गया था। सीरीज/सीरीज ग्रुपबी के लिए, वे नामकरण के लिए हैं। DataFrame/DataFrameGroupBy के लिए, वे एक कॉलम चुनने के लिए हैं।

In [32]: mydf.aggregate({"distance": "min"})
Out[32]:
distance    0.6
dtype: float64

In [33]: mydf.aggregate({"distance": {"foo": "min"}})
/Users/taugspurger/Envs/pandas-dev/bin/ipython:1: FutureWarning: using a dict with renaming is deprecated and will be removed in a future version
  #!/Users/taugspurger/Envs/pandas-dev/bin/python3.6
Out[33]:
     distance
foo       0.6

In [34]: mydf.distance.agg({"foo": "min"})
Out[34]:
foo    0.6
Name: distance, dtype: float64

In [35]: mydf.groupby("cat").agg({"distance": {"foo": "min"}})
/Users/taugspurger/Envs/pandas-dev/lib/python3.6/site-packages/pandas/pandas/core/groupby.py:4201: FutureWarning: using a dict with renaming is deprecated and will be removed in a future version
  return super(DataFrameGroupBy, self).aggregate(arg, *args, **kwargs)
Out[35]:
    distance
         foo
cat
A       1.20
B       0.82
C       0.60

In [36]: mydf.groupby("cat").distance.agg({"foo": "min"})
/Users/taugspurger/Envs/pandas-dev/bin/ipython:1: FutureWarning: using a dict on a Series for aggregation
is deprecated and will be removed in a future version
  #!/Users/taugspurger/Envs/pandas-dev/bin/python3.6
Out[36]:
      foo
cat
A    1.20
B    0.82
C    0.60

यह शायद पंडों में सबसे भ्रमित करने वाली बात नहीं है, इसलिए शायद हम इसे फिर से देख सकते हैं :) मैं शायद कुछ किनारे के मामलों को याद कर रहा हूं। लेकिन भले ही हम तानाशाही एकत्रीकरण को हटा दें, फिर भी हमारे पास नामकरण और स्तंभ चयन के बीच असंगति है:

Series/SeriesGroupBy के लिए डिक्शनरी कीज़ हमेशा आउटपुट के नामकरण के लिए होती हैं।

DataFrame / DataFrameGroupby के लिए, तानाशाही कुंजियाँ हमेशा चयन के लिए होती हैं। dict-of-dicts के साथ हम एक कॉलम का चयन करते हैं, और फिर आंतरिक निर्देश आउटपुट के नामकरण के लिए होता है, जैसे Series / SeriesGroupBy।

हमने पहले इस पर संक्षेप में चर्चा की थी (कहीं न कहीं बहिष्करण के बारे में लंबी चर्चा में), और मैंने यहाँ कुछ ऐसा ही प्रस्तावित किया: https://github.com/pandas-dev/pandas/pull/14668#issuecomment -274508089। लेकिन अंत में केवल बहिष्करण लागू किया गया था, न कि डिक्ट्स ('नाम बदलने' फ़ंक्शन) का उपयोग करने की अन्य कार्यक्षमता को आसान बनाने के विचार।

समस्या यह थी कि dicts दोनों का उपयोग 'चयन' (आप किस कॉलम पर यह फ़ंक्शन लागू करना चाहते हैं) और 'नामकरण' (इस फ़ंक्शन को लागू करते समय परिणामी कॉलम नाम क्या होना चाहिए) के लिए उपयोग किया जाता था। एक वैकल्पिक सिंटैक्स, डिक्ट्स के अलावा, कीवर्ड तर्क हो सकता है, जैसा कि यहां agg_assign प्रस्ताव में चर्चा की गई है।
मैं अभी भी इस संभावना का पता लगाने के पक्ष में हूं, चाहे वह agg ही हो या agg_assign जैसी नई विधि में।

जो मैंने वापस प्रस्तावित किया था वह agg_assign जैसा कुछ था लेकिन लैम्ब्डा फ़ंक्शन के बजाय प्रति कीवर्ड एक ताना का उपयोग करना। यहां उदाहरण के लिए अनुवादित, यह कुछ ऐसा होगा:

mydf.groupby('cat').agg(
    energy_sum={'energy': 'sum'},
    energy_p98={'energy': lambda x: np.percentile(x, 98)},
    energy_p17={'energy': lambda x: np.percentile(x, 17)},
    distance_sum={'distance': 'sum'},
    distance_mean={'distance': 'mean'},
    distance_mad={'distance': smrb.mad},
    distance_mad_c1={'distance': mad_c1})

मुझे यकीन नहीं है कि यह सभी लैम्ब्डा के साथ संस्करण के रूप में लिखना आवश्यक रूप से अधिक पठनीय या आसान है, लेकिन, यह संभावित रूप से अधिक प्रदर्शनकारी हो सकता है, क्योंकि पांडा अभी भी उन स्तंभों पर योग, माध्य आदि के लिए अनुकूलित कार्यान्वयन का उपयोग कर सकते हैं जहां आप करते हैं लैम्ब्डा या उपयोगकर्ता निर्दिष्ट फ़ंक्शन नहीं है।

इस दृष्टिकोण के साथ एक बड़ा प्रश्न यह होगा कि df.groupby('cat').agg(foo='mean') क्या अर्थ होगा? यह तार्किक रूप से सभी स्तंभों पर 'माध्य' लागू करेगा क्योंकि आपने कोई चयन नहीं किया (पहले {'col1' : {'foo': 'mean'}, 'col2': {'foo':'mean'}, 'col3': ...} समान)। लेकिन, इसके परिणामस्वरूप बहु-अनुक्रमित कॉलम होंगे, जबकि ऊपर के उदाहरण में मुझे लगता है कि एमआई कॉलम के साथ समाप्त नहीं होना अच्छा होगा।

मुझे लगता है कि उपरोक्त को मौजूदा agg के अंदर पीछे की ओर संगत किया जा सकता है, लेकिन सवाल यह है कि क्या इसकी आवश्यकता है।
मुझे यह भी लगता है कि यह अच्छी तरह से series मामले में विस्तारित होगा जैसे:

mydf.groupby('cat').distance.agg(
    distance_sum='sum',
    distance_mean='mean',
    distance_mad=smrb.mad,
    distance_mad_c1=mad_c1)

(और आप उपरोक्त एक बार 'दूरी' के लिए और एक बार 'ऊर्जा' के लिए भी विचार कर सकते हैं और यदि आप सभी डिक्ट्स/लैम्ब्डा पसंद नहीं करते हैं तो परिणाम प्राप्त करें)

@TomAugspurger आपके उदाहरण में agg_table सरल कार्यान्वयन में, समूहों को पुनरावृत्त करने के बजाय, लागू किए जाने वाले विभिन्न कार्यों पर पुनरावृति करना बेहतर नहीं होगा, और अंत में अक्ष = 1 द्वारा नए कॉलम को जोड़ना अक्ष = 0 द्वारा नवगठित पंक्तियों को जोड़ने के बजाय?

BTW, @zertrin @tdpetrou @smcateer @pirsquared और अन्य, इस मुद्दे को उठाने और इस तरह की विस्तृत प्रतिक्रिया देने के लिए बहुत-बहुत धन्यवाद। इस तरह की प्रतिक्रिया और सामुदायिक भागीदारी बहुत महत्वपूर्ण है!

मुझे वास्तव में @tdpetrou द्वारा सुझाए गए पैटर्न को डिक्ट्स के निर्देश से भी बेहतर।

यदि फ़ंक्शन pd.Series(data, index=data.keys()) लौटाता है तो क्या हमें सूचकांकों को सही क्रम में प्राप्त करने की गारंटी है? (बस इस बारे में सोच रहा हूं कि मेरे कोड में पैटर्न को सर्वोत्तम तरीके से कैसे कार्यान्वित किया जाए - विषय से बाहर निकलने के जोखिम पर)।

संपादित करें: क्षमा करें, मैंने इंडेक्स तर्क के बिंदु को गलत समझा (यह यहां वैकल्पिक है, केवल तभी आवश्यक है जब आप कॉलम के क्रम को निर्दिष्ट करना चाहते हैं - pd.Series(data) लौटाना मेरे लिए काम करता है)।

क्या @tdpetrou का उदाहरण first और last एकत्रीकरण के साथ काम करेगा?

मुझे इस तरह सिर/पूंछ का सहारा लेना पड़ा

def agg_funcs(x):
    data = {'start':x['DATE_TIME'].head(1).values[0],
           'finish':x['DATE_TIME'].tail(1).values[0],
           'events':len(x['DATE_TIME'])}
    return pd.Series(data, index = list(data.keys()))

results = df.groupby('col').apply(agg_funcs)

मैं अब भी इसे संबोधित करना चाहूंगा, लेकिन मुझे नहीं लगता कि यह 0.23 के लिए किया जाएगा।

क्या @tdpetrou का दृष्टिकोण किसी फ़ंक्शन को परिभाषित किए बिना काम कर सकता है जिसे हम अपने कोड में फिर कभी उपयोग नहीं करेंगे? एक क्यू/केडीबी+ दुनिया से आ रहा है (एसक्यूएल के समान) मैं उलझन में हूं कि हमें एक साधारण चयन कथन के लिए कोई अस्थायी चर/फ़ंक्शन बनाने की आवश्यकता क्यों है।

यहां ओ.पी.

ईमानदारी से कहूं तो इतने समय के बाद और #15931 और यहां पर काफी चर्चा के बाद भी, मुझे अभी भी यकीन नहीं हो रहा है कि यह एक अच्छा विचार है कि री-लेबलिंग डिक्ट्स को हटा दिया जाए।

अंत में, यहां प्रस्तावित विकल्पों में से कोई भी मौजूदा रीलैबलिंग तानाशाही दृष्टिकोण IMHO की तुलना में उपयोगकर्ताओं के लिए अधिक सहज नहीं है। जब यह दस्तावेज़ीकरण में था, केवल एक उदाहरण से यह स्पष्ट था कि यह कैसे काम करता है, और यह बहुत लचीला है।

बेशक पांडा डेवलपर्स अभी भी अन्यथा सोच सकते हैं, बस एक उपयोगकर्ता के दृष्टिकोण के साथ झूमते हुए।

यहां तक ​​​​कि रीलेबलिंग तानाशाही दृष्टिकोण भी बहुत सहज नहीं है। मेरी राय में वाक्यविन्यास SQL ​​- func(column_name) as new_column_name समान होना चाहिए। पायथन में हम इसे तीन-आइटम टपल के साथ कर सकते हैं। (func, column_name, new_column_name) । इस प्रकार डेक्सप्लो ग्रुपबाय एग्रीगेशन करता है।

@zertrin क्या आपके पास उपरोक्त मेरे प्रस्ताव पर प्रतिक्रिया है: https://github.com/pandas-dev/pandas/issues/18366/#issuecomment -349089667
अंत में, यह तानाशाही के क्रम को उलट देता है: "{col: {name: func}}" के बजाय यह "**{name: {col: func}}" जैसा होगा।

@jorisvandenbossche मैंने आपके दृष्टिकोण पर विचार किया है। बात यह है कि, मैं वास्तव में यह नहीं देखता कि यह वर्तमान दृष्टिकोण पर क्या अतिरिक्त लाभ लाता है।

इसे और अधिक स्पष्ट रूप से कहने के लिए, निम्नलिखित विकल्प दिए गए हैं:

1. वर्तमान व्यवहार को कम करें जो अच्छी तरह से काम करता है (हटाने के लिए बहिष्करण कोड की कुछ पंक्तियाँ, हटाए गए दस्तावेज़ के टुकड़े को फिर से जोड़ें)
2. अपने प्रस्ताव को लागू करें (कोड में किए जाने वाले महत्वपूर्ण परिवर्तन, वर्तमान दृष्टिकोण की अवहेलना के साथ आगे बढ़ें, सभी उपयोगकर्ताओं के लिए अपने कोड को अनुकूलित करने की आवश्यकता)

मुझे नहीं लगता कि हमें 2 क्यों चुनना चाहिए जब तक कि यह एक डेवलपर और उपयोगकर्ता परिप्रेक्ष्य से सार्थक और ठोस लाभ न लाए।

ऊपर अपने प्रस्ताव में कुछ बिंदुओं को संबोधित करने के लिए:

समस्या यह थी कि dicts दोनों का उपयोग 'चयन' (आप किस कॉलम पर यह फ़ंक्शन लागू करना चाहते हैं) और 'नामकरण' (इस फ़ंक्शन को लागू करते समय परिणामी कॉलम नाम क्या होना चाहिए) के लिए उपयोग किया जाता था।

चूंकि इसे पहले अच्छी तरह से प्रलेखित किया गया था, मुझे विश्वास नहीं है कि यह उपयोगकर्ताओं के लिए एक मुद्दा था। व्यक्तिगत रूप से, मुझे दस्तावेज़ीकरण में उदाहरणों को तुरंत देखने का बिंदु मिला। (संपादित करें: और मैंने सोचा: _ "याय! बहुत उपयोगी निर्माण, यह बिल्कुल वही मेल खाता है जो मैं ढूंढ रहा था। अच्छा।"_)

एक वैकल्पिक सिंटैक्स, डिक्ट्स के अलावा, कीवर्ड तर्क हो सकता है

तानाशाही दृष्टिकोण का उपयोग करने के लिए आकर्षक चीजों में से एक यह है कि उपयोगकर्ता इसे आसानी से किसी अन्य कोड के साथ गतिशील रूप से उत्पन्न कर सकते हैं। जैसा कि आपने इस एक के ठीक ऊपर टिप्पणी में बताया, आपके प्रस्ताव के अनुसार कीवर्ड तर्कों पर जाने से अभी भी **{name: {col: func}} निर्माण के माध्यम से इसके लिए अनुमति मिलेगी। इसलिए मैं आपके प्रस्ताव के खिलाफ नहीं हूं। जब हम पहले से ही वर्तमान कार्यान्वित प्रणाली के साथ समान स्तर की कार्यक्षमता प्राप्त करते हैं, तो मुझे मूल्य वर्धित और ऐसे परिवर्तनों की आवश्यकता दिखाई नहीं देती है।

अंत में, आपका प्रस्ताव _ठीक है यदि पांडा कोर देव वर्तमान दृष्टिकोण के खिलाफ एक मजबूत भावना रखते हैं। मुझे _user_ के रूप में कोई लाभ नहीं दिख रहा है। (वास्तव में मुझे नए प्रस्ताव के साथ इसे फिर से काम करने के लिए सभी मौजूदा उपयोगकर्ता कोड बदलने की कमी दिखाई दे रही है)।

@zertrin हमने कल कुछ मुख्य पहले , केवल कल के हमारे विचारों को प्रतिबिंबित करने के लिए ऐसा करने जा रहा हूं।

तो सबसे पहले, यह धारणा कि SQL "SELECT avg(col2) as col2_avg" जैसी बुनियादी कार्यक्षमता काम करना चाहिए और आसान होना चाहिए, कुछ ऐसा है जिस पर हम पूरी तरह सहमत हैं, और हम वास्तव में इसके लिए एक समाधान चाहते हैं।

मूल कारणों के अलावा हमने इसे (जो इतना मजबूत हो भी सकता है और नहीं भी) को पदावनत करने का फैसला किया, वर्तमान (बहिष्कृत) dicts भी आदर्श नहीं है , क्योंकि यह एक मल्टीइंडेक्स बनाता है जिसे आप वास्तव में कभी नहीं चाहते हैं:

In [1]: df = pd.DataFrame({'A': ['a', 'b', 'a'], 'B': range(3), 'C': [.1, .2, .3]})

In [3]: gr = df.groupby('A')

In [4]: gr.agg({'B': {'b_sum': 'sum'}, 'C': {'c_mean': 'mean', 'c_count': 'count'}})
Out[4]: 
        C            B
  c_count c_mean b_sum
A                     
a       2    0.2     2
b       1    0.2     1

उपरोक्त में, मल्टीइंडेक्स का पहला स्तर अतिश्योक्तिपूर्ण है, क्योंकि आपने पहले से ही विशेष रूप से कॉलम का नाम बदल दिया है (उदाहरण में ओपी में, यह सीधे कॉलम के पहले स्तर को छोड़कर भी है)।
हालांकि इसे बदलना मुश्किल है क्योंकि आप gr.agg(['sum', 'mean']) या (मिश्रित) gr.agg({'B': ['sum', 'mean'], 'C': {'c_mean': 'mean', 'c_count': 'count'}}) जैसी चीजें भी कर सकते हैं, यदि मल्टीइंडेक्स की आवश्यकता है और समझ में आता है।

तो उपरोक्त चर्चा में उल्लिखित प्रस्तावों में से एक, अंतिम कॉलम नामों को अलग से निर्दिष्ट करने का एक तरीका था (उदाहरण के लिए https://github.com/pandas-dev/pandas/issues/18366#issuecomment-346683449)।
उदाहरण के लिए कॉलम नाम निर्दिष्ट करने के लिए aggregate एक अतिरिक्त कीवर्ड जोड़ना, जैसे

gr.agg({'B': 'sum', 'C': ['mean', 'count']}, columns=['b_sum', 'c_mean', 'c_count'])

संभव होगा।
हालांकि, अगर हम कॉलम/फ़ंक्शन विनिर्देश और नए कॉलम नामों को विभाजित करते हैं, तो हम इसे नए कीवर्ड की तुलना में अधिक सामान्य बना सकते हैं, और कुछ ऐसा कर सकते हैं:

gr.agg({'B': 'sum', 'C': ['mean', 'count']}).rename(columns=['b_sum', 'c_mean', 'c_count'])

इसे हल करने के लिए https://github.com/pandas-dev/pandas/issues/14829 की जरूरत है (कुछ ऐसा जो हम 0.24.0 के लिए करना चाहते हैं)।
(महत्वपूर्ण नोट: इस के लिए हम तो हम नाम के स्वत: डिडुप्लीकेशन किसी तरह का क्या करना चाहिए अगर हम इस समाधान का समर्थन करना चाहते, लैम्ब्डा कार्यों के नकली नाम इस समस्या को ठीक करने की आवश्यकता है।)

फिर, हम अभी भी नाम बदलने के लिए कीवर्ड तर्कों के तरीके को पसंद करते हैं। इसके कारण हैं:

• यह पंडों में assign काम करने के तरीके के समान है, और यह भी संगत है कि कैसे groupby().aggregate() ibis में काम करता है (और यह भी इसी तरह दिखता है जैसे R में dplyr)
• यह सीधे आपको गैर-पदानुक्रमित कॉलम नाम देता है जो आप चाहते हैं (कोई मल्टीइंडेक्स नहीं)
• साधारण मामलों के लिए (उदाहरण के लिए श्रृंखला मामले के लिए भी), मुझे लगता है कि यह तानाशाही के रूप में सरल है

हमने अभी भी थोड़ी चर्चा की थी कि यह कैसा दिख सकता है। जो मैंने ऊपर प्रस्तावित किया था (मेरे पहले उदाहरणों में समकक्ष कॉलम/फ़ंक्शन चयन का उपयोग करने के लिए):

gr.agg(b_sum={'B': 'sum'}, c_mean={'C': 'mean'}, c_count={'C': 'count'})

आप अभी भी इस विनिर्देश को तानाशाही के रूप में बना सकते हैं, लेकिन वर्तमान (बहिष्कृत) संस्करण की तुलना में आंतरिक और बाहरी स्तर की अदला-बदली के साथ:

gr.agg(**{'b_sum': {'B': 'sum'}, 'c_mean': {'C': 'mean'}, 'c_count': {'C': 'count'})

(हमारे पास एक उदाहरण सहायक कार्य हो सकता है जो मौजूदा संस्करण के डिक्ट्स को इस संस्करण में परिवर्तित करता है)

हालाँकि, तानाशाही हमेशा केवल एक ही होती है {col: func} , और वे कई एकल तत्व dicts थोड़े अजीब लगते हैं। तो हमने सोचा कि एक विकल्प टुपल्स का उपयोग करना है:

gr.agg(b_sum=('B', 'sum'), c_mean=('C', 'mean'), c_count=('C', 'count'))

यह थोड़ा बेहतर दिखता है, लेकिन दूसरी ओर {'B': 'sum'} dict अन्य एपीआई के साथ संगत है जिस पर फ़ंक्शन को लागू करने के लिए कॉलम निर्दिष्ट करना है।

ऊपर दिए गए दोनों सुझाव (बाद में आसान नामकरण, और कीवर्ड-आधारित नामकरण) सैद्धांतिक रूप से ऑर्थोगोनल हैं, लेकिन दोनों (या अभी भी आगे की चर्चा के आधार पर कुछ और) के लिए अच्छा हो सकता है।

देवों के वर्तमान विचारों को यहाँ अग्रेषित करने के लिए धन्यवाद

मैं परिणामी मल्टीइंडेक्स के साथ बहिष्कृत तानाशाही दृष्टिकोण की (मेरी राय में, केवल) दोष को स्वीकार करता हूं। यदि उपयोगकर्ता एक अतिरिक्त विकल्प पास करता है तो इसे चपटा किया जा सकता है (हाँ YAO :-/)।

जैसा कि उल्लेख किया गया है, मैं दूसरे संस्करण के खिलाफ नहीं हूं, जब तक कि यह संभव हो:

• चीजों को गतिशील रूप से किसी भी तरह उत्पन्न करें और इसे अनपैक करें ( **{} निर्माण के लिए धन्यवाद, याय पायथन!)
• नामकरण और एकत्रीकरण विनिर्देश को एक साथ बंद रखें (दो सूचियों का ट्रैक रखना जैसे कि उनका आदेश वही रहता है जो उपयोगकर्ता आईएमएचओ के रूप में स्पष्ट रूप से परेशान है)
• (संभावित रूप से कमी या विरोध) फ़ंक्शन नामों के कारण वर्कअराउंड की आवश्यकता के बिना लैम्ब्डा या आंशिक कार्यों का उपयोग करें।

जैसे, अंतिम सुझाव (col> func मैपिंग के लिए dicts या tuples के साथ) ठीक है, मुझे लगता है।

पिछली टिप्पणी में पहला प्रस्ताव लागू किया जा सकता है यदि आप वास्तव में चाहते हैं, लेकिन इस पर मेरी प्रतिक्रिया यह है कि, एक उपयोगकर्ता के रूप में, मैं चीजों को सिंक में रखने के दर्द के कारण दूसरे विकल्प पर इसका उपयोग नहीं करना चाहता हूं। दो सूचियाँ।

आज देव बैठक में चर्चा की।

संक्षिप्त सारांश

1. @jorisvandenbossche gr.agg(b_sum=("B", "sum), ...) को लागू करने का प्रयास करेगा, अर्थात जब कोई arg पास नहीं है *GroupBy.agg , तो kwargs को <output_name>=(<selection>, <aggfunc>) रूप में समझें
2. ओर्थोगोनल इस मुद्दों के लिए, हम लागू करना चाहते हैं MutliIndex.flatten और एक प्रदान flatten=True कीवर्ड को .agg

शायद यह मदद करता है: पदावनति के लिए मेरा समाधान ये सहायक कार्य हैं जो उपनाम की जगह लेते हैं-> aggr मानचित्रों को सही ढंग से नामित कार्यों की सूची के साथ:

def aliased_aggr(aggr, name):
    if isinstance(aggr,str):
        def f(data):
            return data.agg(aggr)
    else:
        def f(data):
            return aggr(data)
    f.__name__ = name
    return f

def convert_aggr_spec(aggr_spec):
    return {
        col : [ 
            aliased_aggr(aggr,alias) for alias, aggr in aggr_map.items() 
        ]  
        for col, aggr_map in aggr_spec.items() 
    }

जो इसके साथ पुराना व्यवहार देता है:

mydf_agg = mydf.groupby('cat').agg(convert_aggr_spec{
    'energy': {
        'total_energy': 'sum',
        'energy_p98': lambda x: np.percentile(x, 98),  # lambda
        'energy_p17': lambda x: np.percentile(x, 17),  # lambda
    },
    'distance': {
        'total_distance': 'sum',
        'average_distance': 'mean',
        'distance_mad': smrb.mad,   # original function
        'distance_mad_c1': mad_c1,  # partial function wrapping the original function
    },
}))

जो समान है

mydf_agg = mydf.groupby('cat').agg({
    'energy': [ 
        aliased_aggr('sum', 'total_energy'),
        aliased_aggr(lambda x: np.percentile(x, 98), 'energy_p98'),
        aliased_aggr(lambda x: np.percentile(x, 17), 'energy_p17')
    ],
    'distance': [
         aliased_aggr('sum', 'total_distance'),
         aliased_aggr('mean', 'average_distance'),
         aliased_aggr(smrb.mad, 'distance_mad'),
         aliased_aggr(mad_c1, 'distance_mad_c1'),
    ]
})

यह मेरे लिए काम करता है, लेकिन शायद कुछ कोने के मामलों में काम नहीं करेगा ...

अद्यतन : पता चला कि नामकरण आवश्यक नहीं है, क्योंकि एकत्रीकरण विनिर्देश में टुपल्स की व्याख्या (उपनाम, aggr) के रूप में की जाती है। तो alias_aggr फ़ंक्शन की आवश्यकता नहीं है, और रूपांतरण बन जाता है:

def convert_aggr_spec(aggr_spec):
    return {
        col : [ 
           (alias,aggr) for alias, aggr in aggr_map.items() 
        ]  
        for col, aggr_map in aggr_spec.items() 
    }

मैं यहां सिर्फ एक अन्य उपयोगकर्ता के रूप में झंकार करना चाहता हूं, जो वास्तव में, वास्तव में किसी भी फ़ंक्शन पर एक कॉलम को एकत्र करने की कार्यक्षमता को याद कर रहा है और तुरंत उसी पंक्ति में इसका नाम बदल रहा है। मेरे पास _never_ पांडा द्वारा लौटाए गए मल्टीइंडेक्स का उपयोग करके खुद को मिला है - मैं या तो इसे तुरंत फ़्लैट करता हूं, या मैं वास्तव में अपने कॉलम नामों को मैन्युअल रूप से निर्दिष्ट करना चाहता हूं क्योंकि उनका वास्तव में कुछ विशिष्ट मतलब है।

मुझे यहां प्रस्तावित किसी भी दृष्टिकोण से खुशी होगी: एसक्यूएल-जैसी वाक्यविन्यास (मैं वास्तव में खुद को .query() पहले से ही पांडा में बहुत कुछ का उपयोग कर पाता हूं), मूल्यह्रास व्यवहार पर वापस, अन्य सुझावों में से कोई भी। वर्तमान दृष्टिकोण ने मुझे पहले से ही उन सहयोगियों से उपहास किया जो आर का उपयोग करते हैं।

मैंने हाल ही में खुद को पंडों के बजाय पाइस्पार्क का उपयोग करते हुए पाया, भले ही यह आवश्यक नहीं था, सिर्फ इसलिए कि मुझे सिंटैक्स बहुत अधिक पसंद है:

df.groupby("whatever").agg(
    F.max("col1").alias("my_max_col"),
    F.avg("age_col").alias("average_age"),
    F.sum("col2").alias("total_yearly_payments")
)

इसके अलावा पाइस्पार्क ज्यादातर मामलों में पांडा की तुलना में लिखने के लिए और अधिक जटिल है, यह सिर्फ इतना साफ दिखता है! तो मैं निश्चित रूप से सराहना करता हूं कि इस पर काम अभी भी किया जाना है :-)

मुझे लगता है कि हमारे पास इस कार्यक्षमता के लिए एक सहमत वाक्यविन्यास है; हमें किसी की जरूरत है
इसे लागू करो।

बुधवार 27 मार्च 2019 को सुबह 9:01 बजे थॉमस कस्तल सूचनाएं @github.com
लिखा था:

मैं यहां सिर्फ एक अन्य उपयोगकर्ता के रूप में झंकार करना चाहता हूं जो वास्तव में, वास्तव में है
किसी भी फ़ंक्शन पर कॉलम को एकत्रित करने की कार्यक्षमता गुम है और
तुरंत उसी पंक्ति में उसका नाम बदलकर। मैंने खुद को कभी नहीं पाया
पांडा द्वारा लौटाए गए मल्टीइंडेक्स का उपयोग करना - मैं या तो इसे तुरंत फ़्लैट करता हूं,
या मैं वास्तव में अपने कॉलम नामों को मैन्युअल रूप से निर्दिष्ट करना चाहता हूं क्योंकि वे
वास्तव में कुछ खास मतलब है।

मुझे यहां प्रस्तावित किसी भी दृष्टिकोण से खुशी होगी: SQL जैसा सिंटैक्स
(मैं वास्तव में खुद को .query() पहले से ही पांडा में बहुत कुछ का उपयोग कर पाता हूं),
मूल्यह्रास व्यवहार पर वापस लौटना, अन्य सुझावों में से कोई भी।
वर्तमान दृष्टिकोण ने मुझे पहले से ही उन सहयोगियों से उपहास किया जो आर का उपयोग करते हैं।

मैंने हाल ही में खुद को पंडों के बजाय पाइस्पार्क का उपयोग करते हुए भी पाया है
यह आवश्यक नहीं था, सिर्फ इसलिए कि मुझे वाक्य रचना बहुत अधिक पसंद है:

df.groupby("whatever").agg(F.max("col1").alias("my_max_col"),
F.avg("age_col").alias("average_age"),
F.sum("col2").alias("total_yearly_payments") )

इसके अलावा पाइस्पार्क ज्यादातर मामलों में पंडों की तुलना में लिखने के लिए अधिक जटिल है,
यह बस इतना साफ दिखता है! तो मैं निश्चित रूप से उस काम की सराहना करता हूं
यह अभी भी किया जाना है :-)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/pandas-dev/pandas/issues/18366#issuecomment-477168767 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABQHIkCYYsah5siYA4_z0oop_ufIB3h8ks5va3nJgaJpZM4QjSLL
.

मैं इसे 0.25.0 के लिए प्राप्त करने का प्रयास करने जा रहा हूं

मैंने https://github.com/pandas-dev/pandas/pull/26399 पर एक पीआर डाला है **kwargs का उपयोग करके नाम बदलें और स्तंभ-विशिष्ट एकत्रीकरण के इस मिश्रण को इस समझ के साथ अनुमति देना है कि मान (selection, aggfunc) टुपल्स होने चाहिए।

In [2]: df = pd.DataFrame({'kind': ['cat', 'dog', 'cat', 'dog'],
   ...:                    'height': [9.1, 6.0, 9.5, 34.0],
   ...:                    'weight': [7.9, 7.5, 9.9, 198.0]})

In [3]: df
Out[3]:
  kind  height  weight
0  cat     9.1     7.9
1  dog     6.0     7.5
2  cat     9.5     9.9
3  dog    34.0   198.0

In [4]: df.groupby('kind').agg(min_height=('height', 'min'), max_weight=('weight', 'max'))
Out[4]:
      min_height  max_weight
kind
cat          9.1         9.9
dog          6.0       198.0

इसकी कुछ सीमाएँ हैं

• यह बाकी पंडों के लिए कुछ हद तक अजीब है। sytanx (output_name=(selection, aggfunc)) वास्तव में कहीं और प्रकट नहीं होता है (हालांकि .assign output_name=... पैटर्न का उपयोग करता है)
• आउटपुट नामों की वर्तनी जो अजगर पहचानकर्ता नहीं हैं बदसूरत है: .agg(**{'output name': (col, func)})
• यह केवल पायथन 3.6+ है, या हमें 3.5 और इससे पहले के कुछ बदसूरत हैक्स की आवश्यकता है, क्योंकि **kwargs का ऑर्डर पहले संरक्षित नहीं था
• aggfunc को एक यूनरी फ़ंक्शन होना चाहिए। यदि आपके कस्टम aggfunc को अतिरिक्त तर्कों की आवश्यकता है, तो आपको पहले इसे आंशिक रूप से लागू करना होगा

और एक कार्यान्वयन विवरण है, एक ही कॉलम के लिए एकाधिक lambda aggfuncs अभी तक समर्थित नहीं है, हालांकि इसे बाद में ठीक किया जा सकता है।

मुझे संदेह है कि यहां सदस्यता लेने वाले अधिकांश लोग पदावनत व्यवहार के कुछ विकल्प के समर्थक होंगे। लोग इस बारे में विशेष रूप से क्या सोचते हैं?

cc @WillAyd अगर मुझे आपकी कोई चिंता याद आती है।

हाय @TomAugspurger ,

इस कदम को आगे बढ़ाने के लिए धन्यवाद।

इसकी कुछ सीमाएँ हैं

• यह बाकी पंडों के लिए कुछ हद तक अजीब है। sytanx (output_name=(selection, aggfunc)) वास्तव में कहीं और प्रकट नहीं होता है (हालांकि .assign output_name=... पैटर्न का उपयोग करता है)

मैं मदद नहीं कर सकता लेकिन महसूस करता हूं कि इस तरह का तर्क उस तरह के समान लगता है जिसने मौजूदा कार्यान्वयन को पहले स्थान पर बहिष्कृत करने के लिए प्रेरित किया।

क्या आप साझा कर सकते हैं कि हम पुराने _उस विशेष तर्क के संबंध में इस नए तरीके से अधिक लाभान्वित क्यों हैं?

एक लाभ जो मैं पहले से सोच सकता था वह यह है कि (py3.6+ के लिए) हम अलग-अलग कॉलम के आउटपुट ऑर्डर का चयन कर सकते हैं।

• आउटपुट नामों की वर्तनी जो अजगर पहचानकर्ता नहीं हैं बदसूरत है: .agg(**{'output name': (col, func)})

वैसे तो पुराना तरीका उस लिहाज से बेहतर था। लेकिन जैसा कि मैंने पहले कहा था, जब तक गतिशील रूप से एकत्रीकरण बनाने के लिए **{...} निर्माण का उपयोग करना संभव है, मुझे काफी खुशी होगी।

• यह केवल पायथन 3.6+ है, या हमें 3.5 और इससे पहले के कुछ बदसूरत हैक्स की आवश्यकता है, क्योंकि **kwargs का ऑर्डर पहले संरक्षित नहीं था

यह पहले कैसे काम करता था (मौजूदा तानाशाही सुविधा)? क्या किसी तरह से आदेश की गारंटी थी?

• aggfunc को एक यूनरी फ़ंक्शन होना चाहिए। यदि आपके कस्टम aggfunc को अतिरिक्त तर्कों की आवश्यकता है, तो आपको पहले इसे आंशिक रूप से लागू करना होगा

बस मेरी समझ की पुष्टि करने के लिए: aggfunc कोई भी कॉल करने योग्य हो सकता है जो वैध मान देता है? ("अक्सर उपयोग की जाने वाली" स्ट्रिंग aggfungs के अलावा 'min' , 'max' , आदि)। क्या पहले की तुलना में कोई अंतर है? (यानी यूनरी सीमा पहले से मौजूद नहीं थी?)

और एक कार्यान्वयन विवरण है, एक ही कॉलम के लिए एकाधिक lambda aggfuncs अभी तक समर्थित नहीं है, हालांकि इसे बाद में ठीक किया जा सकता है।

हाँ, यह एक तरह का कष्टप्रद है, लेकिन जब तक यह सिर्फ एक अस्थायी सीमा है और इसे ठीक करने के लिए खुला है, यह काम कर सकता है।

मुझे संदेह है कि यहां सदस्यता लेने वाले अधिकांश लोग पदावनत व्यवहार के कुछ विकल्प के समर्थक होंगे। लोग इस बारे में विशेष रूप से क्या सोचते हैं?

खैर, किसी भी मामले में मुझे लगता है कि एक चरण में कुल और नाम बदलना वास्तव में महत्वपूर्ण है। यदि पुराना व्यवहार वास्तव में कोई विकल्प नहीं है, तो यह विकल्प कर सकता है।

क्या आप साझा कर सकते हैं कि हम उस विशेष तर्क के संबंध में पुराने तरीके से इस नए तरीके से अधिक लाभान्वित क्यों होते हैं।

मैं शायद गलत याद कर रहा हूं, लेकिन मेरा मानना ​​है कि SeriesGroupby.agg और DataFrameGroupby.agg के शब्दकोश में बाहरी कुंजी के बीच अलग-अलग अर्थ हैं (क्या यह कॉलम चयन या आउटपुट नामकरण है?) इस सिंटैक्स के साथ, हम लगातार कीवर्ड का मतलब आउटपुट नाम रख सकते हैं।

वैसे तो पुराना तरीका उस लिहाज से बेहतर था।

क्या अंतर सिर्फ ** ? अन्यथा मुझे लगता है कि समान सीमाएं साझा की जाती हैं।

यह पहले कैसे काम करता था (मौजूदा तानाशाही सुविधा)? क्या किसी तरह से आदेश की गारंटी थी?

चाबियों को छांटना, जो कि मैं अब पीआर में कर रहा हूं।

बस मेरी समझ की पुष्टि करने के लिए: aggfunc कोई भी कॉल करने योग्य हो सकता है जो वैध मान देता है?

यहाँ अंतर है

In [21]: df = pd.DataFrame({"A": ['a', 'a'], 'B': [1, 2], 'C': [3, 4]})

In [22]: def aggfunc(x, myarg=None):
    ...:     print(myarg)
    ...:     return sum(x)
    ...:

In [23]: df.groupby("A").agg({'B': {'foo': aggfunc}}, myarg='bar')
/Users/taugspurger/sandbox/pandas/pandas/core/groupby/generic.py:1308: FutureWarning: using a dict with renaming is deprecated and will be removed in a future version
  return super().aggregate(arg, *args, **kwargs)
None
Out[23]:
    B
  foo
A
a   3

वैकल्पिक प्रस्ताव के साथ, हम आउटपुट कॉलम नामों के लिए **kwargs आरक्षित कर रहे हैं। तो आपको functools.partitial(aggfunc, myarg='bar') ।

ठीक है धन्यवाद, मुझे लगता है कि प्रस्तावित दृष्टिकोण 👍 पहले पुनरावृत्ति के लिए है (और जैसे ही एकाधिक लैम्ब्डा कार्यान्वयन सीमा हटा दी जाती है, वास्तव में एक प्रतिस्थापन के रूप में ठीक रहेगा)