Numpy: वस्तु सरणियों का "नियंत्रित" निर्माण

को निर्मित 4 दिस॰ 2019 · 45टिप्पणियाँ · स्रोत: numpy/numpy

ऑब्जेक्ट सरणियों का स्वतः-निर्माण हाल ही में numpy में बहिष्कृत किया गया था। मैं परिवर्तन से सहमत हूं, लेकिन कुछ प्रकार के सामान्य कोड लिखना थोड़ा कठिन लगता है जो यह निर्धारित करता है कि उपयोगकर्ता द्वारा प्रदान किया गया तर्क गैर-ऑब्जेक्ट सरणी में परिवर्तनीय है या नहीं।

पुनरुत्पादन कोड उदाहरण:

Matplotlib में निम्नलिखित स्निपेट शामिल हैं:

    # <named ("string") colors are handled earlier>
    # tuple color.
    c = np.array(c)
    if not np.can_cast(c.dtype, float, "same_kind") or c.ndim != 1:
        # Test the dtype explicitly as `map(float, ...)`, `np.array(...,
        # float)` and `np.array(...).astype(float)` all convert "0.5" to 0.5.
        # Test dimensionality to reject single floats.
        raise ValueError(f"Invalid RGBA argument: {orig_c!r}")

लेकिन कभी-कभी फ़ंक्शन को विभिन्न स्वरूपों में रंगों की एक सरणी के साथ बुलाया जाता है (उदाहरण के लिए ["red", (0.5, 0.5, 0.5), "blue"] ) - हम ValueError पकड़ते हैं और प्रत्येक आइटम को एक बार में परिवर्तित करते हैं।

अब np.array(c) पर कॉल एक DeprecationWarning उत्सर्जित करेगी। हम इसके आसपास कैसे काम कर सकते हैं? यहां तक कि np.min_scalar_type(c) जैसा कुछ भी एक चेतावनी उत्सर्जित करता है (जो मुझे लगता है कि इसे नहीं करना चाहिए?), इसलिए यह मेरे लिए स्पष्ट नहीं है कि "अगर हम इस चीज़ को एक सरणी में परिवर्तित करते हैं, तो dtype क्या होगा?"

Numpy/पायथन संस्करण जानकारी:

1.19.0.dev0+bd1adc3 3.8.0 (डिफ़ॉल्ट, 6 नवंबर 2019, 21:49:08)
[जीसीसी 7.3.0]

57 - Close?

स्रोत

anntzer

सबसे उपयोगी टिप्पणी

क्या कोई operator.mod उदाहरण की ओर इशारा कर सकता है?

जहां तक == ऑपरेटर का सवाल है, जो मैंने देखा वह np.array(vals, dtype=object) == vals जैसा कुछ कर रहा था, जहां vals=[1, [2, 3]] (कोड को पैराफ्रेश करना), इसलिए समाधान सक्रिय रूप से दाईं ओर सरणी बनाना है पक्ष।

कई scipy विफलताएं np.array([0.25, np.array([0.3])]) के रूप में प्रतीत होती हैं, जहां स्केलर और ndarray को shape==(1,) साथ मिलाने से आयाम की खोज बंद हो जाएगी और एक ऑब्जेक्ट ऐरे का निर्माण होगा। xref gh-15075

mattip 9 दिस॰ 2019

👍2

सभी 45 टिप्पणियाँ

एक विकल्प होगा
`` `पायथन
प्रयत्न:
# खेल से आगे बढ़ें और एक त्रुटि के लिए पदावनति को बढ़ावा दें जो इसे बदल देगी
चेतावनियों के साथ। कैच_वार्निंग्स ():
चेतावनियाँ। फ़िल्टर चेतावनी ('उठाएँ', पदावनति चेतावनी, संदेश = "...")
c_arr = np.asarray(c)
सिवाय (बहिष्करण चेतावनी, ValueError):
# जो कुछ भी आप वर्तमान में ValueError के लिए करते हैं

eric-wieser 4 दिस॰ 2019

मुझे यह लगता है, और gh-15045 में उल्लिखित असफल परीक्षण ऐसे उदाहरण हैं जहां DeprecationWarning को सीधे उत्सर्जित करने के बजाय कुछ वर्षों के लिए ValueError उत्सर्जित करने से आवश्यकता से अधिक कोड मंथन होता है।

mattip 4 दिस॰ 2019

ध्यान दें कि warnings.catch_warnings थ्रेडसेफ नहीं है। यह वर्कअराउंड को लाइन के नीचे फॉलोअप मुद्दों के लिए थोड़ा सा प्रवण बनाता है।

seberg 4 दिस॰ 2019

👀1

मुझे लगता है कि कोड-मंथन बहिष्करण अवधि के लायक है।

Matplotlib इस तरह के बदलाव को जल्दी पकड़ने के लिए चेतावनियों-अस-विफलताओं के साथ अपना परीक्षण सूट चलाता है, इसलिए ऐसा लगता है कि सिस्टम मेरे लिए काम कर रहा है :)।

tacaswell 4 दिस॰ 2019

लेकिन AFAICT इसके लिए एक उचित रूप से आसान फिक्स भी नहीं है (जैसा कि ऊपर बताया गया है कि प्रस्तावित फिक्स थ्रेडसेफ नहीं है): /

anntzer 4 दिस॰ 2019

👍1

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

समस्या यह है कि आज पुस्तकालय लेखक के पास यह पूछने का कोई तरीका नहीं है कि "क्या यह वास्तव में चेतावनी छोड़ेगा" ... चेतावनी को छोड़कर, और इसे दबाने से थ्रेडसेफ नहीं है।

थ्रेड-सुरक्षा चेतावनी के संबंध में: https://bugs.python.org/issue37604

eric-wieser 4 दिस॰ 2019

AFAIK, बहिष्करण रिलीज शाखा में है। क्या हम इसे वापस करना चाहते हैं? यदि नहीं, तो सुधारों को बैकपोर्ट की आवश्यकता होगी। मैं अभी भी स्पष्ट नहीं हूं कि रिलीज शाखा पहियों में चेतावनियां क्यों नहीं उठाई गईं और आखिरी दो बिल्ड तक रात के निर्माण में दिखाई नहीं दीं। मैंने शाखा के बाद कुछ भी नहीं बदला और तब से मास्टर शाखा में, संभवतः, # 15040 को छोड़कर कमिट्स में कुछ भी संदिग्ध नहीं लग रहा है।

charris 4 दिस॰ 2019

आईएमएचओ (और ऊपर

anntzer 4 दिस॰ 2019

या संभवतः मल्टीबिल्ड व्यवहार शाखाएं मास्टर से अलग हैं।

charris 4 दिस॰ 2019

FWIW मैं हमेशा इस परिवर्तन पर कम से कम -1 था, विशेष रूप से रैग्ड डेटा संरचनाओं के एक उत्सुक उपयोगकर्ता के रूप में, लेकिन वैसे भी अब मुझे यह पता लगाने की आवश्यकता है कि SciPy 1.4.0rc2 तैयारी के लिए सैकड़ों परीक्षण विफलताओं के बारे में क्या करना है। https://github.com/scipy/scipy/pull/11161

tylerjereddy 4 दिस॰ 2019

अब मुझे यह पता लगाने की जरूरत है कि सैकड़ों परीक्षण विफलताओं के बारे में क्या करना है

एक आसान विकल्प होगा:

अपने pytest config में चेतावनी को रोकें
बाद में इसे ठीक करने के लिए कोई समस्या खोलें

हमें में पूरे मुद्दे का उपयोग कर DeprecationWarning के बजाय ValueError नीचे की ओर परियोजनाओं और उन बिल्कुल ऐसा करने के लिए एक की ग्रेस अवधि प्रदान किया गया था।

eric-wieser 4 दिस॰ 2019

AFAIK, बहिष्करण रिलीज शाखा में है। क्या हम इसे वापस करना चाहते हैं?

मुझे लगता है कि हम करते हैं, यह मुद्दों की बारिश कर रहा है। अब हमारे पास पंडों, Matplotlib, SciPy, numpy.testing और NumPy ufuncs, == आदि के अंदर क्या टूट रहा है, इसकी एक सूची है। मुझे लगता है कि हमें अब परिवर्तन वापस करना चाहिए और उन सभी का आकलन/ठीक करना चाहिए चीज़ें, फिर बहिष्करण पुन: प्रस्तुत करें।

rgommers 4 दिस॰ 2019

क्या हम एक लंबित मूल्यह्रास चेतावनी पर समझौता कर सकते हैं?

eric-wieser 4 दिस॰ 2019

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

eric-wieser 4 दिस॰ 2019

ऐसा लगता है कि हम मूल मुद्दे से अलग हो गए हैं, जो "मूल्यों का अनुक्रम दिया गया है, मैटप्लोटलिब कैसे निर्धारित कर सकता है कि वे एक रंग या रंगों की सूची हैं"। मुझे लगता है कि एक समाधान होना चाहिए जिसके लिए मूल्यों को ndarray पर कास्टिंग करने और उस सरणी के प्रकार की जांच करने की आवश्यकता नहीं है। किसी प्रकार का पुनरावर्ती is_a_color() फ़ंक्शन एक बेहतर समाधान हो सकता है।

mattip 4 दिस॰ 2019

मैंने 1.18.x के लिए #15053 में परिवर्तन वापस कर दिया है।

charris 4 दिस॰ 2019

भावना यह है कि ब्रेकिंग स्किपी और पांडा सीआई अस्थायी रूप से मास्टर में भी इसे वापस करने के लिए काफी परेशान है। मैं चाहूंगा कि यह मूल रूप से निर्धारित (एक महीने के भीतर) में वापस जाए। हालाँकि हमें इसका समाधान खोजने की आवश्यकता हो सकती है। इसके अलावा फिक्सअप पांडा मेरे लिए थोड़ा चिंताजनक हैं, क्योंकि वे catch_warnings ।

यदि वास्तव में कोई रास्ता नहीं है, और हमें थ्रेड-सुरक्षित चेतावनी दमन की आवश्यकता है। np.seterr संभवतः इसके लिए एक स्लॉट रख सकता है: /।

seberg 4 दिस॰ 2019

ऐसा लगता है कि हम मूल मुद्दे से अलग हो गए हैं, जो "मूल्यों का अनुक्रम दिया गया है, मैटप्लोटलिब कैसे निर्धारित कर सकता है कि वे एक रंग या रंगों की सूची हैं"।

मुझे लगता है कि @anntzer जो मुद्दा

ndarray(flexible_input) बनाएं
अगर `new_ndarray.dtype.kind == 'O': इसे संभालें
अन्य: use_the_array

चूँकि कोई ऐसे कोड में dtype=object नहीं जोड़ सकता, तो क्या किया जाना चाहिए?

इसके अलावा फिक्सअप पांडा मेरे लिए थोड़ा चिंताजनक हैं, क्योंकि वे catch_warnings ।

@seberg इसके लिए suppress_warnings बेहतर नहीं था?

rgommers 4 दिस॰ 2019

@rgommers नहीं, suppress_warnings ने चेतावनियों के दमन के मुद्दे को स्थायी रूप से हल किया जब यह नहीं होना चाहिए। हालांकि इसे नए पायथन संस्करणों पर तय किया गया है, ताकि हमें वास्तव में इसकी आवश्यकता न हो (इसमें बेहतर गुण हैं, क्योंकि यह घोंसले का समर्थन करता है, लेकिन यह थ्रेड सुरक्षा का समर्थन नहीं करता है। मुझे यकीन नहीं है कि यह पाइथन के बाहर भी संभव है, और यहां तक कि अगर ऐसा था, तो शायद यह वांछनीय नहीं है)

seberg 5 दिस॰ 2019

पूरी तरह से सुनिश्चित नहीं हैं कि यदि समस्याग्रस्त मामले मूल इरादे (https://numpy.org/neps/nep-0034.html) के खिलाफ चलते हैं, तो हम अभी प्रत्याशित नहीं हैं।

वैसे भी, एक तरीका यह होगा कि "आपकी चिंता की सराहना करते हुए पुराने व्यवहार को स्पष्ट रूप से सक्षम किया जाए, लेकिन हम स्पष्ट रूप से संदर्भ-निर्भर ऑब्जेक्ट dtype चाहते हैं और समस्याग्रस्त इनपुट को स्वयं संभाल लेंगे"। कुछ ऐसा

~~~
np.array(डेटा, dtype='allow_object')

np.array(डेटा, allow_object_dtype=True)

np.array_create_allow_object_dtype() के साथ:
एनपी.सरणी (डेटा)
~~~

सभी बहुत सुंदर नहीं हैं और नामकरण में सुधार होना निश्चित है। लेकिन यह पुस्तकालयों के लिए एक साफ रास्ता देता है जो व्यवहार पर निर्भर करता है और इसे रखना चाहता है (कम से कम इस समय के लिए)।

timhoffm 5 दिस॰ 2019

क्या वास्तव में matplotlib मामला नहीं है:

with np.forbid_ragged_arrays_immediately():
    np.array(data)

चूंकि वास्तव में आप ऑब्जेक्ट dtype प्राप्त करने के बजाय त्रुटि को पकड़ना चाहते हैं?

eric-wieser 6 दिस॰ 2019

वर्तमान में मास्टर के लिए लंबित बहिष्करण का कोई प्रत्यावर्तन नहीं है। मुझे नहीं लगता कि इसे थोक में वापस किया जाना चाहिए क्योंकि यह 1.18 में था क्योंकि इससे फिक्स भी हटा दिए गए थे, जो मुझे लगता है कि हम रखना चाहते हैं। @mattip एक अधिक लक्षित प्रत्यावर्तन की सराहना की जाएगी जब तक कि हम तय नहीं करते कि लंबी अवधि में क्या करना है।

charris 6 दिस॰ 2019

👍1

एफडब्ल्यूआईडब्ल्यू मुझे लगता है कि एमपीएल में अधिकांश जगहों पर इसे मारा जा सकता है (अधिक या कम पुनर्गठन के साथ - एक मामले में यह बहुत तेजी से कोड को बदल देता है ...)
मुझे लगता है कि @timhoffm का प्रस्तावित एपीआई with np.forbid_ragged_arrays_immediately: तुलना में अच्छा होगा क्योंकि बाद वाले को आसानी से पूर्व के संदर्भ में लिखा जा सकता है (अगर np.array(..., allow_object=True).dtype == object बढ़ाएं) जबकि विपरीत ( try: with np.forbid: ... except ValueError: ... ) कम कुशल होगा यदि हम अभी भी ऑब्जेक्ट सरणी बनाना चाहते हैं। लेकिन एक सीएम (सिर्फ "स्थानीय रूप से बहिष्करण अवधि से आगे बढ़ रहा है") कुछ भी नहीं से बेहतर होगा।

(फिर से, मुझे लगता है कि परिवर्तन एक अच्छा है, यह सिर्फ एक बात है कि इसे कैसे क्रियान्वित किया जाता है।)

anntzer 6 दिस॰ 2019

हाँ, हमें बस यह पता लगाने की ज़रूरत है कि एपीआई कैसा दिखना चाहिए। जैसा कि कई लोगों ने बताया, वर्तमान में दो मुख्य मुद्दे हैं:

object और "allow ragged" । यदि वस्तुओं का उचित प्रकार है ( Decimal कहें) तो आप वास्तव में चेतावनी/त्रुटि प्राप्त करना चाहते हैं लेकिन dtype=object पास करने की भी आवश्यकता हो सकती है
नए व्यवहार में ऑप्ट-इन करने या पुराने (बिना किसी चेतावनी के) का उपयोग करने का कोई तरीका नहीं है। ऐसा लगता है कि आंतरिक उपयोग के लिए कम से कम ऑप्ट-इन आवश्यक है, अगर हम इसे प्रदान नहीं करते हैं, तो हम मूल रूप से मानते हैं कि (संभवतः अप्रत्यक्ष रूप से) यह केवल अंतिम उपयोगकर्ता हैं जो इन मामलों में भाग लेते हैं?

अंत में, हमें यह पता लगाना होगा कि इसे हमारे कोड में कैसे रटना है :)। ndmin कम से कम रैग्ड व्यवहार को नियंत्रित करने वाले झंडे में रटना का एक और लक्ष्य हो सकता है।

seberg 6 दिस॰ 2019

वर्तमान में मास्टर के लिए लंबित बहिष्करण का कोई प्रत्यावर्तन नहीं है। मुझे नहीं लगता कि इसे थोक में वापस किया जाना चाहिए क्योंकि यह 1.18 में था क्योंकि इससे फिक्स भी हटा दिए गए थे, जो मुझे लगता है कि हम रखना चाहते हैं। @mattip एक अधिक लक्षित प्रत्यावर्तन की सराहना की जाएगी जब तक कि हम तय नहीं करते कि लंबी अवधि में क्या करना है।

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

rgommers 6 दिस॰ 2019

अभी तक वापस न आने का तर्क - जबकि परिवर्तन मास्टर में है, हम डाउनस्ट्रीम सीआई रन का लाभ उठा सकते हैं और यह पता लगाने की कोशिश कर सकते हैं कि उनके वर्कअराउंड कैसा दिखेंगे

eric-wieser 6 दिस॰ 2019

डाउनस्ट्रीम CI लाल है, यह _very_ अनुपयोगी है। अब हमारे पास उनकी विफलताओं की सूची है, हमें यहां अपने जीवन को थोड़ा आसान बनाने के लिए उनके सीआई को लाल रखने की आवश्यकता नहीं है।

rgommers 6 दिस॰ 2019

और कम से कम Matplotlib का CI pip install --pre विरुद्ध चल रहा है न कि मास्टर शाखा

tacaswell 6 दिस॰ 2019

और कम से कम Matplotlib का CI pip install --pre विरुद्ध चल रहा है न कि मास्टर शाखा

ऐसा लगता है कि रात के पहियों से खींच रहा है। परिवर्तन पहले से ही 1.18.0rc1 के लिए पूर्ववत किया गया था, इसलिए यदि आप PyPI से --pre साथ इंस्टॉल कर रहे हैं तो आपको यह नहीं दिखना चाहिए।

rgommers 6 दिस॰ 2019

उपरोक्त टिप्पणियों में से कुछ एनईपी 34 में प्रस्तावित परिवर्तनों पर पुनर्विचार करने की राशि है। मुझे यकीन नहीं है कि यह धागा इस चर्चा को जारी रखने के लिए उपयुक्त जगह है, लेकिन यहां जाता है। (कोई हानि नहीं अगर इसकी चर्चा कहीं और की जानी चाहिए - टिप्पणियों की प्रतिलिपि बनाना और चिपकाना आसान है। मुस्कान: इसके अलावा, आप में से कुछ ने इन टिप्पणियों को सुस्त पर चर्चा में भिन्नता देखी है।)

हाल ही में इस बारे में सोचने के बाद, मैं @timhoffm के पहले सुझाव के समान विचार के साथ समाप्त हुआ (और विचार शायद पिछले कुछ महीनों में अन्य समय पर प्रस्तावित किया गया है): एक विशिष्ट स्ट्रिंग या सिंगलटन ऑब्जेक्ट को परिभाषित करें, जब दिया गया हो dtype तर्क array , फ़ंक्शन को 1-डी ऑब्जेक्ट सरणी बनाकर रैग्ड-आकार के इनपुट को संभालने की अनुमति देता है। वास्तव में, यह dtype=None के पूर्व-एनईपी-34 व्यवहार को सक्षम बनाता है जिसमें रैग्ड-आकार का इनपुट स्वचालित रूप से ऑब्जेक्ट सरणी में परिवर्तित हो जाता है। यदि dtype लिए कोई अन्य मूल्य दिया गया है ( None या object ), तो इनपुट रैग्ड-आकार का होने पर एक मूल्यह्रास चेतावनी दी जाती है। NumPy के भविष्य के संस्करण में उस चेतावनी को एक त्रुटि में बदल दिया जाएगा।

मुझे लगता है कि अब यह स्पष्ट हो गया है कि रैग्ड-आकार के इनपुट को संभालने के लिए dtype=object का उपयोग करना समस्या का अच्छा समाधान नहीं है। आदर्श रूप से, हम "ऑब्जेक्ट एरे" की धारणाओं को "रैग्ड एरे" से अलग कर देंगे। लेकिन हम उन्हें पूरी तरह से अलग नहीं कर सकते, क्योंकि जब हम रैग्ड ऐरे को हैंडल करना चाहते हैं, तो हमारे पास ऑब्जेक्ट ऐरे बनाने का एकमात्र विकल्प होता है। दूसरी ओर, कभी-कभी हम एक ऑब्जेक्ट ऐरे चाहते हैं, लेकिन हम रैग्ड-शेप्ड इनपुट के स्वचालित रूपांतरण को अनुक्रमों के ऑब्जेक्ट एरे में नहीं चाहते हैं।

उदाहरण के लिए (cf. आइटम 1 में @seberg की अंतिम टिप्पणी), मान लीजिए f1 , f2 , f3 और f4 Fraction ऑब्जेक्ट्स, और मैं Fraction s के ऑब्जेक्ट एरेज़ के साथ काम कर रहा हूं। मुझे रैग्ड ऐरे बनाने में कोई दिलचस्पी नहीं है। अगर मैं गलती से a = np.array([f1, f2, [f3, f4]], dtype=object) लिखता हूं, तो मैं _want_ कि एक त्रुटि उत्पन्न करने के लिए, उन सभी कारणों से जो हमारे पास NEP 34 है। NEP 34 के साथ, हालांकि, यह लंबाई 3 की 1-d सरणी बनाएगी।

विकल्प जो एक नया कीवर्ड तर्क जोड़ते हैं, जैसे @timhoffm का दूसरा सुझाव, आवश्यकता से अधिक जटिल लगता है। जिस समस्या को हम हल करने का प्रयास कर रहे हैं वह "फुट गन" है जहां रैग्ड इनपुट स्वचालित रूप से 1-डी ऑब्जेक्ट सरणी में परिवर्तित हो जाता है। समस्या केवल तब उत्पन्न होती है जब dtype=None को array में पास कर दिया जाता है। पुराने परेशानी भरे व्यवहार को बनाए रखने के लिए उपयोगकर्ताओं को dtype=None को dtype=<special-value-that-enables-ragged-handling> से बदलने की आवश्यकता है, यह एपीआई में सरल परिवर्तन है जिसे समझाना आसान है। क्या हमें वास्तव में इससे ज्यादा की जरूरत है?

WarrenWeckesser 6 दिस॰ 2019

मुझे लगता है कि अब यह स्पष्ट हो गया है कि रैग्ड-आकार के इनपुट को संभालने के लिए dtype=object का उपयोग करना समस्या का अच्छा समाधान नहीं है। आदर्श रूप से, हम "ऑब्जेक्ट एरे" की धारणाओं को "रैग्ड एरे" से अलग कर देंगे।

उचित लगता है, शायद। यह बताना भी अच्छा है कि NumPy में कोई वास्तविक "रैग्ड ऐरे" अवधारणा नहीं है । यह ऐसा कुछ है जिसका हम मूल रूप से समर्थन नहीं करते हैं (यदि आप चाहते हैं तो पुष्टि करने के लिए समस्या ट्रैकर या मेलिंग सूची पर दस्तावेज़ों में "रैग्ड" खोजें), यह कुछ ऐसा है जो डीवाईएनडी और एक्सएनडी समर्थन करता है, और हमने केवल संक्षिप्त होने के बारे में बात करना शुरू कर दिया है चर्चा करने के लिए वाक्यांश "हम np.array([1, [2, 3]]) व्यवहार को हटाना चाहते हैं जो उपयोगकर्ताओं को ट्रिप करता है"। इसलिए एक नई एपीआई चीज़ के रूप में "रैग्ड एरेज़" में पकाना अत्यधिक सावधानी के साथ किया जाना चाहिए, यह बिल्कुल ऐसा कुछ नहीं है जिसे हम बढ़ावा देना चाहते हैं। तो अच्छा होगा कि हम जो कुछ भी dtype=some_workaround जोड़ सकते हैं उसके नामकरण में यह स्पष्ट कर दें।

rgommers 7 दिस॰ 2019

👍1

ऐसा लगता है कि आम राय np.array(vals, dtype=special) अनुमति देकर बहिष्करण (शायद अनिश्चित काल तक) को बढ़ाने के समाधान के आसपास एकत्रित हो रही है जो एनईपी 34 से पहले व्यवहार करेगी। मैं एक स्ट्रिंग के बजाय सिंगलटन पसंद करता हूं, क्योंकि इसका मतलब है कि पुस्तकालय उपयोग special = getattr(np.special, None) कर सकता है

अब हमें यह तय करने की जरूरत है कि नाम कहां रखा जाए और इसे कहां उजागर किया जाए। शायद never_fail या guess_dimensions ? जहां तक इसका खुलासा करने के लिए है, मैं इसे np बजाय कुछ अन्य आंतरिक मॉड्यूल से लटकाना पसंद नहीं करूंगा, शायद _ के साथ यह इंगित करने के लिए कि यह वास्तव में एक निजी इंटरफ़ेस है।

मुझे लगता है कि आगे का रास्ता एनईपी 34 में संशोधन करना है, फिर मेलिंग सूची पर चर्चा को उजागर करना है।

mattip 8 दिस॰ 2019

ध्यान दें कि ऑपरेटरों का उपयोग करने में समस्याओं की कुछ रिपोर्टें भी आई हैं ( == और operator.mod कम से कम)। क्या आप इसे अनदेखा करने का प्रस्ताव कर रहे हैं, या किसी भी तरह उस राज्य को सरणी पर संग्रहीत करने का प्रस्ताव कर रहे हैं?

rgommers 9 दिस॰ 2019

लगभग सभी मामलों में यह शायद ज्ञात है कि ऑपरेंड में से एक एक numpy array है। तो संभवतः एक सुस्पष्ट सरणी में मैन्युअल रूप से परिवर्तित करके अच्छी तरह से परिभाषित व्यवहार प्राप्त करना संभव होना चाहिए।

seberg 9 दिस॰ 2019

क्या कोई operator.mod उदाहरण की ओर इशारा कर सकता है?

mattip 9 दिस॰ 2019

👍2

क्या कोई operator.mod उदाहरण की ओर इशारा कर सकता है?

देखा कि @jbrockmendel के पंडों पीआर में, लेकिन मुझे लगता है कि यह तब से बदल गया है (अब टिप्पणियों में एक स्पष्ट operator.mod नहीं देखें)।

जहां तक == ऑपरेटर का सवाल है, जो मैंने देखा वह np.array(vals, dtype=object) == vals जैसा कुछ कर रहा था, जहां vals=[1, [2, 3]] (कोड को पैराफ्रेश करना), इसलिए समाधान सक्रिय रूप से दाईं ओर सरणी बनाना है पक्ष।

उस समय यह np.array(vals, dtype=object) == np.array(vals, dtype=object) बन जाता है, इसलिए बेहतर होगा कि परीक्षण को हटा दें :)

rgommers 10 दिस॰ 2019

@mattip ने लिखा:

मैं एक स्ट्रिंग के बजाय एक सिंगलटन पसंद करता हूं, क्योंकि इसका मतलब है कि पुस्तकालय का उपयोग विशेष = getattr (np.special, कोई नहीं) कर सकता है और उनका कोड सभी संस्करणों में काम करेगा।

यह मुझे ठीक लगता है।

WarrenWeckesser 10 दिस॰ 2019

अब हमें यह तय करने की जरूरत है कि नाम कहां रखा जाए और इसे कहां उजागर किया जाए। शायद never_fail या guess_dimensions ? जहां तक इसका खुलासा करने के लिए है, मैं इसे एनपी के बजाय कुछ अन्य आंतरिक मॉड्यूल से लटकाना पसंद नहीं करूंगा, शायद _ के साथ यह इंगित करने के लिए कि यह वास्तव में एक निजी इंटरफ़ेस है।

इसके लिए मेरा वर्तमान कामकाजी नाम legacy_auto_dtype , लेकिन शायद ऐसे कई अन्य नाम हैं जिनके बारे में मुझे कोई शिकायत नहीं होगी।

मुझे यकीन नहीं है कि नाम निजी होना चाहिए। _private_ और _public_ की किसी भी व्यावहारिक परिभाषा के अनुसार, यह एक _public_ वस्तु होगी। यह उपयोगकर्ताओं को विरासती व्यवहार को संरक्षित करने का साधन प्रदान करता है, उदाहरण के लिए, array(data) को array(data, dtype=legacy_auto_dtype) रूप में फिर से लिखकर। मुझे लगता है कि अद्यतन एनईपी समझाएगा कि विरासत व्यवहार को बनाए रखने के लिए कोड को इस तरह संशोधित किया जाना चाहिए (उन लोगों के लिए जो ऐसा करना चाहिए)। यदि ऐसा है, तो वस्तु निश्चित रूप से निजी नहीं है। वास्तव में, ऐसा लगता है कि यह एक सार्वजनिक वस्तु है जो अनिश्चित काल तक NumPy में रहेगी। लेकिन शायद मेरी समझ गलत है कि संशोधित एनईपी 34 कैसे काम करेगा।

WarrenWeckesser 10 दिस॰ 2019

सार्वजनिक/निजी के @WarrenWeckesser के विवरण से सहमत; या तो यह सार्वजनिक है, या इसे NumPy के बाहर किसी के द्वारा भी उपयोग नहीं किया जाना चाहिए।

पुन: नाम: कृपया एक ऐसा नाम चुनें जो कार्यक्षमता का वर्णन करता हो। "विरासत" जैसी चीजें लगभग कभी भी एक अच्छा विचार नहीं होती हैं।

rgommers 10 दिस॰ 2019

कृपया एक नाम चुनें जो कार्यक्षमता का वर्णन करता है।

auto_object , auto_dtype , auto ?

charris 10 दिस॰ 2019

कुछ देर जोर से सोचना...

यह वस्तु क्या करती है?

वर्तमान में, जब NumPy को एक पायथन ऑब्जेक्ट दिया जाता है जिसमें बाद की लंबाई होती है, जिसकी लंबाई नियमित nd सरणी के अनुरूप नहीं होती है, तो NumPy object डेटा प्रकार के साथ एक सरणी बनाएगा, जिसमें पहले स्तर पर ऑब्जेक्ट होंगे जहां आकार असंगतता होती है। पायथन वस्तुओं के रूप में छोड़ दिया। उदाहरण के लिए, array([[1, 2], [1, 2, 3]]) का आकार (2,) , np.array([[1, 2], [3, [99]]]) का आकार (2, 2) , आदि। NEP 34 के साथ, हम उस व्यवहार को हटा रहे हैं, इसलिए एक बनाने का प्रयास कर रहे हैं "रैग्ड" इनपुट वाली सरणी अंततः एक त्रुटि का परिणाम देगी, जब तक कि यह स्पष्ट रूप से सक्षम न हो। हम जिस विशेष मूल्य के बारे में बात कर रहे हैं वह पुराने व्यवहार को सक्षम बनाता है।

कि के लिए एक अच्छा नाम क्या है? ragged_as_object ? inconsistent_shapes_as_object ?

WarrenWeckesser 10 दिस॰ 2019

उस समय यह np.array(vals, dtype=object) == np.array(vals, dtype=object) बन जाता है, इसलिए बेहतर होगा कि परीक्षण को हटा दें :)

खैर, मैं व्याख्या कर रहा था। वास्तविक परीक्षण अधिक है जैसे my_func(vals) == vals बनना चाहिए my_func(vals) == np.array(vals, dtype=object)

मैं डीटाइप के लिए एक विशेष मूल्य की अनुमति देने के लिए एनईपी 34 के विस्तार का प्रस्ताव दूंगा।

mattip 10 दिस॰ 2019

ध्यान दें कि ऐसा लगता है कि scipy को scipy/scipy#11310 और scipy/scipy#11308 के साथ परीक्षण पास करने के लिए इस प्रहरी की आवश्यकता नहीं है

mattip 3 जन॰ 2020

🎉1

gh-15119 को विलय कर दिया गया, जिसने NEP को फिर से लागू किया। अगर इसे वापस नहीं किया जाता है, तो हम इस मुद्दे को बंद कर सकते हैं

mattip 22 जन॰ 2020

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

seberg 18 जुल॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Numpy: वस्तु सरणियों का "नियंत्रित" निर्माण

पुनरुत्पादन कोड उदाहरण:

Numpy/पायथन संस्करण जानकारी:

सबसे उपयोगी टिप्पणी

सभी 45 टिप्पणियाँ

संबंधित मुद्दों