xref https://github.com/JuliaLang/julia/issues/11557#issuecomment -339776065 और नीचे, और @ Sacha0 का PR #24389 भी

मेरे पास इस आशय का कार्य प्रगति पर है कि मैं अगले या दो दिनों में पोस्ट करने की आशा करता हूं :)। श्रेष्ठ!

मेरे लिए fill(oneunit(T), sz) की तुलना में पठनीयता में एक गैर-तुच्छ हानि की तरह दिखता है ones(T, sz) ।

ध्यान दें कि आपको शायद ही कभी fill(oneunit(T), sz) रूप में वर्बोज़ के रूप में कुछ लिखने की आवश्यकता होती है, क्योंकि आमतौर पर oneunit(T) स्थान पर एक शाब्दिक या समान रूप से कॉम्पैक्ट पर्याप्त होता है। सरणी कंस्ट्रक्टरों में भविष्य के परिवर्तनों के साथ छोटे मंत्र भी संभव हो सकते हैं। इसके अतिरिक्त, एक बार जब आप fill परिवर्तित हो जाते हैं, तो आप इसके शौकीन हो जाते हैं, मैं आपको विश्वास दिलाता हूं :)। श्रेष्ठ!

हम सिर्फ यह चुन सकते हैं कि ones one का उपयोग करता है या oneunit । ones और zeros को सुविधा कार्य माना जाना चाहिए, जो तब तक ठीक है जब तक उनके पास अधिक सामान्य कार्यों के संदर्भ में स्पष्ट अर्थ हैं।

प्रति ट्राइएज योजना: अगले सप्ताह फिर से देखें, विशेष रूप से ones और zeros को MATLAB संगतता परत पर ले जाने पर विचार करते हुए, आधार में fill पक्ष में। श्रेष्ठ!

ones और oneunits दो विकल्पों में अंतर करेंगे।

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

यह कोई बदलाव नहीं है जिसके बारे में मैं रोमांचित हूं, लेकिन मैंने इसे उठाया क्योंकि यह एक तार्किक असंगति है। मुझे लगता है कि यह कहना उचित है कि ones(T, sz) अर्थ है fill(one(T), sz) लेकिन वास्तव में यह हुड के तहत क्या करता है fill(oneunit(T), sz) ।

एक विकल्प यह होगा कि इसका नाम बदलकर oneunits । एक विकल्प एक भयानक स्वैप करना होगा: one -> algebraic_one और oneunit -> one । यह तोड़ रहा है और बहिष्करण के माध्यम से करना संभव नहीं है, इसलिए मैं "भयानक" कहता हूं।

हां, मैं कहूंगा कि oneunits जोड़ना और ones को fill(one(T), ...) देना उसके लिए स्पष्ट समाधान होगा, नहीं?

मैं इसके साथ ठीक रहूंगा। जिज्ञासा से बाहर, के उपयोग क्या हैं fill(one(T), sz) ? क्या हमें ones की भी आवश्यकता है?

हाहा :) मैं पूछने जा रहा था - आप fill(oneunits(T), sz) उपयोग किस लिए करते हैं? (उदाहरण के लिए 1 मीटर, या 1 किलोग्राम, या 1 सेकंड से भरी सरणी का उपयोग किस लिए किया जाएगा?)

मुझे लगता है कि fill(one(T), sz) का उपयोग उसी कारण से किया जाता है जैसे zeros(T, sz) , जो कि कस्टम कमी-प्रकार-ऑपरेशन के लिए एक सरणी प्रारंभ करना है। एक सरणी z = zeros(T, sz) इसके तत्वों को z[i] += x साथ जोड़ने के लिए तैयार है जबकि o = fill(one(T), sz) इसके तत्वों को गुणा करने के लिए तैयार है o[i] *= x । उदाहरण के लिए, मैं उन स्थितियों के बारे में सोच रहा हूं जहां सरणी तत्व (सापेक्ष) संभावना का प्रतिनिधित्व कर सकते हैं। इन दो मामलों में, मैं क्रमशः + या * ऑपरेटर के लिए पहचान ढूंढ रहा हूं (और एडिटिव जेनरेटर नहीं)।

यह भी देखें #23544

हाहा :) मैं पूछने जा रहा था - आप fill(oneunits(T), sz) किसके लिए उपयोग करते हैं? (उदाहरण के लिए 1 मीटर, या 1 किलोग्राम, या 1 सेकंड से भरी सरणी का उपयोग किस लिए किया जाएगा?)

एक ODE के लिए आश्रित चर। यह अजीब होगा यदि आप T प्रकार की सरणी के लिए पूछे जाने पर इकाइयों का यादृच्छिक रूप से कटा हुआ हो?

fill को प्राथमिकता देने का मूल कारण यह है कि शक्तिशाली, ऑर्थोगोनल, कंपोज़ेबल टूल का एक तंग सेट ones / zeros जैसे तदर्थ, सीमित और अतिव्यापी टूल के बड़े संग्रह से बेहतर कार्य करता है। trues / falses । ऊपर की चर्चा इस बिंदु पर प्रकाश डालती है: जबकि fill उपरोक्त सभी उपयोग के मामलों को स्पष्ट रूप से समायोजित करता है और (अधिकांश वास्तविक उपयोग में) संक्षेप में, ones / zeros / trues / falses दृष्टिकोण के लिए प्रत्येक उपयोग के मामले के लिए एक नए फ़ंक्शन की आवश्यकता होती है।

आधार में पुनर्लेखन से कुछ प्रासंगिक उदाहरण:

complex.(ones(size(Ac, 1)), ones(size(Ac, 1)))

हो जाता है

fill(1.0 + 1.0im, size(Ac, 1))

तथा

2ones(Int, 2, 2, 2)

हो जाता है

fill(2, (2, 2, 2)) # or fill(2, 2, 2, 2) if you prefer

कृपया ध्यान दें कि ये fill अपने गैर- fill समकक्षों की तुलना में सरल, अधिक पठनीय, अधिक कॉम्पैक्ट और अधिक कुशल हैं, और base/ और test/ हैं ऐसे उदाहरणों से भरा पड़ा है। सभी परिवर्तनों के साथ, fill संक्रमण के लिए कुछ प्रारंभिक मानसिक समायोजन की आवश्यकता होती है। लेकिन समायोजन के बाद आप पाते हैं कि आपकी उंगलियों पर अधिक शक्ति और लालित्य है :)। श्रेष्ठ!

@ Sacha0: trues / falses सीधे से बदली नहीं हैं fill , लेकिन जरूरत उपयोग करने के लिए fill! एक साथ BitArray प्रारंभकर्ता। वे one और oneunit बीच अस्पष्टता में भी शामिल नहीं हैं। इसलिए मुझे नहीं लगता कि वे इस चर्चा में बिल्कुल भी फिट बैठते हैं।

ones , मैं आम तौर पर इसे बहिष्कृत करने का विरोध करता हूं, मुझे लाभ नहीं दिख रहा है। यह तर्क कि कुछ अभिव्यक्ति fill साथ अधिक प्रभावी ढंग से लिखी जा सकती हैं, मेरी राय में बहुत सम्मोहक नहीं है, क्योंकि ये सभी उदाहरण ones का उपयोग कुछ और करने के लिए मध्यवर्ती चरणों के रूप में करते हैं; लेकिन क्या होगा जब आप वास्तव में लोगों की एक सरणी चाहते हैं? फिर fill का उपयोग करना लंबा, कम स्पष्ट और अधिक कष्टप्रद है। मुझे @JeffBezanson का प्रस्ताव सबसे अच्छा लगता है। के कुछ हिस्सों हैं base या test अधिक प्रभावी ढंग से उपयोग करते हुए लिखा जा सकता है fill के बजाय ones कि अभी कुछ भी नहीं रोक रहा है।

@carlobaldassi हालांकि यह सच है, एक त्वरित गिटहब खोज से पता चलता है कि मध्यवर्ती आवंटन से बचने के लिए ones लगभग सभी उपयोग वास्तव में fill का उपयोग करना चाहिए ...

इन मामलों के लिए fill का उपयोग करना मुझे समझ में आता है। ध्यान दें कि हम ones आदि की संबंधित विधियों को बदलने के लिए एक नई fill(x, A) = fill!(x, copymutable(A)) विधि चाहते हैं।

@TotalVerb उस खोज के पहले 10 पृष्ठों पर एक त्वरित स्किम से, मैं यह नहीं कहूंगा कि "लगभग सभी" एक उचित मूल्यांकन है। एक "महत्वपूर्ण अंश", सबसे अच्छा। वहां ones लिए बहुत सारे वैध उपयोग के मामले हैं, शायद बहुमत भी (और यहां तक ​​​​कि अगर वे सिर्फ 20% कहते हैं तो मुझे लगता है कि मेरा तर्क अभी भी खड़ा है)।

(मैं भी वास्तव में पठनीयता बहस के बारे में आरक्षण है, मुझे लगता है कि यह दावा करने के लिए संदिग्ध है कि जैसे fill(2, 2, 2, 2) की तुलना में अधिक पठनीय है 2 * ones(Int, 2, 2, 2) , या कि, कहते हैं, fill(k * 1.0, 3) अधिक होगा k * ones(3) से पठनीय; मैं बिल्कुल भी आश्वस्त नहीं हूं कि यह केवल आदत की बात है। हालांकि यह एक छोटी सी बात है।)

ट्रू/फॉल्स को फिल द्वारा सीधे बदला नहीं जा सकता है, लेकिन फिल का उपयोग करने की आवश्यकता है! बिटअरे प्रारंभकर्ता के साथ। वे एक और एक इकाई के बीच अस्पष्टता में भी शामिल नहीं हैं। इसलिए मुझे नहीं लगता कि वे इस चर्चा में बिल्कुल भी फिट बैठते हैं।

वास्तव में, trues और falses सीधे fill :) से बदलने योग्य नहीं हैं। इसके बजाय, trues और falses ऊपर वर्णित सामान्य समस्या के अतिरिक्त उदाहरण हैं / #11557 से संबंधित हैं (और सरणी कंस्ट्रक्टरों की हालिया दिशा उम्मीद से निपटेगी)। अन्य उदाहरणों में शामिल हैं जैसे bones , bzeros , brand , brandn , और beye BandedMatrices.jl में और समकक्षों के साथ a d DistributedArrays.jl में उपसर्ग।

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

आधार में ones कुछ सौ उपयोगों को फिर से लिखने के बाद, मैं @TotalVerb के कथन की पुष्टि कर सकता हूं

एक त्वरित गिटहब खोज से पता चलता है कि मध्यवर्ती आवंटन से बचने के लिए लगभग सभी उपयोगों को वास्तव में भरने का उपयोग करना चाहिए ...

(संपादित करें: हालांकि मैं लगभग सभी के बजाय लगभग आधा कहूंगा, और उपयुक्त पुनर्लेखन fill अलावा कुछ और हो सकता है।) इसके अलावा, उस पुनर्लेखन अनुभव ने मुझे सिखाया है ...

लेकिन क्या होगा जब आप वास्तव में लोगों की एक सरणी चाहते हैं? फिर भरण का उपयोग करना लंबा, कम स्पष्ट और अधिक कष्टप्रद होता है।

... दूसरी ओर, उस मामले में fill अक्सर छोटा और सरल होता है: अनुरोधित लोग अक्सर Float64 नहीं होते हैं (इसके बजाय ones(Int, n...) और ones(Complex{Float64}, n...) ), जिस स्थिति में fill एक शाब्दिक (जैसे fill(1, n...) और fill(1.0 + 0im, n...) ) को स्वीकार करके छोटा और सरल है। मापने योग्य शब्दों में, जिस शाखा में मैं आधार में ones कॉल फिर से लिख रहा हूं, वह ones -> fill पुनर्लेखन से वर्ण गणना से ~5% कम है। श्रेष्ठ!

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

विश्लेषण में 156 ones कॉल शामिल थे। उन कॉलों में से,

• 84 कॉल (~54%) तदर्थ fill एस थे। (उदाहरण के लिए, ones(100)/sqrt(100)*7 सरलीकृत होकर fill(7/sqrt(100), 100) या, बेहतर अभी तक, fill(.7, 100) । मेरा पसंदीदा kron(0.997, ones(1, J*J*s) -> fill(0.997, 1, J*J*s) ।)

• 3 कॉल (~2%) तदर्थ प्रसारण थे। (उदाहरण के लिए, A - ones(n,n) A .- 1. को सरल करता है।)

• 5 कॉल (~3%) तदर्थ सदिश शाब्दिक थे। (उदाहरण के लिए, ones(1) सरलीकृत होकर [1.] ।)

• 1 कॉल (~ 0.5%) शब्दार्थ रूप से एक जंक मैट्रिक्स निर्माण था। (हालांकि जंगली में अपेक्षाकृत असामान्य है, यह पैटर्न test/ में काफी सामान्य है क्योंकि हमारे पास अप्रारंभीकृत Array s के लिए संक्षिप्त सुविधा निर्माता नहीं है, उदाहरण के लिए <strong i="32">@test_throws</strong> DimensionMismatch BLAS.trsv(...,Vector{elty}(n+1)) बनाम <strong i="34">@test_throws</strong> DimensionMismatch BLAS.trsv(...,ones(elty,n+1)) ।)

शेष कॉल ones रूप में अर्थपूर्ण रूप से उचित थे, हालांकि अक्सर ones उपयोग केवल इसलिए देखा जाता है क्योंकि यह छोटा है, बजाय इसके कि one विशेष रूप से आवश्यक हैं। उन शेष कॉलों में से,

• 13 कॉल (~8%) fill जितनी छोटी थीं। (उदाहरण के लिए, ones(Int, n, n) -> fill(1, n, n) या ones(Float64, n) -> fill(1., n) ।)

• 50 कॉल (~32%) fill जितनी लंबी थीं। (उदाहरण के लिए, ones(n, n) -> fill(1., n, n) ।)

कुल मिलाकर, जंगली ~ ones कॉलों में से 60% किसी और तरह से बेहतर तरीके से लिखे गए हैं, ~ 8% शब्दार्थ रूप से ones और fill रूप में थोड़े छोटे हैं, और ~32% हैं यथोचित रूप से ones और fill रूप में थोड़ा लंबा।

एक अतिरिक्त अवलोकन:

मुझे एक सरणी तर्क स्वीकार करने वाले ones कॉल के केवल एक उदाहरण का सामना करना पड़ा, और यह स्पष्ट नहीं था कि संलग्न स्निपेट वास्तविक कोड था या नहीं। तो ones सरणी तर्क को स्वीकार करने वाली विधियां जंगली में कोई उपयोग होने पर बहुत कम दिखती हैं।

वास्तव में दिलचस्प चर्चा ... विपरीत पक्ष से पक्ष की ओर से चली गई ... साथ ही एक अन्य भाषा मिसाल के रूप में, R rep और matrix का उपयोग इस तरह से करता है जो fill बराबर है

वाह, उस प्रयास में डालने के लिए @ Sacha0 धन्यवाद!

प्रश्न स्वाभाविक रूप से " zeros बारे में क्या" उठता है? मैं अनुमान लगा रहा हूं कि काफी अधिक उपयोग होगा, और उपयोग की कुछ और श्रेणियां ("मुझे बस अप्रारंभीकृत सरणियों पर भरोसा नहीं है" या "मुझे नहीं पता कि Array कंस्ट्रक्टर्स का उपयोग कैसे करें ")।

जो भी कारण (मुझे लगता है कि इसके बारे में समरूपता है one और zero ), मैं कुछ हद तक या तो दोनों जगह की ओर आकर्षित कर रहा हूँ ones और zeros के साथ fill , या न ही।

शून्य के साथ बात यह है कि आप इनमें से किसी एक स्थिति में प्रतीत होंगे:

1. आपको अधिकांश शून्यों को अधिलेखित करने की आवश्यकता है - इस मामले में आप एक समझ का उपयोग करना बेहतर समझते हैं;
2. आपको अधिकांश शून्य को बदलने की आवश्यकता नहीं है - इस मामले में आप एक विरल मैट्रिक्स का उपयोग करना बेहतर समझते हैं;
3. आपको वास्तव में एक पूर्ण-शून्य मैट्रिक्स की आवश्यकता है - इस मामले में आप 0I का उपयोग करना बेहतर समझते हैं।

वास्तव में कोई उपयोग मामला नहीं है जहां वास्तव में घने शून्य के मैट्रिक्स को आवंटित करना वास्तव में एक अच्छा विचार है।

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

पर्याप्त रूप से - कभी-कभी आप घनत्व की परवाह नहीं करते हैं और सादगी इसके लायक है।

ट्राइएज: हमने संकल्प लिया कि हम केवल पूरी तरह से गैर-सामान्य तरीके यानी zeros(dims...) और ones(dims...) और शायद zeros(dims) और ones(dims) भी रखते हैं।

@StefanKarpinski उपयोग की सिफारिशों के लिए इसका मतलब है कि हम सामान्य कोड के लिए zeros(3, 3) से अधिक fill(0.0, 3, 3) की सिफारिश करेंगे (जब एक घने सरणी आदि आदि की आवश्यकता होती है)? दक्षता आदि के कुछ विवरण मेरी पहुंच से बाहर हैं, मैं बस यही सोच रहा हूं कि मैं जूलिया को आगे बढ़ते हुए सर्वोत्तम/मुहावरेदार प्रथाओं को कैसे सिखाऊंगा।

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

ट्राइएज: संकल्प किया कि हम केवल पूरी तरह से गैर-सामान्य तरीके रखते हैं

पीछे क्या तर्क है?

इसके अलावा, क्या यह मुद्दा किसी तरह सरणियों के निर्माण की सामान्य समस्या से संबंधित है, जिस पर अभी विचार किया जा रहा है, और यदि हां, तो यह कैसे मदद करता है? या, क्या हम निर्यात की गई विधियों की संख्या को Base से कम करने का प्रयास कर रहे हैं? (या कुछ और पूरी तरह से?)

https://github.com/JuliaLang/julia/issues/24595 :) में आगामी लेखन। श्रेष्ठ!

24595 के ओपी ने इस मुद्दे के व्यापक संदर्भ को विस्तृत किया, और अब #24595 में एक फॉलोअप विशेष रूप से सुविधा निर्माणकर्ताओं को संबोधित करता है ones , zeros , और fill गहराई में। पूर्व को पढ़ना बाद की सराहना करने में मूल्यवान है। श्रेष्ठ!

खैर, कम से कम Float64 मामले को सहेजना कुछ नहीं से बेहतर है।
मेरा मानना ​​​​है कि पूर्णांक शून्य का मामला भी काफी प्रासंगिक है, जो - मुझे लगता है - मूल रूप से वह बिंदु है जो @vtjnash यहां बना रहा था।

यह भी ध्यान दिया जाना चाहिए कि zeros में 3 * ones(n) विरोधी पैटर्न की अनुमति देने की "समस्या" नहीं है। वास्तव में, मैं वास्तव में नहीं देखता कि सुविधा निर्माता होने के व्यापक अर्थों को छोड़कर, ones और zeros को एक साथ क्यों जाना चाहिए। उन दोनों के बीच कोई वास्तविक 'समरूपता' नहीं है।

सांख्यिकीय विश्लेषण पर कुछ अतिरिक्त टिप्पणियाँ, क्योंकि यह निम्नलिखित चर्चाओं और #24595 के लेखन का आधार प्रतीत होता है। सबसे पहले, दस पृष्ठ वास्तव में जंगली में क्या हो रहा है, इसके सूक्ष्म निष्कर्ष के लिए पर्याप्त नहीं हैं, वे सबसे अच्छा एक मोटा विचार दे सकते हैं। कुछ फ़ाइलें सीधे matlab से आई हैं, उदाहरण के लिए, जैसा कि उनके नाम/शैली से स्पष्ट है। दूसरे, जैसा कि मुझे संदेह था, यहां तक ​​कि उस विश्लेषण से पता चलता है कि वहां ones लगभग आधे उपयोग "वैध" थे। तीसरा, इस तरह के कोड को देखने से इस बारे में कुछ नहीं पता चलता है कि 3 * ones(...) लिखते समय वास्तव में एक विरोधी पैटर्न है जो प्रदर्शन के मुद्दों को बनाता है, या यह कोड का एक टुकड़ा है जिसका कोई प्रदर्शन प्रभाव नहीं है (और लेखक हो सकता है तय किया है कि यह इस तरह से और अधिक पठनीय लिखा गया है - जो मुझे दृढ़ता से लगता है कि उस मामले में अन्यथा निर्णय लेने के लिए किसी और का व्यवसाय नहीं है)।

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

के बारे में

मेरा मानना ​​​​है कि पूर्णांक शून्य का मामला भी काफी प्रासंगिक है, जो - मुझे लगता है - मूल रूप से वह बिंदु है जो @vtjnash यहां बना रहा था।

जो संदर्भित करता है

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

ध्यान दें कि fill उस मामले में भी बेहतर या बेहतर कार्य करता है: fill(0, shape...) बनाम zeros(Int, shape...) ।

आपके अन्य बिंदुओं के संबंध में, #24595 पढ़ने योग्य हो सकता है :)। श्रेष्ठ!

मैं बस लगता है कि zeros(Int, 10, 10) अधिक पठनीय / से स्पष्ट है fill(0, 10, 10) , और zeros(T, k) तुलना में बेहतर है fill(zero(T), k) । हम दोनों ही क्यों नहीं हो सकते? मैं इस तर्क को नहीं खरीदता कि zeros समान अस्पष्टता समस्या से ग्रस्त है ones ।

आपके अन्य बिंदुओं के संबंध में, #24595 पढ़ने योग्य हो सकता है

मैंने इसे पढ़ा था। (मैंने इसे लिंक भी किया था।)

मैंने इसे पढ़ा था। (मैंने इसे लिंक भी किया था।)

#24595 को पूर्ण रूप से पढ़ने और उस पर उचित विचार करने के बाद, आप जानते हैं कि #24595: (1) एक बहुत व्यापक मुद्दे से संबंधित है जिसमें सुविधा निर्माता केवल एक हिस्सा हैं; और (2) केवल ऊपर पोस्ट किए गए सांख्यिकीय विश्लेषण और उन बिंदुओं से कहीं अधिक पर विचार करता है जिन पर आप ध्यान केंद्रित करते हैं।

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

क्या zeros परिवर्तन के साथ एक सामान्य fill आवक है? zeros का जेनेरिक प्रोग्रामिंग के लिए एक बहुत ही वैध उपयोग था क्योंकि यह similar से कहीं अधिक सुरक्षित है, इसलिए सभी DiffEq, और फिर मुझे पता है कि हाल ही में Optim और NLsolve similar साथ आवंटन से स्थानांतरित हो गए हैं zeros चूंकि यह जानने के बाद कि इसमें शून्य होने के लिए सब कुछ आवंटित किया गया है, बहुत सारे बग बंद हो जाते हैं। हालांकि, अब ऐसा लगता है कि इसके लिए कोई तरीका नहीं होगा:

zeros(X)

अब इसके अलावा:

similar(X); fill!(X,0)

क्योंकि वर्तमान fill केवल Array s बनाता है और इस प्रकार similar या zeros तरह टाइप-मैच नहीं करता है। मुझे पता है कि कुछ लोगों ने आवंटित करने के लिए zeros का दुरुपयोग किया जब उन्हें नहीं होना चाहिए था, लेकिन कई मामलों में zeros साथ आवंटन करना एक बहुत ही उचित बात है। मुझे उम्मीद है कि इस शून्य को भरने के लिए fill(0,X) शॉर्टहैंड जोड़ा जाएगा।

विचारशील पोस्ट क्रिस के लिए बहुत धन्यवाद! :) एक अंतरिम आशुलिपि प्रतिस्थापन के रूप में, zero(X) चाल चलता है?

ध्यान दें कि इस तरह के उपयोग के मामलों ठीक कर रहे हैं, जहां में अस्पष्टता zeros और ones समस्याग्रस्त किया जा सकता है: क्या zeros(X) उपज एक साथ वस्तु eltype(X) और से भरा eltype(X) की योगात्मक पहचान (यानी fill!(similar(X), 0) ), या इसके बजाय eltype(X) (संभवतः eltype(X) ) के लिए गुणक शून्य से भरी हुई वस्तु? (विस्तार के लिए #24595 देखें।)

fill(0, X) अवधारणा #11557 में कुछ चर्चा को देखती है, और मैं सहमत हूं कि यह fill एक उपयोगी सामान्यीकरण हो सकता है। धन्यवाद और उत्तम!

दूसरी समस्या यह है कि अपरंपरागत सूचकांक वाले सरणियाँ zeros(inds...) जैसी किसी चीज़ के साथ बनाई जा सकती हैं (क्योंकि अनुक्रमणिका प्रकार सरणी प्रकार निर्धारित करता है )। लेकिन 1-डी मामले के लिए, X "वह सरणी जिसे आप समान होना चाहते हैं" या "वांछित सरणी के लिए सूचकांक" है? (आखिरकार, AbstractUnitRange <: AbstractArray ।) वास्तव में, क्या zeros(3:5) अर्थ fill!(similar(3:5), 0) या fill!(OffsetArray(Vector{Float64}(3), 3:5), 0) ?

लिंकिंग https://github.com/JuliaLang/julia/pull/24656 , जिसमें {ones|zeros }(A::AbstractArray, ...) सुविधा निर्माणकर्ताओं की अतिरिक्त चर्चा शामिल है। श्रेष्ठ!

मुझे आश्चर्य है कि #24656 के अनुसार कैश वैरिएबल बनाने के लिए zeros का उपयोग करना अजीब माना जाता है। मुझे लगता है कि, अगर zeros को शून्य ओवरहेड के करीब कम कर दिया गया था, तो लगभग कोई भी मामला जहां लोग similar का उपयोग कर रहे हैं, इसके बजाय zeros होना चाहिए क्योंकि इससे काफी कुछ ठीक हो जाता है कीड़े मुझे लगता है कि हमें और अधिक लोगों को ऐसा करने के लिए प्रोत्साहित करना चाहिए क्योंकि similar काफी असुरक्षित हो सकता है, और कोई फ़ंक्शन नहीं है और इसके बजाय fill! + similar को एक साथ खींचने से यह कम स्पष्ट हो जाता है कि लोगों को क्या करना चाहिए। Optim.jl में इस पॉप अप के बारे में यहाँ एक टिप्पणी है:

https://github.com/JuliaNLSolvers/NLsolve.jl/issues/89#issuecomment -294585960

हालांकि, मैं @timholy से सहमत

https://github.com/JuliaDiffEq/MultiScaleArrays.jl

MultiScaleArrays.jl ने अमूर्त सरणियाँ बनाईं जो पुनरावर्ती ग्राफ़-जैसी संरचनाएँ हैं जिनका उपयोग भिन्न सॉल्वरों में किया जा सकता है (और मुझे लगता है कि यह अब Optim.jl और NLsolve.jl के साथ संगत हो सकता है?)। अन्य चीजों के अलावा जैविक मॉडल के लिए यह एक अच्छी सुविधा है। जब हम इसे ओडीई सॉल्वर में फेंकते हैं तो एक प्रश्न होता है: हमें कैश एरे क्या बनाना चाहिए? कुछ मामलों में यह मायने रखता है कि उपयोगकर्ता को वह सरणी वापस मिल जाती है जो वे चाहते थे क्योंकि यह उनके ODE फ़ंक्शन f(t,u,du) और वे उसी के अनुसार इसका इलाज करना चाहेंगे। हालांकि, अन्य मामलों में यह केवल कुछ ऐसी चीज के रूप में दिखाई देता है जिसके खिलाफ आंतरिक रूप से प्रसारित किया जाता है। तो दो अलग-अलग प्रकार के कैश चर हैं।

इसे संभालने के लिए, किसी एक एल्गोरिदम के कैशे पर एक नज़र डालें:

https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/caches/low_order_rk_caches.jl#L224 -L234

यहां, rate_prototype = similar(u,first(u)/t,indices(u) समान है लेकिन इकाइयों के लिए संभावित रूप से भिन्न eltype के साथ है। लेकिन ध्यान दें कि यहां दो अलग-अलग प्रकार हैं: similar(u) बनाम similar(u,indices(u)) । मैंने उन लोगों का अर्थ "प्रकार और आकार से मेल खाने" बनाम "आकार और eltype से मेल खाने के लिए किया है, लेकिन एक ही प्रकार होने की आवश्यकता नहीं है"। तो AbstractMultiScaleArray , पहला एक और AbstractMultiScaleArray बनाएगा, जबकि दूसरा, गति के लिए, क्योंकि यह उपयोगकर्ता द्वारा नहीं देखा जाता है, बस उपयुक्त का Array बना देगा आकार। इसके बाद इसे similar(u,T) और similar(u,T,indices(u)) तक बढ़ा दिया जाता है।

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

ध्यान दें कि ये similar का उपयोग कर रहे हैं क्योंकि मैं इसके zeros संस्करण के साथ आने के लिए बहुत आलसी था। मेरे पास वास्तव में एक अलग जगह है जो इनमें से कुछ सरणियों को शून्य कर सकती है क्योंकि यदि उपयोगकर्ता केवल du को अपने f(t,u,du) व्युत्पन्न गणना में सेट करता है, तो वे निहित रूप से बात करते हैं "जो मैं सेट नहीं करता हूं उसका मतलब है शून्य", जो केवल तभी सत्य है जब इसे zeros साथ आवंटित किया गया था, इसलिए मैं जितना संभव हो सके zeros का उपयोग करके पूर्व-आवंटन करने का प्रयास करता हूं (एक ही मुद्दा इसके लिए NLsolve.jl में आता है) .

उम्मीद है कि स्पष्टीकरण का पालन करने के लिए बहुत भ्रमित नहीं था। मेरे सभी मामलों में मैं बस similar बाद fill! स्विच कर सकता हूं, लेकिन मुझे पता है कि कुछ पैकेज नहीं होंगे और यह बग का स्रोत होगा।

दिलचस्प। आप सही कह रहे हैं कि similar(A, inds) similar(A) तुलना में एक अलग प्रकार बना सकता है, लेकिन सामान्य तौर पर मैंने हमेशा एक ही प्रकार को बनाने की संभावना के बारे में सोचा है लेकिन विभिन्न सूचकांकों के साथ। उदाहरण के लिए, यदि आपको 2-डी ऑब्जेक्ट पर कॉलमवाइज ऑपरेशन के लिए 1-आयामी कैश की आवश्यकता है, तो मैं similar(A, first(inds)) उपयोग करूंगा। (क्योंकि आयामी स्वरूप एक प्रकार पैरामीटर है बेशक यह एक अलग प्रकार का है, लेकिन यह एक ही सार कंटेनर प्रकार हो सकता है।) तुम भी एक छोटे से टाइल, आदि की एक 5x5 कैश बनाने के लिए इसका इस्तेमाल कर सकते हैं

कुल मिलाकर यह एक चुनौतीपूर्ण समस्या प्रतीत होती है। खेल में थोड़ी देर हो चुकी है, लेकिन क्या हमें same पेश करना चाहिए? इसमें similar के समान तर्क हो सकते हैं, लेकिन अनुबंध यह होगा कि इसे उसी सार कंटेनर को वापस करने की आवश्यकता होगी।

मैं same एक-तर्क के रूप का समर्थन कर सकता था, लेकिन यह भी मुश्किल है - ध्यान दें कि same(a) उसी सरणी प्रकार को वापस नहीं कर सका यदि a setindex! समर्थन नहीं करता है same और similar केवल तभी उपयोगी होते हैं जब आप बाद में सरणी में लिखने जा रहे हों। हम इसे अपरिवर्तनीय a लिए एक त्रुटि बना सकते हैं, लेकिन AbstractArray लिए एक इंटरफ़ेस के रूप में यह सही, सामान्य कोड बनाने के लिए अनावश्यक (और शायद अनुपयोगी) लगता है।

इसी तरह, हम यह नहीं मान सकते कि प्रत्येक AbstractArray अलग-अलग eltypes या सूचकांकों का समर्थन कर सकता है। मेरे लिए, same दो या तीन-तर्क रूप होने से लोगों को सुरक्षा की झूठी भावना देते हुए स्थानों के समूह में रन-टाइम त्रुटियां पेश की जाएंगी कि उनका सामान्य कोड किसी भी AbstractArray लिए अच्छा काम करेगा

लेकिन 1-डी मामले के लिए, एक्स "वह सरणी है जिसे आप समान होना चाहते हैं" या "वांछित सरणी के लिए सूचकांक"?

यह एक और कारण है कि मैं keys समान सूचकांकों और मूल्यों के साथ एक कंटेनर वापस करने के पक्ष में हूं, और फिर इसे similar की आवश्यकता बना रहा हूं (जब तक कि आप एक (कुछ) पूर्णांक प्रदान नहीं करते हैं कौन सा मामला Base.OneTo (कार्टेशियन रेंज) माना जाता है)।

यह चर्चा #18161 की ओर बढ़ रही है, और शायद वहीं जारी रहनी चाहिए :)।

सबसे हालिया ट्राइएज सिर्फ ones रखने की ओर झुक रहा था।

क्या उन्हें रखने में दुख होता है? मुझे लगता है कि यह उन लोगों की मदद करता है जो जूलिया में घर पर सुन्न महसूस करते हैं।

बंद होने के बाद से हम ones और zeros रख रहे हैं।