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

लेकिन व्यापक प्रश्न के अलावा, मुझे लगता है कि आपको उदाहरण देने का प्रयास करना चाहिए कि मानक अनुमानकों से पंडों के अनुकूल आउटपुट कैसे भिन्न होंगे और उपयोगिता पर फर्क पड़ेगा। उदाहरण मैं सोच सकता हूँ:

• सभी तरीके इनपुट से इंडेक्स को कॉपी कर सकते हैं
• ट्रांसफॉर्मर को उचित रूप से नामित कॉलम का उत्पादन करना चाहिए
• मल्टीक्लास प्रेडिक्ट_प्रोबा कॉलम को क्लास के नाम से लेबल कर सकता है

हाँ, मेरे सिर के ऊपर से:

• सूचकांक वास्तव में उपयोगी हो सकता है, उदाहरण के लिए समयबद्ध अंतराल चर बनाने के लिए (उदाहरण के लिए 1 दिन अंतराल, कुछ लापता दिनों के साथ दैनिक डेटा पर)
• स्केलेर रजिस्टरों को स्पष्ट रूप से स्पष्ट डेटा के साथ इस्तेमाल किया जा सकता है (मिश्रित डेटाफ्रेम पास करें, लेबलबिनाराइज़र के साथ श्रेणीबद्ध कॉलम बदलें, उलटा_ट्रांसफॉर्म इसे वापस करें)।
• sklearn-pandas पहले से ही एक अच्छा इंटरफ़ेस प्रदान करता है जो आपको डेटाफ़्रेम पास करने की अनुमति देता है, और केवल डेटा के सबसेट का उपयोग करता है, और व्यक्तिगत कॉलम को मनमाने ढंग से रूपांतरित करता है।

यदि यह सब एक परिवर्तन में है, तो यह वास्तव में प्रभावित नहीं करता है कि डिफ़ॉल्ट रूप से स्केलेर कैसे काम करता है।

मुझे नहीं लगता कि इसे ट्रांसफॉर्मर के रूप में अच्छी तरह से लागू किया जा सकता है। यह होगा
एक या अधिक मेटास्टिमेटर या मिक्सिन। मुझे लगता है कि उन्हें शुरू में होना चाहिए
बाहरी रूप से लागू किया गया और उपयोगी के रूप में प्रदर्शित किया गया

22 अक्टूबर 2015 17:40 पर, naught101 [email protected] लिखा है:

हाँ, मेरे सिर के ऊपर से:

• सूचकांक वास्तव में उपयोगी हो सकता है, उदाहरण के लिए समयबद्ध अंतराल बनाने के लिए
  चर (उदाहरण के लिए 1 दिन अंतराल, कुछ लापता दिनों के साथ दैनिक डेटा पर)
• स्पष्ट डेटा के साथ स्केलेर रजिस्टरों का पारदर्शी रूप से उपयोग किया जा सकता है
  (मिश्रित डेटाफ़्रेम पास करें, लेबलबिनाराइज़र के साथ श्रेणीबद्ध कॉलम बदलें,
  inverse_transform इसे वापस)।
• sklearn-pandas पहले से ही एक अच्छा इंटरफ़ेस प्रदान करता है जो आपको अनुमति देता है
  डेटाफ़्रेम पास करें, और केवल डेटा के सबसेट का उपयोग करें, और मनमाने ढंग से
  व्यक्तिगत स्तंभों को रूपांतरित करें।

यदि यह सब एक परिवर्तन में है, तो यह वास्तव में प्रभावित नहीं करता है कि sklearn
डिफ़ॉल्ट रूप से काम करता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/scikit-learn/scikit-learn/issues/5523#issuecomment -150123228
.

कॉलम ट्रांसफॉर्मर पीआर # 3886 के पीछे "पांडा" को बेहतर बनाना एक तरह का विचार था। शायद मुझे और अधिक बारीकी से देखना चाहिए था कि स्केलेर-पांडा पहले से क्या कर रहा है। मुझे पूरा यकीन नहीं है कि आगे बढ़ने का सबसे अच्छा तरीका क्या है।

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

संबंधित #4196

हालांकि इसके लिए इनपुट सत्यापन के साथ बड़ी सर्जरी की आवश्यकता होगी
कॉलम नामों को सुरक्षित रखें:-/

न केवल इनपुट सत्यापन: प्रत्येक परिवर्तन को यह वर्णन करना होगा कि यह क्या है
इनपुट कॉलम के लिए करता है।

सच है, लेकिन मुझे लगता है कि अच्छा होगा;)

एक सवाल शायद यह है कि क्या हम इसे केवल पाइपलाइनों में या हर जगह चाहते हैं। यदि हम इसे पाइपलाइनों तक सीमित रखते हैं, तो इनपुट सत्यापन सर्जरी कम बड़ी होगी। लेकिन मुझे यकीन नहीं है कि यह कितना उपयोगी होगा।

आप हमेशा उसमें केवल एक चीज़ के साथ एक पाइपलाइन कर सकते हैं, है ना? तो हम _तरह के_ सभी मामलों को संभालते हैं (हालांकि यह 1 ऑब्जेक्ट की सीमा में हैकी है) पहले केवल पाइपलाइन तक सीमित करके ...

+1। पाइपलाइन से शुरू करना अच्छा लगता है, और अगले चरण में सभी ट्रांसफार्मर को कवर करें।

मेरे पास पांडा और स्केलेर एकीकरण के साथ एक इम्प्लांट भी है, जो कॉलम जानकारी को inverse_transform माध्यम से वापस कर सकता है (हालांकि गंदा हैक ...)

http://pandas-ml.readthedocs.org/en/latest/sklearn.html

• सूचकांक वास्तव में उपयोगी हो सकता है, उदाहरण के लिए समयबद्ध अंतराल चर बनाने के लिए
(उदाहरण के लिए 1 दिन का अंतराल, कुछ लापता दिनों के साथ दैनिक डेटा पर)

मैं थोड़ा मूर्ख हूँ, लेकिन नमूने में कुछ के बारे में बात नहीं कर रहा हूँ
फीचर दिशा के बजाय यहां दिशा?

• स्पष्ट डेटा के साथ स्केलेर रजिस्टरों का पारदर्शी रूप से उपयोग किया जा सकता है (पास
मिश्रित डेटाफ़्रेम, लेबलबिनाराइज़र के साथ श्रेणीबद्ध स्तंभों को रूपांतरित करें,
inverse_transform इसे वापस)।

• sklearn-pandas पहले से ही एक अच्छा इंटरफ़ेस प्रदान करता है जो आपको a . पास करने की अनुमति देता है
डेटाफ़्रेम, और केवल डेटा के सबसेट का उपयोग करें, और मनमाने ढंग से रूपांतरित करें
व्यक्तिगत कॉलम।

ठीक है, लेकिन यह सब एक ट्रांसफार्मर के स्तर पर है जो पंडों को अंदर ले जाता है,
और डेटा मैट्रिक्स देता है, है ना? कोशिश करने के बजाय a
स्किकिट-लर्न की सभी वस्तुओं में संशोधन (जो जोखिम भरा है)
प्रयास), हम पहले इस ट्रांसफार्मर को लागू कर सकते हैं (मुझे विश्वास है कि
@amueller के दिमाग में यह है)।

फीचर दिशा के बजाय नमूना दिशा यहां?

हां।

ठीक है, लेकिन यह सब एक ट्रांसफॉर्मर के स्तर पर है जो पंडों को अंदर ले जाता है, और डेटा मैट्रिक्स देता है, है ना?

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

OK, but that's all at the level of one transformer that takes Pandas in,
and gives a data matrix out, isn't it?

हां, यही वह है जिसे मैं शुरू करने के बारे में सोच रहा था। मुझे इससे ज्यादा खुशी होगी
एक आवरण जो एक्स और वाई को डेटाफ्रेम के रूप में पेश करता है। मुझे कोई स्पष्ट कारण नहीं दिख रहा है
sklearn के इंटर्नल के साथ पेंच करने के लिए।

फिर हम एक ही पृष्ठ पर हैं। मुझे लगता है कि @amueller के पास इसके बारे में विचार हैं
यह, और हम कुछ चर्चा, और शायद कोड जल्द ही देख सकते हैं।

दूसरी चीज जो अच्छी होगी, वह होगी परिवर्तन में कॉलम नामों को संरक्षित करना/फीचर चयन करते समय उनका चयन करना। मुझे वह मुद्दा नहीं मिला जहां हमने अभी इस पर चर्चा की है।

5172

एक नोट: मैंने सोचा था कि क्या कोई उपयोगकर्ता को यह कार्यक्षमता प्रदान करने के लिए केवल सबसे बाहरी अनुमानक को एक समूह में लपेटना चाहेगा। मुझे लगता है कि इसका उत्तर है: नहीं, एक पाइपलाइन के भीतर डेटाफ्रेम-जागरूक ट्रांसफार्मर की अनुमति देने के लिए परमाणु ट्रांसफार्मर को भी लपेटना चाहता है (क्यों नहीं?) इसे मिक्सिन के रूप में लागू किए बिना, मुझे लगता है कि आपको अनावश्यक पैरामीटर प्रीफ़िक्सिंग या अन्य समस्याएँ क्लोनिंग (जैसे # 5080 में) के साथ समस्याएँ मिलने वाली हैं।

:+1:

मैं जिस समाधान का उपयोग कर रहा हूं उसे टॉस करना चाहता था:

def check_output(X, ensure_index=None, ensure_columns=None):
    """
    Joins X with ensure_index's index or ensure_columns's columns when avaialble
    """
    if ensure_index is not None:
        if ensure_columns is not None:
            if type(ensure_index) is pd.DataFrame and type(ensure_columns) is pd.DataFrame:
                X = pd.DataFrame(X, index=ensure_index.index, columns=ensure_columns.columns)
        else:
            if type(ensure_index) is pd.DataFrame:
                X = pd.DataFrame(X, index=ensure_index.index)
    return X

मैं फिर स्केलेर के अनुमानकों के चारों ओर रैपर बनाता हूं जो इस फ़ंक्शन को ट्रांसफॉर्म के आउटपुट पर कॉल करते हैं जैसे,

from sklearn.preprocessing import StandardScaler as _StandardScaler 
class StandardScaler(_StandardScaler):
    def transform(self, X):
        Xt = super(StandardScaler, self).transform(X)
        return check_output(Xt, ensure_index=X, ensure_columns=X)

क्लासिफायर जिन्हें इनपुट डेटाफ्रेम एक्स के सूचकांक के उपयोग की आवश्यकता होती है, वे केवल इसके सूचकांक का उपयोग कर सकते हैं (जैसा कि बताया गया था कि समय के लिए उपयोगी)।

इस दृष्टिकोण में मौजूदा स्केलेर डिज़ाइन के साथ पूरी तरह से संगत होने का लाभ है, जबकि गणना की गति को संरक्षित करते हुए (गणित संचालन और डेटाफ़्रेम पर अनुक्रमण numpy arrays की तुलना में 10x तक धीमा है, http://penandpants.com/2014/09/05 /प्रदर्शन-की-पांडा-श्रृंखला-बनाम-सुन्न-सरणी/)। दुर्भाग्य से, प्रत्येक अनुमानक को जोड़ने के लिए यह बहुत कठिन काम है जो इसका उपयोग कर सकता है।

शायद इस जादू के साथ पाइपलाइन संस्करण बनाना जरूरी है ...

15 जनवरी 2016 को 02:30 बजे, डीन वायट नोटिफिकेशन @github.com ने लिखा:

मैं जिस समाधान का उपयोग कर रहा हूं उसे टॉस करना चाहता था:

def check_output (X, सुनिश्चित_इंडेक्स = कोई नहीं, सुनिश्चित_स्तंभ = कोई नहीं):
"""
उपलब्ध होने पर सुनिश्चित_इंडेक्स के सूचकांक या सुनिश्चित_स्तंभों के कॉलम के साथ एक्स से जुड़ता है
"""
अगर सुनिश्चित_इंडेक्स कोई नहीं है:
अगर सुनिश्चित_कॉलम कोई नहीं है:
अगर टाइप (सुनिश्चित_इंडेक्स) पीडी है। डेटाफ्रेम और टाइप (ensure_columns) पीडी है। डेटाफ्रेम:
X = pd.DataFrame(X, index=ensure_index.index, column=ensure_columns.columns)
अन्यथा:
अगर टाइप (सुनिश्चित_इंडेक्स) पीडी है। डेटाफ्रेम:
X = pd.DataFrame(X, index=ensure_index.index)
वापसी एक्स

मैं फिर स्केलेर के अनुमानकों के चारों ओर रैपर बनाता हूं जो इस फ़ंक्शन को कहते हैं
परिवर्तन के उत्पादन पर जैसे,

sklearn.preprocessing से _StandardScaler . के रूप में StandardScaler आयात करें
कक्षा MinMaxScaler (_MinMaxScaler):
डीईएफ़ ट्रांसफ़ॉर्म (स्वयं, एक्स):
एक्सटी = सुपर (मिनमैक्सस्केलर, सेल्फ)। ट्रांसफॉर्म (एक्स)
वापसी चेक_आउटपुट (एक्सटी, सुनिश्चित_इंडेक्स = एक्स, सुनिश्चित_ कॉलम = एक्स)

क्लासिफायर जिन्हें इनपुट डेटाफ्रेम एक्स के सूचकांक के उपयोग की आवश्यकता होती है, वे बस कर सकते हैं
इसके सूचकांक का उपयोग करें (जैसा कि बताया गया था कि समय-सारिणी के लिए उपयोगी)।

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/scikit-learn/scikit-learn/issues/5523#issuecomment -171674105
.

या बस कुछ ऐसा जो पाइपलाइन/अनुमानक को लपेटता है, नहीं?

मैं वास्तव में समझ नहीं पा रहा हूं कि आप "चेक_ *" जैसे फ़ंक्शन को क्यों कॉल करेंगे, जब यह केवल जांच करने से कहीं अधिक कर रहा है ...

14 जनवरी 2016 को सुबह 10:45:44 बजे सीएसटी, जोएल नोथमैन नोटिफिकेशन @github.com ने लिखा:

शायद इस जादू के साथ पाइपलाइन संस्करण बनाना जरूरी है ...

15 जनवरी 2016 को 02:30 बजे, डीन वायट नोटिफिकेशन @github.com
लिखा था:

मैं जिस समाधान का उपयोग कर रहा हूं उसे टॉस करना चाहता था:

def check_output (X, सुनिश्चित_इंडेक्स = कोई नहीं, सुनिश्चित_स्तंभ = कोई नहीं):
"""
सुनिश्चित_इंडेक्स के सूचकांक या सुनिश्चित_स्तंभों के कॉलम के साथ एक्स में शामिल हों
जब उपलब्ध हो
"""
अगर सुनिश्चित_इंडेक्स कोई नहीं है:
अगर सुनिश्चित_कॉलम कोई नहीं है:
अगर टाइप (सुनिश्चित_इंडेक्स) पीडी है। डेटाफ्रेम और
type(ensure_columns) pd.DataFrame है:
एक्स = पीडी। डेटाफ्रेम (एक्स, इंडेक्स = सुनिश्चित_इंडेक्स। इंडेक्स,
कॉलम = सुनिश्चित_कॉलम.कॉलम)
अन्यथा:
अगर टाइप (सुनिश्चित_इंडेक्स) पीडी है। डेटाफ्रेम:
X = pd.DataFrame(X, index=ensure_index.index)
वापसी एक्स

मैं फिर स्केलेर के अनुमानकों के चारों ओर रैपर बनाता हूं जो इसे कहते हैं
समारोह
परिवर्तन के उत्पादन पर जैसे,

sklearn.preprocessing से _StandardScaler . के रूप में StandardScaler आयात करें
कक्षा MinMaxScaler (_MinMaxScaler):
डीईएफ़ ट्रांसफ़ॉर्म (स्वयं, एक्स):
एक्सटी = सुपर (मिनमैक्सस्केलर, सेल्फ)। ट्रांसफॉर्म (एक्स)
वापसी चेक_आउटपुट (एक्सटी, सुनिश्चित_इंडेक्स = एक्स, सुनिश्चित_ कॉलम = एक्स)

क्लासिफायर जिन्हें इनपुट डेटाफ्रेम एक्स के सूचकांक के उपयोग की आवश्यकता होती है
अभी - अभी
इसके सूचकांक का उपयोग करें (जैसा कि बताया गया था कि समय-सारिणी के लिए उपयोगी)।

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें

https://github.com/scikit-learn/scikit-learn/issues/5523#issuecomment -171674105
.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/scikit-learn/scikit-learn/issues/5523#issuecomment -171697542

K-9 मेल के साथ मेरे Android डिवाइस से भेजा गया। मेरे संक्षिप्तता को माफ़ करो।

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

क्या यह हमेशा ऐसा होता है कि सभी सरणियों के n_rows परिवर्तन के दौरान संरक्षित होते हैं? यदि ऐसा है, तो इनपुट की अनुक्रमणिका (यदि यह मौजूद है) को विरासत में लेना सुरक्षित लगता है, लेकिन मुझे यकीन नहीं है कि डिफ़ॉल्ट कॉलम नामों के साथ डेटाफ्रेम प्राप्त करना (उदाहरण के लिए, [0, 1, 2, 3, ...]) है एंड-यूज़र परिप्रेक्ष्य से वर्तमान व्यवहार से बेहतर है, लेकिन यदि एक स्पष्ट रैपर/मेटा-अनुमानक का उपयोग किया जाता है, तो कम से कम उपयोगकर्ता को पता चल जाएगा कि क्या उम्मीद करनी है।

साथ ही, सहमत हूं कि check_* एक खराब नाम है - मैं अपने फ़ंक्शन में कुछ अधिक सत्यापन कर रहा था, और यहां पोस्ट करने के लिए डेटाफ़्रेम तर्क को हटा दिया।

मुझे लगता है कि पाइपलाइन शुरू करने का स्थान होगा, हालांकि हमें उन सभी अनुमानकों में कुछ जोड़ना होगा जो कॉलम नामों को उचित रूप से मैप करते हैं।

ट्रांसफॉर्मर को उचित नाम वाले कॉलम @naught101 . का उत्पादन करना चाहिए

हालांकि कॉलम नामों को संरक्षित करने के लिए इनपुट सत्यापन के साथ बड़ी सर्जरी की आवश्यकता होगी:-/ @amueller

न केवल इनपुट सत्यापन: प्रत्येक परिवर्तन को यह वर्णन करना होगा कि वह इनपुट कॉलम में क्या करता है। @GaelVaroquaux

क्या किसी ने यांत्रिकी के बारे में सोचा है कि ट्रांसफॉर्मर से ट्रांसफॉर्मर तक नामों को कैसे पास किया जाए, और शायद उत्पत्ति को कैसे ट्रैक किया जाए? कोई इसे कहां स्टोर करेगा?

मेरे एक दोस्त, @cbrummitt को भी इसी तरह की समस्या है, जहां उसके डिजाइन मैट्रिक्स का प्रत्येक कॉलम एक कार्यात्मक रूप है (उदाहरण के लिए x^2, x^3, x_1^3x_2^2, सिम्पी एक्सप्रेशन के रूप में दर्शाया गया है), और उसके पास ट्रांसफॉर्मर हैं जो बहुपद सुविधाओं के समान कार्य करते हैं, जो कार्यात्मक रूप ले सकते हैं और उसके आधार पर अधिक उत्पन्न कर सकते हैं। लेकिन वह पुराने अभिव्यक्तियों को लेने और नए उत्पन्न करने के लिए sympy का उपयोग कर रहा है, और अभिव्यक्तियों को स्ट्रिंग लेबल के रूप में संग्रहीत करता है, और जब आप फ़ंक्शन ट्रांसफॉर्मेशन को परत करते हैं तो जटिल हो जाता है। वह यह सब पाइपलाइन के बाहर कर सकता था, लेकिन फिर उसे ग्रिडसर्च आदि का लाभ नहीं मिलता।

मुझे लगता है कि हमारे प्रश्न का अधिक सामान्य संस्करण यह है कि आपके पास कुछ ऐसी जानकारी कैसे है जो ट्रांसफॉर्मर से ट्रांसफॉर्मर तक पहुंच जाएगी जो कि डेटा ही नहीं है? मैं पाइपलाइन-वैश्विक स्थिति के बिना या प्रत्येक ट्रांसफॉर्मर/अनुमानक को पिछले वाले के बारे में जाने, या प्रत्येक चरण में कई चीजें, या कुछ वापस किए बिना एक शानदार तरीके से नहीं आ सकता।

इसके बाद हम इस पर नज़र रखने के लिए पाइपलाइन को संशोधित करने के विचार के साथ आए, आपको _fit() और _transform() और शायद कुछ अन्य चीजों को बदलना होगा। ऐसा लगता है कि हमारा सबसे अच्छा विकल्प है।

यह पागल लगता है लेकिन ऐसा क्या लगता है कि हम वास्तव में चाहते हैं कि हमारा डेटा मैट्रिक्स सिम्पी एक्सप्रेशन हो, और प्रत्येक परिवर्तन नए भाव उत्पन्न करता है? यह सकल है, check_array() इसे होने से रोकता है, और यह पाइपलाइन के अन्य चरणों को नाराज़ कर देगा।

वर्तमान विचार के लिए #6425 देखें।

आप सभी चाहते हैं कि प्रत्येक ट्रांसफॉर्मर के लिए एक मैपिंग हो (एक पाइपलाइन सहित)
ट्रांसफॉर्मर), इनपुट फीचर नाम से आउटपुट फीचर नाम (या कुछ .)
परिवर्तनों का संरचित प्रतिनिधित्व, जिस पर मुझे संदेह है, अधिक है
इंजीनियरिंग की तुलना में हम प्राप्त करने जा रहे हैं)। यही #6425 प्रदान करता है।

8 अक्टूबर 2016 को 03:42 बजे, एंड्रियास म्यूएलर नोटिफिकेशन @github.com
लिखा था:

देखें #6425 https://github.com/scikit-learn/scikit-learn/issues/6425 के लिए
वर्तमान विचार।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/scikit-learn/scikit-learn/issues/5523#issuecomment -252301608,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAEz65fBsMwqmkDq3DEjMSUC-W-nfn9zks5qxnZxgaJpZM4GTHGc
.

हम इस पर गौर करेंगे, धन्यवाद!

क्या कोई इस मुद्दे पर विश्व की स्थिति पर एक सामान्य अपडेट प्रदान कर सकता है?

क्या पांडा DataFrame समर्थन हमेशा एक वाईएमएमवी चीज होगी?
केवल एक ndarray बजाय पांडा DataFrame साथ उपयोग के लिए सुरक्षित/क्या नहीं माना जाता है, इस पर मार्गदर्शन सहायक होगा। शायद निम्नलिखित की तर्ज पर कुछ (मेड अप उदाहरण तालिका):

मॉड्यूल/श्रेणी|पंडों का सुरक्षित रूप से उपभोग कर सकते हैं DataFrame
--|--
sklearn.pipeline|सुरक्षित
sklearn.feature_selection|सुरक्षित
रजिस्टरों|वाईएमएमवी
sklearn.feature_extraction|सुरक्षित नहीं, लागू करने की कोई योजना नहीं
आदि|...

अभी, मुझे "बस इसे आज़माएं और देखें कि क्या यह अपवाद फेंकता है" के अलावा किसी अन्य दृष्टिकोण के बारे में निश्चित नहीं है।

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

मेरी प्रारंभिक विचार प्रक्रिया एक प्रतिस्थापन पाइपलाइन ऑब्जेक्ट बनाने के लिए थी जो एक पांडा का उपभोग कर सकती है DataFrame जो मानक स्किकिट-लर्न घटकों के लिए ऑटो-जेनरेटेड रैपर इनपुट/आउटपुट DataFrame ऑब्जेक्ट्स को numpy ndarray में परिवर्तित करने के लिए DataFrame आदिम का उपयोग कर सकूं, लेकिन यह थोड़ा भारी हाथ लगता है। विशेष रूप से तब, जब हम उनके लिए "आधिकारिक" समर्थन प्राप्त करने की कगार पर हों।

मैं कुछ अलग पीआर का पालन कर रहा हूं, लेकिन यह समझना मुश्किल है कि किसके लिए छोड़ दिया गया है और/या जो वर्तमान सोच को दर्शाता है:
उदाहरण:

6425 (इस धागे में ऊपर अक्टूबर 2016 को संदर्भित)

9012 (स्पष्ट रूप से स्केलेर-पांडा के साथ ओवरलैप होता है, लेकिन प्रयोगात्मक के रूप में एनोटेट किया जाता है?)

3886 (#9012 से आगे?)

यह "सुरक्षित रूप से पांडा डेटाफ़्रेम का उपभोग कर सकता है" से आपका क्या मतलब है, इस पर गंभीर रूप से टिका है। यदि आपका मतलब केवल फ़्लोट नंबर वाले डेटाफ़्रेम से है, तो हम गारंटी देते हैं कि सब कुछ काम करेगा। अगर कहीं एक भी तार हो तो कुछ भी काम नहीं करेगा।

मुझे लगता है कि किसी भी गैर-तुच्छ (या शायद यहां तक ​​​​कि मामूली) ऑपरेशन के लिए डेटाफ्रेम लौटने वाला कोई भी विज्ञान-सीखने वाला अनुमानक ऐसा कुछ है जो कभी नहीं हो सकता है (हालांकि यह इसे पसंद करेगा)।

9012 होगा और स्थिर हो जाएगा, पीआर एक पहला पुनरावृत्ति है (या 10 वां पुनरावृत्ति, यदि आप गैर-विलय वाले लोगों की गणना करते हैं;)

6425 होने की संभावना है, हालांकि यह पूरी तरह से पांडा से संबंधित नहीं है।

3886 वास्तव में #9012 . से अधिक है

कार्यक्षमता #6425 वर्तमान में लागू की गई है (कुछ ट्रांसफॉर्मर के लिए और
दूसरों के लिए एक्स्टेंसिबल) सिंगलडिस्पैच के माध्यम से
https://codecov.io/gh/TeamHG-Memex/eli5 इसके लायक क्या है।

21 जून 2017 को 13:25 बजे, एंड्रियास म्यूएलर नोटिफिकेशन @github.com ने लिखा:

9012 https://github.com/scikit-learn/scikit-learn/pull/9012 होगा

होता है और स्थिर हो जाएगा, पीआर एक पहला पुनरावृत्ति है।

6425 https://github.com/scikit-learn/scikit-learn/issues/6425 है

होने की संभावना है, हालांकि यह पूरी तरह से पांडा से संबंधित नहीं है।

3886 https://github.com/scikit-learn/scikit-learn/pull/3886 वास्तव में है

#9012 . से आगे
https://github.com/scikit-learn/scikit-learn/pull/9012

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

ओह और जब मैं कहता हूं "यदि आपका मतलब केवल फ्लोट नंबर वाले डेटाफ्रेम से है, तो हम गारंटी देते हैं कि सब कुछ काम करेगा।" मेरा मतलब स्थान-आधारित कॉलम इंडेक्सिंग से है। प्रशिक्षण और परीक्षण सेट कॉलम स्थिति के अनुसार समान माने जाते हैं।

यह "सुरक्षित रूप से पांडा डेटाफ़्रेम का उपभोग कर सकता है" से आपका क्या मतलब है, इस पर गंभीर रूप से टिका है। यदि आपका मतलब केवल फ़्लोट नंबर वाले डेटाफ़्रेम से है, तो हम गारंटी देते हैं कि सब कुछ काम करेगा। अगर कहीं एक भी तार हो तो कुछ भी काम नहीं करेगा।

मुझे लगता है कि यह हमारे लिए काफी अच्छा है।

हम मिश्रित प्रकारों (स्ट्रिंग्स, फ्लोट्स, और इनट्स) को चयनकर्ताओं या मॉडलों जैसे स्किकिट-लर्न घटकों तक पहुंचने से पहले एन्कोडिंग/स्केलिंग के माध्यम से फ्लोट्स में बदलने के लिए कस्टम घटकों (मौजूदा टूलींग के आसपास पतले रैपर जो पाइपलाइन के अनुकूल नहीं हैं) की एक पाइपलाइन का उपयोग कर रहे हैं।

मेरे सभी ट्रांसफार्मर लौट DataFrame रों जब दिया DataFrame एस।
जब मैं एक 300-कॉलम DataFrame को Pipeline इनपुट करता हूं और 500-कॉलम ndarray हूं, तो मैं इससे प्रभावी रूप से बहुत कुछ नहीं सीख सकता, उदाहरण के लिए, feature_selection , क्योंकि मेरे पास अब कॉलम नाम नहीं हैं। अगर, कहें, mutual_info_classif मुझे बताता है कि केवल कॉलम 30 और 75 महत्वपूर्ण हैं, तो मैं यह नहीं समझ सकता कि उत्पादन के लिए मेरे मूल Pipeline को कैसे सरल बनाया जाए।
इस प्रकार मेरे उपयोग के मामले में मेरे डेटा को DataFrame में रखना महत्वपूर्ण है।
धन्यवाद।

@ सैम-एस मैं पूरी तरह सहमत हूं। "लघु" अवधि में, इसे https://github.com/scikit-learn/scikit-learn/pull/13307 और https://github.com/scikit-learn/enhancement_proposals/pull/18 द्वारा संबोधित किया जाएगा।

आपको एक पांडा डेटाफ़्रेम नहीं मिलेगा, लेकिन आपको एक बनाने के लिए कॉलम नाम मिलेगा।

क्या आप कृपया एक और ठोस उदाहरण दे सकते हैं, यद्यपि? क्योंकि अगर सभी ट्रांसफॉर्मर डेटाफ्रेम लौटाते हैं, तो चीजें काम करनी चाहिए (या उपरोक्त प्रस्तावों की तुलना में अधिक आसानी से काम करने के लिए बनाई जानी चाहिए)।

https://github.com/pandas-dev/pandas/issues/27211 . के माध्यम से थोड़ा अपडेट
जो मेरी उम्मीदों पर पानी फेर देता है। ऐसा लगता है कि हम जीरो-कॉपी राउंड-ट्रिप होने पर भरोसा नहीं कर सकते हैं, और इसलिए पांडा में लपेटने और खोलने के परिणामस्वरूप पर्याप्त लागत आएगी।

पांडा-देव/पांडा#27211 के माध्यम से थोड़ा अपडेट जो मेरी उम्मीदों पर पानी फेर देता है। ऐसा लगता है कि हम जीरो-कॉपी राउंड-ट्रिप होने पर भरोसा नहीं कर सकते हैं, और इसलिए पांडा में लपेटने और खोलने के परिणामस्वरूप पर्याप्त लागत आएगी।

हाँ, लेकिन मुझे लगता है कि एक बार जब हम फीचर और नमूना प्रोप (पंक्ति नाम और "सूचकांक" थोड़े नमूना प्रोप होते हैं) को कवर करते हैं, तो अधिकांश संबंधित उपयोगकेस जिन्हें थोड़े पांडा की आवश्यकता होती है, उन्हें कवर किया जाएगा, है ना?

@adrinjalali मुझे यकीन नहीं है कि "थोड़े से संबंधित उपयोगकेस के साथ थोड़े पांडा की जरूरत है" से आपका क्या मतलब है। मैंने इस मुद्दे को मुख्य रूप से स्किकिट-लर्न के भीतर सुविधाओं को लागू करने के लिए पंडों के समर्थन के रूप में नहीं देखा, बल्कि पंडों-आधारित वर्कफ़्लो में स्किकिट-लर्न को अधिक आसानी से एकीकृत करने के लिए देखा।

बस जिज्ञासा से बाहर, क्या कोई समय सीमा है जिसके भीतर पंडों की अनुकूलता में सुधार होने की उम्मीद है? मुझे पंडों में विशेष रूप से दिलचस्पी है -> पांडा StandardScaler लिए बाहर।

मेरे पास एक उपयोग का मामला है जहां मुझे Pipeline में प्रत्येक चरण के माध्यम से संरक्षित पांडा डेटाफ्रेम की आवश्यकता है। उदाहरण के लिए 1 के साथ एक पाइपलाइन) डेटा के आधार पर सुविधा चयन चरण फ़िल्टरिंग सुविधाएँ, 2) डेटा परिवर्तन चरण, 3) विशिष्ट सुविधा कॉलम नामों या मूल सूचकांकों के लिए फ़िल्टर करने के लिए एक और सुविधा चयन चरण, 4) मानकीकरण, 5) वर्गीकरण।

चरण 3) मेरा मानना ​​​​है कि वर्तमान में स्केलेर में संभव नहीं है, यहां तक ​​​​कि एक संख्यात्मक सरणी इनपुट के साथ भी, क्योंकि मूल फीचर इंडेक्स तब अर्थहीन होते हैं जब डेटा 3 हो जाता है) क्योंकि 1) में एक फीचर चयन चरण था। यदि पांडा डेटाफ्रेम को पाइपलाइन में संरक्षित किया जा रहा है तो यह काम करेगा क्योंकि मैं कॉलम नाम से 3 में फ़िल्टर कर सकता हूं)।

क्या मैं यह सोचने में गलत हूं कि वर्तमान में numpy array इनपुट के साथ भी ऐसा करने का कोई तरीका नहीं है?

आप सही कह रहे हैं कि यह समर्थित नहीं है, और इसका समर्थन करना मामूली नहीं होगा। आपके उपयोग के मामले से संबंधित, हम पाइपलाइन के साथ फीचर नामों को पारित करने पर काम कर रहे हैं (जैसा कि आप ऊपर लिंक किए गए पीआर और प्रस्तावों में देखते हैं)। एक बार यह हो जाने के बाद उम्मीद है कि आपके मामले में मदद मिलनी चाहिए। मुझे यकीन नहीं है कि यह मदद करता है, लेकिन आप https://github.com/scikit-learn-contrib/sklearn-pandas पर भी एक नज़र डाल सकते हैं

आप सही कह रहे हैं कि यह समर्थित नहीं है, और इसका समर्थन करना मामूली नहीं होगा। आपके उपयोग के मामले से संबंधित, हम पाइपलाइन के साथ फीचर नामों को पारित करने पर काम कर रहे हैं (जैसा कि आप ऊपर लिंक किए गए पीआर और प्रस्तावों में देखते हैं)। एक बार यह हो जाने के बाद उम्मीद है कि आपके मामले में मदद मिलनी चाहिए।

पुष्टि के लिए धन्यवाद, हाँ, फीचर नामों (या अन्य फीचर गुणों) को फिट करने के तरीकों को पास करने में सक्षम होना और प्रत्येक फीचर चयन चरण के दौरान उन्हें ठीक से कटा हुआ होना इस उपयोग के मामले के लिए ठीक होगा।

मुझे यकीन नहीं है कि यह मदद करता है, लेकिन आप https://github.com/scikit-learn-contrib/sklearn-pandas पर भी एक नज़र डाल सकते हैं

इससे पहले मैंने उनके दस्तावेज़ों को पढ़ा था और शायद मैं इसे नहीं देख रहा हूं, लेकिन उनकी अधिकांश (या सभी) विशेषताएं अब scikit-learn 0.21 में sklearn.compose.ColumnTransformer साथ अप्रचलित हैं? इसके अलावा ऐसा नहीं लगता है कि वे पांडा का समर्थन करते हैं, यह परिवर्तन के बाद सुन्न सरणियों जैसा दिखता है।

(मुझे आश्चर्य है कि फीचर चयन में पंडों का समर्थन करना टूट जाएगा
बहुत...)

संक्षेप में कोड की जाँच करने पर, सभी प्रकार की जाँचें होती हैं जो कई जगहों पर मनमाने ढंग से होती हैं, उदाहरण के लिए https://github.com/scikit-learn/scikit-learn/blob/939fa3cccefe708db7a81c5248db32a1d600bf8d/sklearn/utils/validation.py# एल619

साथ ही कई ऑपरेशन इंडेक्सिंग का उपयोग एक नुकीले अंदाज में करते हैं जिसे पांडा डेटाफ्रेम द्वारा स्वीकार नहीं किया जाएगा।

पांडा को अंदर/बाहर रखना दिन-प्रतिदिन डेटा विज्ञान आईएमओ के लिए जरूरी होगा, लेकिन विज्ञान-सीखना इस तरह से डिजाइन किया गया है जिससे इसे लागू करना मुश्किल हो जाएगा।

दिन-प्रतिदिन डेटा विज्ञान आईएमओ के लिए पांडा को अंदर/बाहर रखना जरूरी होगा, लेकिन
स्किकिट-लर्न को इस तरह से डिज़ाइन किया गया लगता है जिससे इसे बनाना मुश्किल हो जाएगा
क्रियान्वित किया।

पांडा डेटाफ्रेम पर अच्छे अंकों को लागू करना कठिन है। वे न्यायसंगत हैं
उसके लिए नहीं, विशेष रूप से बहुभिन्नरूपी संचालन के लिए (संख्यात्मक)
कॉलम भर में संचालन)।

मशीन लर्निंग ज्यादातर मल्टीवेरिएट न्यूमेरिक्स है।

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

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

उपयोगकर्ता आधार को बनाए रखने और नए उपयोगकर्ताओं को लाने के लिए इस प्रकार की मुख्य कार्यात्मकताएं बहुत महत्वपूर्ण हैं। अन्यथा मैं पुस्तकालयों को देखता हूं जैसे एमएलआर 3 अंततः स्केलेर से उपयोगकर्ताओं को परिपक्व और आकर्षित करता है क्योंकि मुझे पता है कि वे डेटा फ्रेम और मेटाडेटा का पूरी तरह से समर्थन करते हैं (या करेंगे)।

वह निर्णय उपयोगकर्ता पर छोड़ दिया जाना चाहिए?

खैर, उपयोगकर्ता एल्गोरिदम लागू नहीं कर रहा है।

अन्यथा मैं पुस्तकालयों को देखता हूं जैसे एमएलआर 3 अंततः परिपक्व हो रहा है और
उपयोगकर्ताओं को स्केलेर से दूर आकर्षित करना क्योंकि मुझे पता है कि वे ऐसा करते हैं (या करेंगे)
पूरी तरह से डेटा फ्रेम और मेटाडेटा का समर्थन करते हैं।

एमएलआर 3 आर में है, डेटाफ्रेम पांडा डेटाफ्रेम से काफी अलग हैं।
शायद इससे इसे लागू करना आसान हो जाता है।

मैं सहमत हूं कि फीचर नामों और विषम डेटा के लिए बेहतर समर्थन
प्रकार महत्वपूर्ण है। हम अच्छे तकनीकी समाधान खोजने पर काम कर रहे हैं
जिससे प्रदर्शन और अत्यधिक जटिल कोड का नुकसान नहीं होता है।

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

मुझे लगता है कि सुन्न सरणियों के साथ चिपके रहने का आपका दृष्टिकोण और कम से कम पासिंग फीचर नामों का समर्थन करना या इससे भी बेहतर मल्टीपल फीचर मेटाडेटा कई उपयोग के मामलों के लिए काम करेगा। प्रशिक्षण नमूना मेटाडेटा पास करने के लिए आप पहले से ही **fit_params में इसका समर्थन करते हैं और मुझे पता है कि डिज़ाइन को बेहतर बनाने का प्रयास किया जा रहा है। लेकिन मैंने https://github.com/scikit-learn/enhancement_proposals/pull/16 में उल्लेख किया है कि ऐसे उपयोग के मामले हैं जहां आपको transform विधियों में पास किए गए परीक्षण नमूना मेटाडेटा की भी आवश्यकता होगी और यह वर्तमान में समर्थित नहीं है .

एमएलआर 3 आर में है, डेटाफ्रेम पांडा डेटाफ्रेम से काफी अलग हैं।

जीवन विज्ञान अनुसंधान में कम्प्यूटेशनल वैज्ञानिक आमतौर पर अजगर और आर दोनों के साथ बहुत सहज होते हैं और दोनों का एक साथ उपयोग करते हैं (स्वयं शामिल)। मुझे पूरा यकीन है कि विज्ञान सीखने वाले उपयोगकर्ता आधार का एक महत्वपूर्ण प्रतिशत जीवन विज्ञान शोधकर्ता हैं।

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

पांडा डेटाफ्रेम पर अच्छे अंकों को लागू करना कठिन है। वे न्यायसंगत हैं
उसके लिए नहीं, विशेष रूप से बहुभिन्नरूपी संचालन के लिए (संख्यात्मक)
कॉलम भर में संचालन)।

हो सकता है कि मुझे कुछ याद आ रहा हो, लेकिन क्या डेटाफ़्रेम को खोलना संभव नहीं होगा ( df.values का उपयोग करके), गणनाएँ करें और फिर एक नए डेटाफ़्रेम पर वापस लपेटें?

यह मूल रूप से मैं चरणों के बीच मैन्युअल रूप से करता हूं, और केवल एक चीज जो Pipeline के उपयोग को रोकती है।

शायद मुझे कुछ याद आ रहा है, लेकिन क्या इसे खोलना संभव नहीं होगा
DataFrame (df.values ​​​​का उपयोग करके), गणना करें और फिर एक नए में वापस लपेटें
डेटा ढांचा ?

सामान्य तौर पर नहीं: यह काम नहीं कर सकता (विषम स्तंभ), और यह होगा
बहुत सारी मेमोरी कॉपी की ओर ले जाता है।

सामान्य तौर पर नहीं: यह काम नहीं कर सकता (विषम स्तंभ)

मुझे लगता है कि कॉलम ट्रांसफॉर्मर और इस तरह से इसे अलग-अलग संभाल सकते हैं।

यह बहुत सारी मेमोरी कॉपी की ओर ले जाएगा।

मैं समझता हूं कि डिजाइन और कार्यान्वयन के लिए कठिन विकल्प हैं, और यह एक ठोस तर्क है।

हालाँकि, मुझे समझ में नहीं आता कि आप यह तर्क क्यों देंगे कि स्केलेर द्वारा कॉलम मेटा डेटा का समर्थन करने के तरीके में सुधार करना एक अच्छा विचार नहीं है।

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

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

यह उपयोगकर्ता पर निर्भर करेगा कि वह प्रदर्शनों को अनुकूलित करते समय इस वर्कफ़्लो का उपयोग न करने का निर्णय करे।

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

इसलिए हमें यहां थोड़ी सावधानी से कदम बढ़ाने की जरूरत है। लेकिन हमें हल करते रहने की जरूरत है
यह एक उच्च प्राथमिकता के रूप में।

मुझे लगता है कि सबसे अच्छा समाधान नमूना और फीचर गुणों के लिए पांडा डेटाफ्रेम को अंदर और बाहर का समर्थन करना होगा और उन्हें ट्रेन और परीक्षण फिट/ट्रांसफॉर्म में ठीक से पास करना और टुकड़ा करना होगा। यह डेटा मैट्रिक्स एक्स की गति को numpy arrays के रूप में रखते हुए अधिकांश उपयोग मामलों को हल करेगा।

इस तर्क से गायब एक महत्वपूर्ण बिंदु यह है कि पांडा डेटा के स्तंभ प्रतिनिधित्व की ओर बढ़ रहे हैं, इस तरह से np.array(pd.DataFrame(numpy_data)) में दो _गारंटी_ मेमोरी प्रतियां होंगी। इसलिए यह इतना आसान नहीं है जितना कि केवल डेटाफ़्रेम रखना और values जब भी हमें गति की आवश्यकता होती है।

इस तर्क से गायब एक महत्वपूर्ण बिंदु यह है कि पांडा डेटा के स्तंभ प्रतिनिधित्व की ओर बढ़ रहे हैं, इस तरह से np.array(pd.DataFrame(numpy_data)) में दो _गारंटी_ मेमोरी प्रतियां होंगी। इसलिए यह इतना आसान नहीं है जितना कि केवल डेटाफ़्रेम रखना और values जब भी हमें गति की आवश्यकता होती है।

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

हां, वे परिवर्तन कई उपयोग के मामलों में मदद करते हैं, और हम उन पर काम कर रहे हैं। लेकिन यह मुद्दा उससे परे है: https://github.com/scikit-learn/scikit-learn/issues/5523#issuecomment -508807755

@hermidalc क्या आप सुझाव दे रहे हैं कि हम X को एक सुस्पष्ट सरणी होने दें, और अन्य डेटाफ़्रेम ऑब्जेक्ट में मेटा डेटा असाइन करें?

@hermidalc क्या आप सुझाव दे रहे हैं कि हम X को एक सुस्पष्ट सरणी होने दें, और अन्य डेटाफ़्रेम ऑब्जेक्ट में मेटा डेटा असाइन करें?

हाँ, पांडा डेटाफ़्रेम के रूप में नमूना गुणों और फ़ीचर गुणों के लिए पूर्ण समर्थन। अन्य पीआर और मुद्दों में नमूना गुणों और फीचर नामों पर चर्चा पहले से ही हो रही है, उदाहरण के लिए यहां #9566 और #14315

मैंने इस मुद्दे पर पढ़ा है और ऐसा लगता है कि यहां दो प्रमुख अवरोधक हैं:

1. https://github.com/pandas-dev/pandas/issues/27211
2. वह पांडा एनडी सरणियों को संभालता नहीं है।

क्या आपने इसके बजाय xarrays के लिए समर्थन जोड़ने पर विचार किया है? उनके पास पांडा की वह सीमाएँ नहीं हैं।

X = np.arange(10).reshape(5, 2)
assert np.asarray(xr.DataArray(X)) is X
assert np.asarray(xr.Dataset({"data": (("samples", "features"), X)}).data).base is X.base

sklearn-xarray नामक एक पैकेज है: https://phausamann.github.io/sklearn-xarray/content/wrappers.html जो इनपुट और आउटपुट के रूप में xarrays को संभालने के लिए scikit अनुमानकों को लपेटता है लेकिन ऐसा लगता है कि यह बिना रखरखाव के चला गया है वर्षों। हालांकि, मुझे आश्चर्य है कि रैपर यहां जाने का रास्ता है या नहीं।

xarray पर सक्रिय रूप से विचार किया जा रहा है। इसे प्रोटोटाइप किया जा रहा है और यहां काम किया जा रहा है: https://github.com/scikit-learn/scikit-learn/pull/16772 पीआर में एपीआई कैसा दिखेगा, इस पर एक उपयोग नोटबुक है।

(0.23 रिलीज के साथ समाप्त होने के बाद मैं इस पर वापस आऊंगा)

मुझे भी इस फीचर में बहुत दिलचस्पी है।
यह अनंत समस्याओं का समाधान करेगा। वर्तमान में यह वह समाधान है जिसका मैं उपयोग कर रहा हूं।
मैंने sklearn.preprocessing मॉड्यूल के चारों ओर एक रैपर लिखा, जिसे मैंने sklearn_wrapper

इसलिए sklearn.preprocessing से आयात करने के बजाय मैं sklearn_wrapper से आयात करता हूं।
उदाहरण के लिए:

# this
from sklearn.preprocessing import StandardScaler 
# becomes 
from sklearn_wrapper import StandardScaler

इस मॉड्यूल के कार्यान्वयन के नीचे। इसे आज़माएं और मुझे बताएं कि आप लोग क्या सोचते हैं

from functools import wraps
from itertools import chain

import pandas as pd
from sklearn import preprocessing, compose, feature_selection, decomposition
from sklearn.compose._column_transformer import _get_transformer_list

modules = (preprocessing, feature_selection, decomposition)


def base_wrapper(Parent):
    class Wrapper(Parent):

        def transform(self, X, **kwargs):
            result = super().transform(X, **kwargs)
            check = self.check_out(X, result)
            return check if check is not None else result

        def fit_transform(self, X, y=None, **kwargs):
            result = super().fit_transform(X, y, **kwargs)
            check = self.check_out(X, result)
            return check if check is not None else result

        def check_out(self, X, result):
            if isinstance(X, pd.DataFrame):
                result = pd.DataFrame(result, index=X.index, columns=X.columns)
                result = result.astype(X.dtypes.to_dict())
            return result

        def __repr__(self):
            name = Parent.__name__
            tmp = super().__repr__().split('(')[1]
            return f'{name}({tmp}'

    Wrapper.__name__ = Parent.__name__
    Wrapper.__qualname__ = Parent.__name__

    return Wrapper


def base_pca_wrapper(Parent):
    Parent = base_wrapper(Parent)

    class Wrapper(Parent):
        @wraps(Parent)
        def __init__(self, *args, **kwargs):
            self._prefix_ = kwargs.pop('prefix', 'PCA')
            super().__init__(*args, **kwargs)

        def check_out(self, X, result):
            if isinstance(X, pd.DataFrame):
                columns = [f'{self._prefix_}_{i}' for i in range(1, (self.n_components or X.shape[1]) + 1)]
                result = pd.DataFrame(result, index=X.index, columns=columns)
            return result

    return Wrapper


class ColumnTransformer(base_wrapper(compose.ColumnTransformer)):

    def check_out(self, X, result):
        if isinstance(X, pd.DataFrame):
            return pd.DataFrame(result, index=X.index, columns=self._columns[0]) if self._remainder[1] == 'drop' \
                else pd.DataFrame(result, index=X.index, columns=X.columns). \
                astype(self.dtypes.iloc[self._remainder[-1]].to_dict())


class SelectKBest(base_wrapper(feature_selection.SelectKBest)):

    def check_out(self, X, result):
        if isinstance(X, pd.DataFrame):
            return pd.DataFrame(result, index=X.index, columns=X.columns[self.get_support()]). \
                astype(X.dtypes[self.get_support()].to_dict())


def make_column_transformer(*transformers, **kwargs):
    n_jobs = kwargs.pop('n_jobs', None)
    remainder = kwargs.pop('remainder', 'drop')
    sparse_threshold = kwargs.pop('sparse_threshold', 0.3)
    verbose = kwargs.pop('verbose', False)
    if kwargs:
        raise TypeError('Unknown keyword arguments: "{}"'
                        .format(list(kwargs.keys())[0]))
    transformer_list = _get_transformer_list(transformers)
    return ColumnTransformer(transformer_list, n_jobs=n_jobs,
                             remainder=remainder,
                             sparse_threshold=sparse_threshold,
                             verbose=verbose)


def __getattr__(name):
    if name not in __all__:
        return

    for module in modules:
        Parent = getattr(module, name, None)
        if Parent is not None:
            break

    if Parent is None:
        return

    if module is decomposition:
        Wrapper = base_pca_wrapper(Parent)
    else:
        Wrapper = base_wrapper(Parent)

    return Wrapper


__all__ = [*[c for c in preprocessing.__all__ if c[0].istitle()],
           *[c for c in decomposition.__all__ if c[0].istitle()],
           'SelectKBest']


def __dir__():
    tmp = dir()
    tmp.extend(__all__)
    return tmp

https://github.com/koaning/scikit-lego/issues/304 ने sklearn.pipeline.FeatureUnion पर हॉट-फिक्सिंग द्वारा एक और समाधान प्रदान किया