Numpy: ENH: `अक्ष` तर्क के साथ `random.shuffle` का विकल्प।

यह न देखें कि इसे एक विकल्प की आवश्यकता क्यों होगी -- क्यों न केवल a . जोड़ें
फेरबदल करने के लिए अक्ष तर्क? कोई नहीं के लिए डिफ़ॉल्ट, जैसे np.sum।

शनिवार, अक्टूबर 11, 2014 को रात 9:36 बजे, वॉरेन वेकेसर नोटिफिकेशन @github.com
लिखा था:

numpy.random.shuffle का विकल्प रखना अच्छा होगा कि
एक अक्ष तर्क स्वीकार करता है, और जो स्वतंत्र रूप से फेरबदल करता है
एक आयामी स्लाइस। यहां एक कार्यान्वयन है जिसे मैं अव्यवस्थित कहूंगा।
यह काम करता है, लेकिन अधिक कुशल सी कार्यान्वयन करना अच्छा होगा।

डीईएफ़ अव्यवस्थित (ए, अक्ष = -1):
"""
दिए गए अक्ष के साथ-साथ a शफ़ल करें।

Apply numpy.random.shuffle to the given axis of `a`.
Each one-dimensional slice is shuffled independently.
"""
b = a.swapaxes(axis, -1)
# Shuffle `b` in-place along the last axis.  `b` is a view of `a`,
# so `a` is shuffled in place, too.
shp = b.shape[:-1]
for ndx in np.ndindex(shp):
    np.random.shuffle(b[ndx])
return

उदाहरण:

[156] में: a = np.arange(20).reshape(4,5)

[157] में: ए
आउट [157]:
सरणी ([[0, 1, 2, 3, 4],
[5, 6, 7, 8, 9],
[10, 11, 12, 13, 14],
[15, 16, 17, 18, 19]])

[158] में: अव्यवस्थित (ए, अक्ष = -1)

[159] में: ए
आउट [159]:
सरणी ([[ 2, 0, 4, 3, 1],
[8, 6, 7, 9, 5],
[11, 14, 13, 10, 12],
[19, 18, 16, 17, 15]])

[160] में: a = np.arange(20).reshape(4,5)

[161] में: अव्यवस्थित (ए, अक्ष = 0)

[162] में: ए
आउट [162]:
सरणी ([[5, 11, 7, 13, 14],
[0, 6, 2, 3, 4],
[10, 1, 17, 18, 19],
[15, 16, 12, 8, 9]])

यह अनुरोध स्टैक ओवरफ्लो पर इस प्रश्न से प्रेरित था:
http://stackoverflow.com/questions/26310346/quickly-calculate-randomized-3d-numpy-array-from-2d-numpy-array/

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5173।

नथानिएल जे स्मिथ
पोस्टडॉक्टोरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

shuffle का वर्तमान व्यवहार वास्तव में axis=None जैसा नहीं है। यह अपने तर्क को एक आयामी अनुक्रम के रूप में मानता है।

In [181]: a = np.arange(20).reshape(4,5)

In [182]: np.random.shuffle(a)

In [183]: a
Out[183]: 
array([[ 0,  1,  2,  3,  4],
       [15, 16, 17, 18, 19],
       [ 5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14]])

आप इसे axis=0 रूप में व्याख्या कर सकते हैं, लेकिन लापता विशेषता 1-डी स्लाइस का स्वतंत्र फेरबदल है।

2-डी सरणी के लिए, आप a.T का अनुकरण करने के लिए फेरबदल कर सकते हैं axis=1 , लेकिन इससे आपको स्वतंत्र फेरबदल नहीं मिलेगा:

In [184]: a = np.arange(20).reshape(4,5)

In [185]: np.random.shuffle(a.T)

In [186]: a
Out[186]: 
array([[ 4,  1,  0,  3,  2],
       [ 9,  6,  5,  8,  7],
       [14, 11, 10, 13, 12],
       [19, 16, 15, 18, 17]])

disarrange , मैं axis=None की तरह कार्य करने की अपेक्षा करता हूं np.random.shuffle(a.flat) ।

यह ठीक होगा यदि वैकल्पिक फेरबदल को shuffle उचित तर्क जोड़कर लागू किया गया था जो नियंत्रित करता है कि यह कैसे व्यवहार करता है, लेकिन मेरे पास उस एपीआई के लिए कोई प्रस्ताव नहीं है।

शायद shuffle : axis और independent (या उन पंक्तियों के साथ कुछ) में दो तर्क जोड़े जा सकते हैं। नया हस्ताक्षर होगा:

def shuffle(a, independent=False, axis=0)

जब independent गलत होता है, तो यह वर्तमान shuffle तरह कार्य करता है। जब सही होता है, तो यह disarrange जैसा कार्य करता है।

ओह, उह, मैंने अभी माना है कि यह अनुरूप के साथ अधिक संगत था
सॉर्ट जैसे कार्य :-(। यह अच्छा होगा यदि इस तरह का
शफलिंग-ऑफ-स्लाइस idx = arange(...); फेरबदल (आईडीएक्स);
multi_dim_array [idx, ...]; लेकिन किसी ने मुझसे नहीं पूछा :-)

मैं फेरबदल के एक संस्करण पर +1 हूं जिसमें कॉलिंग सम्मेलन हैं जो मेल खाते हैं
np.sort, हालांकि एक नियम के रूप में हमें सूची के साथ जांच करनी चाहिए। उनके पास हो सकता है
श्रेष्ठ नाम जैसे महत्वपूर्ण मुद्दों पर सुझाव भी :-)

(शायद "हाथापाई"?)

शनिवार, अक्टूबर 11, 2014 को रात 10:31 बजे, वॉरेन वेकेसर < नोटिफिकेशन @github.com

लिखा था:

फेरबदल का वर्तमान व्यवहार वास्तव में अक्ष = कोई नहीं जैसा नहीं है। यह व्यवहार करता है
एक आयामी अनुक्रम के रूप में इसका तर्क।

[181] में: a = np.arange(20).reshape(4,5)

[182] में: np.random.shuffle(a)

[183] ​​में: ए
आउट [183]:
सरणी ([[0, 1, 2, 3, 4],
[15, 16, 17, 18, 19],
[5, 6, 7, 8, 9],
[10, 11, 12, 13, 14]])

आप व्याख्या कर सकते हैं कि अक्ष = 0 होने के नाते, लेकिन लापता विशेषता है
1-डी स्लाइस का स्वतंत्र फेरबदल।

2-डी सरणी के लिए, आप अक्ष = 1 का अनुकरण करने के लिए एटी को फेरबदल कर सकते हैं, लेकिन यह नहीं होगा
आपको स्वतंत्र फेरबदल मिलता है:

[184] में: a = np.arange(20).reshape(4,5)

[185] में: np.random.shuffle(aT)

[186] में: ए
आउट [186]:
सरणी ([[4, 1, 0, 3, 2],
[9, 6, 5, 8, 7],
[14, 11, 10, 13, 12],
[19, 16, 15, 18, 17]])

अव्यवस्था में, मैं अक्ष = कोई भी कार्य करने की अपेक्षा नहीं करता
np.random.shuffle(a.flat)।

वैकल्पिक फेरबदल को जोड़कर लागू किया जाए तो यह ठीक रहेगा
फेरबदल करने के लिए उपयुक्त तर्क जो नियंत्रित करते हैं कि यह कैसे व्यवहार करता है, लेकिन मैं नहीं करता
उस एपीआई के लिए एक प्रस्ताव है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5173#issuecomment -58765220।

नथानिएल जे स्मिथ
पोस्टडॉक्टोरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

आह, वांछित व्यवहार को sort एनालॉग के रूप में वर्णित करना एक अच्छा विचार है।

ओह, उह, मैंने अभी माना है कि यह समान कार्यों जैसे सॉर्ट के साथ अधिक संगत था

मैं भी हैरान था, और स्टैकओवरफ्लो प्रश्न पर टिप्पणियों के आधार पर, कम से कम दो अन्य अनुभवी सुन्न उपयोगकर्ता आश्चर्यचकित थे। मैं मेलिंग सूची पर चर्चा शुरू करूंगा।

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

शनिवार, अक्टूबर 11, 2014 को रात 11:00 बजे, वॉरेन वेकेसर < नोटिफिकेशन @github.com

लिखा था:

ओह, उह, मैंने अभी माना है कि यह अनुरूप के साथ अधिक संगत था
सॉर्ट . जैसे कार्य

मैं भी हैरान था, और स्टैक ओवरफ्लो पर टिप्पणियों के आधार पर
प्रश्न, कम से कम दो अन्य अनुभवी सुन्न उपयोगकर्ता आश्चर्यचकित थे। बीमार
मेलिंग सूची पर चर्चा शुरू करें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5173#issuecomment -58766099।

नथानिएल जे स्मिथ
पोस्टडॉक्टोरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

उनके पास बेहतरीन नाम जैसे महत्वपूर्ण मुद्दों पर भी सुझाव हो सकते हैं।

हमें Sue नाम के एक फंक्शन की जरूरत है।

बस इस सुविधा को +1 करना चाहता था, जैसा कि मुझे भी उम्मीद थी कि यह अस्तित्व में होगा, समान रूप से सॉर्ट करने के लिए (अक्ष = एन)। क्या डाक सूची पर कोई निर्णय लिया गया था?

मेलिंग सूची धागा यहाँ है:
http://thread.gmane.org/gmane.comp.python.numeric.general/59014

यह वास्तव में उपयोगी होगा!

मैं भी इसकी सराहना करूंगा!

बहु-आयामी सरणियों के लिए https://stackoverflow.com/a/35647011/3401634 के अनुसार X

np.random.shuffle(X)

वैसा ही है जैसा कि

np.take(X, np.random.permutation(X.shape[0]), axis=0, out=X)

तो क्यों न लागू करें

np.random.shuffle(X, axis=axis)

जैसा

np.take(X, np.random.permutation(X.shape[axis]), axis=axis, out=X)

डिफ़ॉल्ट axis=0 ?

इस पर कोई भी समाचार? मुझे आश्चर्य हुआ कि यह कार्यक्षमता मौजूद नहीं है। अभी के लिए मैं वर्कअराउंड के रूप में np.apply_along_axis साथ np.random.permutation का उपयोग कर रहा हूं।

क्या इसे अब #13829 की वजह से बंद किया जा सकता है?

(ध्यान दें कि यहां उदाहरणों पर काम करते समय, मुझे नए फेरबदल कोड में एक बग मिला। निम्नलिखित में, मैं https://github.com/numpy/numpy/pull/14662 में प्रस्तावित सुधार का उपयोग कर रहा हूं, जिसे विलय होना।)

@wkschwartz , #13829 में परिवर्तन उपयोगी है, लेकिन यह यहां अनुरोधित वृद्धि नहीं है। #13829 में जोड़ा गया अक्ष अभी भी सरणी को 1-डी अनुक्रम के रूप में फेरबदल करने के लिए मानता है। नया अक्ष तर्क उपयोगकर्ता को यह निर्दिष्ट करने की अनुमति देता है कि किस अक्ष को 1-डी अक्ष के रूप में देखा जाता है, लेकिन यह अक्ष के भीतर एक स्वतंत्र फेरबदल नहीं करता है।

उदाहरण के लिए,

In [1]: import numpy as np                                                      

In [2]: rng = np.random.default_rng()                                           

In [3]: x = np.arange(20).reshape(2, 10)                                        

In [4]: x                                                                       
Out[4]: 
array([[ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14, 15, 16, 17, 18, 19]])

In [5]: rng.shuffle(x, axis=1)                                                  

In [6]: x                                                                       
Out[6]: 
array([[ 5,  9,  6,  4,  7,  0,  3,  2,  1,  8],
       [15, 19, 16, 14, 17, 10, 13, 12, 11, 18]])

आप देख सकते हैं कि पंक्तियों को स्वतंत्र रूप से फेरबदल नहीं किया गया है। स्तंभों को पुनर्व्यवस्थित किया गया है, लेकिन प्रत्येक स्तंभ के मान समान हैं।

इस मुद्दे में अनुरोध किया गया व्यवहार स्वतंत्र रूप से फेरबदल करना है, जैसा कि ऊपर दिए गए disarrange कोड में है:

In [10]: x = np.arange(20).reshape(2, 10)                                       

In [11]: x                                                                      
Out[11]: 
array([[ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14, 15, 16, 17, 18, 19]])

In [12]: disarrange(x, axis=1)                                                  

In [13]: x                                                                      
Out[13]: 
array([[ 4,  3,  7,  8,  0,  6,  5,  2,  9,  1],
       [12, 15, 19, 17, 18, 14, 10, 13, 11, 16]])

मैं इसे फिर से जारी करना चाहूंगा, शायद बुधवार की बैठक के लिए भी। हमने अभी choice और permutation में उच्च आयामी क्षमताओं को जोड़ा है और 1.18 में भी अक्ष तर्क (यह इस प्रकार बिल्कुल नया है)।

ये सभी मौजूदा फेरबदल तर्क का उपयोग करते हैं जो कि shuffle the subarrays along this axis के बजाय shuffle along (individual) axis जो मुझे लगता है कि यकीनन क्या होना चाहिए। यानी यह "साथ" या दिए गए अक्ष के भीतर "ओवर" के बजाय फेरबदल करता है।

लेकिन, लगभग सभी अवसरों, में axis NumPy में अक्ष के साथ इसका मतलब है, जैसे उम्मीद है कि बहुत कुछ अपवादों को छोड़कर, के साथ apply_over_axes जो नाम में "पर" है। इसलिए मैं इतना निर्भीक रहूंगा और दावा करूंगा कि भ्रम से बचने के लिए तर्क का नाम बदलकर over_axis=0 करना भी बेहतर होगा! विशेष रूप से यादृच्छिक संख्याओं के लिए जहां गलत फेरबदल को नोटिस करना बहुत कठिन हो सकता है।

जैसा कि ऊपर जिथब क्रॉस-रेफरेंस में उल्लेख किया गया है, मेरे पास https://github.com/numpy/numpy/pull/15121 पर एक कार्य-प्रगति पीआर है

@WarrenWeckesser जो अच्छा है, मैं व्यक्तिगत रूप से इस बारे में अधिक चिंतित हूं कि हमने नए एपीआई में और हाल ही में उस पर अधिक अर्थ का विस्तार किया है।
और मैं सोच रहा हूं कि क्या हमें उस आंशिक रूप से पीछे नहीं हटना चाहिए, उदाहरण के लिए कम से कम axis तर्क का नाम बदलकर। या यहां तक ​​कि एक बार फिर से बहुआयामी व्यवहार से पूरी तरह छुटकारा पाना...

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

@seberg , इस मुद्दे को axis की दो व्याख्याओं के लिए "ओवर" और "साथ" का उपयोग करने के आपके सम्मेलन का पालन करूंगा। मैं नहीं जानता कि क्या हम इस बिंदु पर axis लिए shuffle और permutation की मौजूदा "साथ" व्याख्या को पूरी तरह से पूर्ववत कर सकते हैं, लेकिन मुझे लगता है कि बहुत से लोग खुशी होगी अगर यह पता चला कि हम कर सकते हैं। :)

कई साल पहले मेलिंग सूची चर्चा के अंत में, मैंने सोचा कि समाधान shuffle और permutation के एपीआई को नहीं बदलना था, और इसके बजाय धुरी के साथ यादृच्छिक रूप से दो नई विधियों को पेश करना था इसके बजाय इसके ऊपर। एक विधि जगह पर काम करेगी, और दूसरी एक प्रति लौटाएगी। उस समय मेरी प्राथमिकता permute और permuted नामों के लिए randomly_permute और randomly_permuted , लेकिन उन नामों को प्लेसहोल्डर माना जाना चाहिए। उन नामों पर निर्णय लेने से पहले, हमें यह तय करना होगा कि क्या दो नए फ़ंक्शन जोड़ना सही तरीका है। यहां से, संक्षिप्तता के लिए, मैं प्रस्तावित नई विधियों को permute और permuted रूप में संदर्भित करूंगा।

नए कार्यों के साथ, हमारे पास निम्नलिखित संबंधित Generator तरीके होंगे:

meaning    operate     return
of axis    in-place     copy
-------    --------  -----------
"over"     shuffle   permutation
"along"    permute   permuted

(ऐसी विधियां जो धुरी पर "ओवर" संचालित करती हैं, shuffle और permutation पहले से मौजूद हैं।)

दो नए तरीकों के बजाय, यह सुझाव दिया गया है कि हमारे पास सिर्फ एक है, एक पैरामीटर के साथ जो इन-प्लेस बनाम कॉपी व्यवहार को नियंत्रित करता है। इसके लिए दो सुझाव दिए गए हैं:

(ए) एक out पैरामीटर जोड़ें। इन-प्लेस काम करने के लिए, इनपुट ऐरे को out । यदि out प्रदान नहीं किया जाता है, तो एक फेरबदल की गई प्रति लौटाएं।
(बी) एक बूलियन ध्वज जोड़ें जैसे copy या inplace , जो वांछित व्यवहार को निर्दिष्ट करता है।

नई विधियों को बनाने का मुख्य विकल्प मौजूदा तरीकों में एक नया पैरामीटर जोड़ना है जो axis की व्याख्या करने के तरीके को बदल देता है। इन्हें सूचीबद्ध करने से पहले, मैं एक टिप्पणी दोहराऊंगा कि रॉबर्ट केर्न ने मेलिंग सूची थ्रेड में कहा था कि अभ्यास में अतिरिक्त तर्क का उपयोग कैसे किया जा सकता है (यहां नीचे दिखाए गए independent पैरामीटर का जिक्र है):

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

( संपादकीय विषयांतर : अनिवार्य रूप से इस तरह की चर्चा में, नेमस्पेस (इस मामले में, Generator नेमस्पेस) बढ़ने का मुद्दा सामने आता है (कभी-कभी इसे "नेमस्पेस प्रदूषण" कहा जाता है)। आइए सहमत हैं कि, हां, सभी चीजें समान होने पर, एक छोटा नामस्थान बेहतर होता है। लेकिन, अधिकांश एपीआई डिज़ाइन निर्णयों की तरह, ट्रेडऑफ़ पर विचार किया जाना चाहिए। यदि हम नाम स्थान को छोटा रखते हैं लेकिन अजीब या अत्यधिक जटिल एपीआई के साथ तरीके बनाते हैं, तो हम जीत नहीं रहे हैं।)

इतना सब कहने के बाद, यहां सुझाए गए shuffle के मौजूदा हस्ताक्षर में दो अतिरिक्त जोड़ दिए गए हैं।

(1) shuffle(x, axis=0, independent=False) : बूलियन ध्वज independent निर्धारित करता है कि axis की व्याख्या कैसे की जाती है: गलत -> "ओवर", सच -> "साथ"। (शायद इससे बेहतर नाम हैं independent ।)
(2) shuffle(x, axis=0, iaxis=???) : एक दूसरा तर्क, iaxis , "साथ" व्यवहार के लिए धुरी देता है। (यह axis साथ कैसे इंटरैक्ट करता है, एक स्पष्ट विनिर्देश की आवश्यकता है। संभवतः iaxis लिए एक मान देने से axis को अनदेखा कर दिया जाता है।)

मुझे लगता है कि मैंने सभी विभिन्न एपीआई विचारों को शामिल कर लिया है जो सामने आए हैं। अगर किसी को दूसरों के बारे में पता है तो हमें बताएं।

मैं यहां एपीआई बढ़ाकर खुश हूं। मुझे यकीन नहीं है कि इसके खिलाफ होने का बहुत कारण है:

• हम शायद सहमत हो सकते हैं कि यह एक उपयोगी है
• मौजूदा सुविधाओं के साथ इसे हासिल करने का कोई अच्छा तरीका नहीं है
• कुल व्यवहार स्विच के लिए kwarg उपयोग करना सामान्य पैटर्न नहीं लगता है, मुझे लगता है कि रॉबर्ट केर्न पूरी तरह से वहीं थे।

मुझे लगता है कि यहां जो चल रहा है वह यह है कि shuffle और permutation (और शायद choice ) की तुलना एक अनुक्रमण संचालन (यानी take ) से की जा सकती है, जो axis लिए समान अर्थ का उपयोग करता है। और यही कारण है कि यह मेरे लिए थोड़ा अजीब लगता है, शायद इस परिभाषा का नकारात्मक पक्ष यह है कि यह सामान्य सरणी-जागरूक कार्यों के विपरीत कभी भी एनडी को सामान्यीकृत नहीं कर सकता है (यहां तक ​​​​कि यदि आप arr[..., index] उपयोग करते हैं तो अनुक्रमण स्वयं भी करता है। यही वह है सरणियों के ढेर के लिए सामान्यीकृत करें और प्रत्येक व्यक्ति के लिए पहले जैसा ही ऑपरेशन करें)।
ध्यान दें कि take_along_axis ND को सामान्य रूप से "साथ" अर्थ प्रदान करता है take लिए ND को सही ढंग से (भले ही यह जटिल लगता हो)। apply_along_axis और apply_over_axis जहां से मुझे "ओवर" मिला, हालांकि मुझे यकीन नहीं है कि "ओवर" सही शब्द है ...

मुझे यहां वास्तविक बाहरी होने के लिए permutation (जो आसानी से बदलने योग्य नहीं है लेकिन shuffled होना चाहिए) लगता है। यह shuffle - shuffled , permute - permuted तो मुझे लगता है कि चीजें बहुत स्पष्ट और उचित दिखने लगती हैं। कोई भी shuffled जोड़ने और permutation पर बहिष्करण शुरू करने का इच्छुक है? permutation भी itertools.permutations , FWIW के साथ अपने व्यवहार में बहुत संगत नहीं है।

मुझे लगता है कि permutation , permute , permuted विभिन्न व्यवहारों के साथ समान-ध्वनि वाले नामों का एक भ्रमित ट्रिपल है। इससे बचना अच्छा होगा (संभवतः लंबे समय तक)।

हालांकि मौजूदा एपीआई का विस्तार करना आसान लगता है, मुझे लगता है कि @rkern की बात यह है कि ऐसे कीवर्ड नहीं हैं जो व्यवहार को मौलिक रूप से बदलते हैं, यह सबसे अच्छा रास्ता है।

मुझे लगता है कि इन-प्लेस बनाम नॉट-इन-प्लेस के लिए, हमारे पास NumPy में वैकल्पिक out= स्पेलिंग है। लेकिन चूंकि फेरबदल जगह-जगह है, इसलिए यह कोई समाधान नहीं है और फेरबदल करना अच्छा है। यह permuted लिए हो सकता है (अर्थात permuted(arr, out=arr) अर्थ permute(arr) , सिवाय - फेरबदल के विपरीत - यह ndarray परिवर्तित हो जाएगा)।
किसी भी मामले में, मुझे नए नाम स्थान को साफ़ करने के लिए permutation के पक्ष में shuffled को हटाने की योजना पसंद है!

मैं इस मुद्दे पर वापस आ रहा हूं (और संबंधित पीआर https://github.com/numpy/numpy/pull/15121 पर)।

वापस जब मैंने मूल मुद्दा बनाया, और वर्तमान shuffle एपीआई के साथ समस्या का वर्णन करने की कोशिश की, तो यह बताया गया कि समस्या की व्याख्या करने का एक तरीका यह है कि अधिकांश लोग axis तर्क की अपेक्षा करेंगे shuffle का axis तर्क sort के समान कार्य करने के लिए। sort साथ सादृश्य बहुत अच्छा है, इसलिए यह भी देखना उपयोगी हो सकता है कि हम इन-प्लेस ऑपरेशन बनाम सॉर्टिंग के लिए कॉपी करने के मुद्दे को कैसे संभालते हैं। फ़ंक्शन numpy.sort() एक सरणी-जैसे तर्क को स्वीकार करता है और एक क्रमबद्ध प्रतिलिपि देता है। इन-प्लेस सॉर्टिंग के लिए, कोई ndarray sort() विधि का उपयोग करता है । क्योंकि यह मौजूदा ndarray पर एक विधि है, इन-प्लेस ऑपरेशन स्पष्ट है। Gh-15121 में, इन-प्लेस फ़ंक्शन का तर्क जो बेतरतीब ढंग से इसके तर्क को क्रमपरिवर्तन करता है, एक ndarray np.array करता है, और उन इनपुट को भी अस्वीकार करता है जो अपरिवर्तनीय हो जाते हैं (उदाहरण के लिए हम [(1, 2, 3, 4), (5, 6, 7, 8)] इन-प्लेस फेरबदल नहीं कर सकते हैं )

यह बहुत अच्छा होगा अगर हम वास्तव में sort एपीआई को एक ऐसे फ़ंक्शन के साथ दोहरा सकते हैं जो एक शफल प्रतिलिपि देता है, और एक ndarray विधि जो जगह में शफल हो जाती है, लेकिन मुझे नहीं लगता कि ऐसा जोड़ना ndarray वर्ग के लिए एक विधि को स्वीकार किए जाने की कोई संभावना है।

और एक ndarray _method_ जो जगह-जगह फेरबदल करता है, लेकिन मुझे नहीं लगता कि ndarray वर्ग में ऐसी विधि जोड़ने से स्वीकार किए जाने की कोई संभावना है।

सिंगलटन जनरेटर के बिना मुझे लगता है कि इसे हासिल करना असंभव होगा।

@bashtage ने लिखा

मुझे यहां वास्तविक बाहरी होने के लिए permutation (जो आसानी से बदलने योग्य नहीं है लेकिन shuffled होना चाहिए) लगता है। [यदि यह] shuffle-shuffled , permute-permuted तो मुझे लगता है कि चीजें बहुत स्पष्ट और उचित दिखने लगती हैं। कोई भी shuffled जोड़ने और permutation पर बहिष्करण शुरू करने का इच्छुक है?

यह वही है जो 2014 में मेलिंग सूची चर्चा (प्रकार) में परिवर्तित हुई थी। यहां नथानिएल के सुझाव का लिंक दिया गया है: https://mail.python.org/pipermail/numpy-discussion/2014-October/071364.html

उसका scramble[d] है जिसे मैंने https://github.com/numpy/numpy/pull/15121 में randomly_permute[d] है ।

यदि हम shuffled को permutation प्रतिस्थापन के रूप में जोड़ते हैं, और अक्ष के साथ संचालित होने वाली नई विधियों को कॉल करते हैं permute[d] , तो संबंधित कार्यों की तालिका है

meaning    operate
of axis    in-place   return copy
-------    ---------  -----------
"over"     shuffle    shuffled
"along"    permute    permuted

जिसमें एक अच्छी संगति है। एपीआई के इस संस्करण में, किसी भी विधि में out पैरामीटर नहीं है।

https://github.com/numpy/numpy/pull/15121 में , मैंने हाल ही में एक और तरीका जोड़ा है, अस्पष्ट और स्पष्ट रूप से अस्थायी नाम permuted_with_out जो दर्शाता है कि out तर्क कैसा हो सकता है उपयोग किया गया। यदि हम out पैरामीटर के साथ जाते हैं, और मौजूदा विधियों के नामों के साथ चिपके रहते हैं shuffle और permutation , तो तालिका इस तरह दिखती है

meaning    operate
of axis    in-place                           return copy
-------    ---------------------------------  --------------------
"over"     shuffle(x, axis)                   permutation(x, axis)
"along"    permuted_with_out(x, axis, out=x)  permuted_with_out(x, axis)

लेकिन अगर हम एक out पैरामीटर पेश करने जा रहे हैं, तो हमें सुसंगत होना चाहिए और इसे permutation में भी इस्तेमाल करना चाहिए। और हम अभी भी permutation को shuffled बदलने पर विचार कर सकते हैं। और चूंकि नई shuffled विधि में out पैरामीटर है, जो इन-प्लेस ऑपरेशन की अनुमति देता है, shuffle अनावश्यक हो जाता है और permutation के साथ बहिष्कृत किया जा सकता है। फिर, shuffled और permuted के "अच्छे" नामों पर स्विच करना, तालिका है

    meaning    operate
    of axis    in-place                  return copy
    -------    ------------------------  -----------------
    "over"     shuffled(x, axis, out=x)  shuffled(x, axis)
    "along"    permuted(x, axis, out=x)  permuted(x, axis)

ध्यान दें कि out पैरामीटर केवल इन-प्लेस संचालन के लिए नहीं है। यह एक आउटपुट सरणी का पुन: उपयोग करने की अनुमति देता है, संभावित रूप से एक अस्थायी सरणी के निर्माण से बचता है। यह इस एपीआई का shuffle/shuffled/permute/permuted एपीआई पर एक फायदा है, लेकिन मुझे यकीन नहीं है कि यह लाभ वास्तव में कितना महत्वपूर्ण है। इस एपीआई का नुकसान दो तरीकों, shuffle और permutation का बहिष्करण है। तत्काल प्रभाव को कम करने के लिए ये कुछ समय के लिए "नरम" बहिष्करण हो सकते हैं (यानी दस्तावेज़ों में उनके उपयोग पर जोर दें, लेकिन वास्तव में थोड़ी देर के लिए बहिष्करण चेतावनी न जोड़ें)।

यह बदलाव के दो मुख्य दावेदारों का मेरा सारांश है। हमारे पास shuffle/shuffled/permute/permuted संस्करण है, या shuffled/permuted वाला संस्करण out पैरामीटर के साथ है। यदि, 2014 में वापस, किसी ने उन परिवर्तनों को लागू करने के लिए छलांग लगाई थी, जिन पर चर्चा की गई थी, तो शायद हमारे पास पहले से ही shuffle/shuffled/permute/permuted संस्करण होगा। लेकिन out का उपयोग करने वाले संस्करण में कुछ (छोटे? महत्वहीन?) फायदे हैं: चार के बजाय दो नाम, और out संभावित रूप से उपयोगकर्ता को कम अस्थायी चर रखने की अनुमति देता है। मैं दोनों में से किसी एक के साथ खुश रहूंगा।

लोग क्या सोचते हैं?

आपके द्वारा सूचीबद्ध तीन परिदृश्यों में से, मैं उन्हें 1, 3, और 2 से काफी पीछे रैंक दूंगा। 2 क्रमपरिवर्तन जो काफी मौलिक रूप से भिन्न चीजें कर रहे हैं, वे भ्रम के एक बड़े स्रोत की तरह लगते हैं। मेरी निजी प्राथमिकता किसी सुविधा को एक्सेस करने के लिए आउट के अनिवार्य उपयोग से बचना है; मैं हमेशा एक प्रदर्शन विकल्प के रूप में सोचता हूं जो कुछ परिदृश्यों में समझ में आता है। मैं वास्तव में छात्रों को केवल एक सुविधा का उपयोग करने के लिए उपयोग करना नहीं सिखाना चाहूंगा। मैं यह भी मानूंगा कि मामले में 3 x = shuffled(x, axis, out=x) भी return x बजाय return None , ताकि जब यह जगह पर हो, तो कोई x साथ समाप्त हो सकता है 3 बार दिखाई दे रहा है।

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

लेकिन _is_ के स्थान पर फेरबदल करना एक प्रदर्शन विकल्प है, है ना?

लेकिन _is_ के स्थान पर फेरबदल करना एक प्रदर्शन विकल्प है, है ना?

उपलब्ध होने पर इन-प्लेस एक कोडिंग शैली विकल्प भी हो सकता है। शायद एक भ्रमित करने वाला, और शायद त्रुटि-प्रवण।

मेरा व्यक्तिगत विचार यह है कि जब f(x, out=x) हमेशा थोड़ा जादुई लगता है क्योंकि इसे कभी-कभी कुछ जल्दी हासिल करने के लिए एक बहुत ही गैर-स्पष्ट तरीके के रूप में उपयोग किया जाता है। f(x, inplace=True), किसी और चीज़ की तरह नहीं दिखने के बावजूद, बहुत स्पष्ट लगता है (एक पुराने पांडा पैटर्न जैसा दिखता है जिसे ज्यादातर हटा दिया गया है)।

सच है, लेकिन यह एक कोडिंग शैली का विकल्प है जिसे NumPy में आमतौर पर out=... का उपयोग करके लिखा जाता है (जब तक कि आप इन-प्लेस ऑपरेटर या किसी विधि का उपयोग नहीं कर रहे हों)। या हो सकता है कि यह एक कोडिंग शैली पसंद है जिसे NumPy वर्तमान में ज्यादातर मामलों में सक्रिय रूप से आसान बनाने की कोशिश नहीं करता है ...

मैं इसे थोड़ा जादुई मानता हूं और inplace= kwarg कम जादुई हो सकता है, लेकिन वास्तविक प्राथमिकता के बिना भी? और मुझे यकीन नहीं है कि मुख्य कारण यह कम जादुई लगता है कि इन-प्लेस शफल यहां एल्गोरिदम के मूल में है। अधिकांश छात्रों के लिए एल्गोरिथम विवरण अधिक मायने नहीं रखता है और अंत में यह out= का उपयोग करके लगभग एक प्रति + संबंधित मेमोरी बैंडविड्थ को भी सुरक्षित करता है, और यह ufuncs के बराबर है। (उचित रूप से, ufuncs के लिए भी out=input शायद कुछ जादुई है, लेकिन इसका सामान्य जादू और एक ज्ञात पैटर्न - उन्नत उपयोगकर्ताओं के लिए।)

हालांकि यह लिखने में थोड़ा कठिन है, और पढ़ने में कुछ कम तेज है, np.shuffled(x, out=x) यह बहुत स्पष्ट लगता है कि व्यवहार क्या है। गैर-स्पष्ट हिस्सा केवल प्रदर्शन प्रभाव लगता है, जो मुझे उन्नत उपयोगकर्ताओं के लिए चिंता करने के लिए आरक्षित एक समस्या की तरह लगता है।

out के उपयोग की वकालत करने वालों के लिए एक काल्पनिक प्रश्न: यदि हमारे पास मौजूदा फ़ंक्शन numpy.sort और ndarray.sort थे, और हम अब एक सॉर्टिंग फ़ंक्शन जोड़ रहे थे, तो क्या पसंदीदा एपीआई numpy.sorted(a, axis=-1, kind=None, order=None, out=None) (इन-प्लेस सॉर्टिंग के लिए ndarray.sort विधि को लागू करने की कोई आवश्यकता नहीं है)?

ndarray.sort को list.sort बाद तैयार किया गया है, इसलिए यह शायद एक समझदार एपीआई विकल्प है। उस ने कहा, मैं np.sort पक्ष में नहीं होता, और इसके बजाय np.sorted(..., out=...) पक्ष में होता।

हां, मुझे लगता है कि np.sort का नाम np.sorted np.sort होना चाहिए (बिल्कुल अजगर के sorted() तरह)। चूंकि केवल विधि में ही व्यवहारिक व्यवहार होता है, हालांकि मुझे कोई चिंता नहीं दिखती।

मुझे " ndarray.sort पद्धति को लागू करने की कोई आवश्यकता नहीं है" के बारे में निश्चित नहीं है। मुझे इस पद्धति (या इसके स्थानीय व्यवहार) में कुछ भी गलत नहीं दिख रहा है। विधि के बारे में प्रश्न केवल तभी है जब हमें लगता है कि एक सुविधाजनक विधि को संक्षिप्त रूप प्रदान करना काफी महत्वपूर्ण है।
मुझे लगता है कि इन-प्लेस फ़ंक्शन संस्करण होने में भी कुछ भी गलत नहीं है। नॉट-इन-प्लेस संस्करण नए उपयोगकर्ताओं के लिए अच्छा लगता है और out= पैटर्न मेरे लिए काफी सामान्य है कि उन्नत उपयोगकर्ता पर्याप्त रूप से अच्छी तरह से सेवा कर रहे हैं।

मैं "ndarray.sort विधि को लागू करने की आवश्यकता के बिना" के बारे में निश्चित नहीं हूँ। मुझे इस पद्धति (या इसके स्थानीय व्यवहार) में कुछ भी गलत नहीं दिख रहा है।

वह मेरे एपीआई विचार प्रयोग का हिस्सा था। मेरा मतलब यह नहीं था कि अब हमारे पास कुछ भी गलत है। मैं बस इतना कह रहा था कि, अगर हम खरोंच से शुरू करते हैं - और मैं अपने काल्पनिक परिसर में जोड़ दूंगा कि हम सूचियों के लिए पायथन एपीआई के मिलान से चिंतित नहीं हैं - तो छँटाई के लिए पसंदीदा एपीआई numpy.sorted(..., out=...) , और हमें किसी और चीज की आवश्यकता नहीं होगी।

एक और सवाल, इतना काल्पनिक नहीं: यदि out का उपयोग करना यहां पसंदीदा विकल्प है, तो, पूरे NumPy में एपीआई स्थिरता के लिए, क्या हमें अंततः out को numpy.sort जोड़ने की योजना बनानी चाहिए, numpy.partition , numpy.argsort , और, ठीक है, बाकी सब कुछ जो वर्तमान में नहीं है?

हां, मेरी राय में ufuncs के समान अर्थशास्त्र के साथ out= kwarg जोड़ना व्यावहारिक रूप से सभी NumPy API फ़ंक्शन के लिए एक अच्छा विकल्प है। out तर्क की कोई कमी आम तौर पर एक वृद्धि की प्रतीक्षा कर रही है (हालांकि, मुझे लगता है कि व्यवहार में यह एक छोटी सी वृद्धि हो सकती है और दुर्लभ मामलों में संभवतः बहुत अधिक अतिरिक्त कोड जटिलता के लायक नहीं है)।