Julia: प्रसारण का एक काम था (उदाहरण के लिए इटरेटर और जनरेटर पर प्रसारण)

यह जानबूझकर है। broadcast आकार वाले कंटेनरों के लिए है, और वस्तुओं को स्केलर के रूप में मानने के लिए डिफ़ॉल्ट है। map आकार के बिना कंटेनरों के लिए है, और वस्तुओं को पुनरावृत्त के रूप में मानने के लिए डिफ़ॉल्ट है।

उदाहरण के लिए, broadcast स्ट्रिंग्स को "स्केलर" के रूप में मानता है, जबकि map वर्णों पर पुनरावृति करता है।

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

साथ ही, जैसा कि @stevengj ने पहले बताया है: map और broadcast बीच अंतर होना चाहिए, यदि नहीं, तो दोनों होने का क्या मतलब है।

@stevengj लेकिन Iterators का आकार होता है (विशेषकर जनरेटर) http://docs.julialang.org/en/release-0.5/manual/interfaces/#interfaces

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

@pabloferz map और broadcast बीच मुख्य अंतर स्केलर का उपचार है। अब अदिश की परिभाषा बहस का विषय है और मैं कहूंगा कि हर चीज जिसमें length(x) > 1 उसे अदिश नहीं माना जाना चाहिए।

फ़ंक्शन कॉल के बजाय, कौन से तर्कों को चलने योग्य माना जाना चाहिए, यह चिह्नित करना अस्पष्टता को हटा देगा। मुझे लगता है?

broadcast (मैं सामान्य रूप से भी मानता हूं) के लिए आकार होने का अर्थ है size (न कि केवल length ) और अनुक्रमित होना। टुपल्स के अलावा size बिना कुछ भी स्केलर के रूप में माना जाता है। वर्तमान कार्यान्वयन को देखते हुए आपको सबसे पहले getindex या उस वस्तु के लिए एक को परिभाषित करने में सक्षम होना चाहिए जिसे आप प्रसारित करना चाहते हैं। पुनरावृत्तियों के लिए, यह सामान्य रूप से संभव नहीं है।

मैं भी इसमें भाग गया। # 16769 से आ रहा है, जहां मैं fill! एक सरणी के लिए एक फ़ंक्शन के बार-बार मूल्यांकन (एक निश्चित मान के बजाय) के साथ एक रास्ता ढूंढता हूं, मैंने सोचा कि डॉट-सिंटैक्स पहले से ही चाल कर सकता है। लेकिन, जब a = zeros(2, 3); a .= [rand() for i=1:2, j=1:3] काम करता है, तो (होगा) सस्ता a .= (rand() for i=1:2, j=1:3) नहीं होगा; यह जनरेटर है HasShape() , लेकिन वास्तव में कोई अनुक्रमण क्षमता नहीं है। ब्रॉडकास्ट/डॉट-सिंटैक्स कैसे काम करता है, इसकी समझ में मैं बहुत हल्का हूं, लेकिन क्या यह यहां इंडेक्सिंग क्षमताओं के लिए एक विशेषता रखने में मदद करेगा? उसके लिए पहले से ही एक पीआर (#22489) है...

@rfourquet , आप a = zeros(2, 3); a .= rand.() कर सकते हैं

हां, लेकिन मुझे और सटीक होना चाहिए था: मैं एक ऐसे फ़ंक्शन का उपयोग करना चाहता हूं जो इंडेक्स को पैरामीटर के रूप में प्राप्त करता है, जैसे a .= (f(i, j) for i=1:2, j=1:3) ।

HasShape पुनरावृत्तियों के प्रसारण आयामों की क्या कमियां होंगी? ऐसा करना स्वाभाविक लगता है।

@nalimilan , पहली नज़र में मुझे लगता है कि यह उचित और शायद लागू करने के लिए अपेक्षाकृत आसान होगा। तोड़ रहा होगा इसलिए 1.0 तक किया जाना चाहिए।

इसके साथ एक संभावित समस्या यह है कि HasShape इटरेटर आवश्यक रूप से getindex समर्थन नहीं करते हैं, और इससे इसे लागू करना मुश्किल हो सकता है?

एक संभावना अस्थायी रूप से (1.0 के लिए) सरल कार्यान्वयन करना होगा जिसे अभी एक सरणी में कॉपी किया गया है। यह एक अनुकूलन पोस्ट 1.0 . की अनुमति देगा

इसके साथ एक संभावित समस्या यह है कि हैशैप इटरेटर्स गेटइंडेक्स का जरूरी समर्थन नहीं करते हैं, और इससे इसे लागू करना मुश्किल हो सकता है?

जैसा कि मैंने ऊपर कहा, मेरे पास #22489 पर एक पीआर है जो पुनरावृत्तियों में अनुक्रमण की अनुमति देता है, अगर यह मदद कर सकता है।

1.0 के लिए क्या करने की आवश्यकता है ताकि कम से कम हम 1.x में व्यवहार में सुधार कर सकें?

धन्यवाद @nalimilan इसे लाने के लिए, मैं भी ऐसा करना चाहता था। अगर ब्रॉडकास्ट एक्सप्रेशन के दाईं ओर HasShape जेनरेटर की अनुमति देना 1.0 के लिए लागू करना संभव नहीं है, तो क्या हमें जेनरेटर को स्केलर के रूप में मानने के बजाय अब इसे एक त्रुटि बनाना चाहिए? ताकि इसे 1.x में सक्षम किया जा सके।

:+1: ट्राइएज इसे एक त्रुटि (सुरक्षित विकल्प) बनाने या उस पर collect पर कॉल करने की सलाह देता है (यदि करना आसान है)।

map अपने सभी तर्कों को कंटेनर के रूप में मानता है, और उन सभी पर पुनरावृति करने का प्रयास करता है। मेरी आदर्श दुनिया में, broadcast समान होगा, और इसके सभी तर्कों के आकार को प्रसारित किया जा सकता है, और एक त्रुटि दें यदि उदाहरण के लिए size परिभाषित नहीं है। मैं बताऊंगा कि किसी भी मूल्य को fill साथ लपेटकर प्रसारण में एक स्केलर के रूप में माना जा सकता है, जो 0-डी सरणी प्रदान करता है:

julia> fill("a")
0-dimensional Array{String,0}:
"a"

julia> fill([2])
0-dimensional Array{Array{Int64,1},0}:
[2]

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

यह देखते हुए कि हम या तो किसी भी चलने योग्य का समर्थन कैसे कर सकते हैं, या जब तक हम उनका समर्थन नहीं करते हैं, तब तक उनके लिए एक त्रुटि फेंक दें, ऐसा लगता है कि हमें BroadcastStyle में इटरेटर्स की पहचान करने के तरीके की आवश्यकता होगी। वर्तमान में यह संभव नहीं है, क्योंकि Base.iteratorsize HasLength जैसे स्केलर के लिए भी Symbol लौटाता है। हम एक Base.isiterable विशेषता पेश कर सकते हैं (जो अन्य चीजों के लिए उपयोगी हो सकती है), या Base.iteratorsize डिफ़ॉल्ट बना सकते हैं NotIterable (जो HasLength होने के रूप में भी समझ में आता है)

(भविष्य की चर्चा के लिए मुश्किल मामला: UniformScaling ।)

@timholy चूंकि आपने broadcast का रीडिज़ाइन किया है, कोई सुझाव?

@JeffBezanson , broadcast का पूरा बिंदु कंटेनरों से मेल खाने के लिए स्केलर को "प्रसारित" करने में सक्षम होना है, उदाहरण के लिए ["bug", "cow", "house"] .* "s" ----> ["bugs", "cows", "houses"] । यह मूल रूप से map के व्यवहार से अलग है।

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

उस पर कुछ उपयुक्त विधि को परिभाषित करके broadcast लिए एक विशेष प्रकार को कंटेनर घोषित करना संभव होना चाहिए, लेकिन मुझे लगता है कि वस्तुओं को स्केलर के रूप में व्यवहार करना जारी रखना चाहिए।

एक असंबंधित पीआर (https://github.com/JuliaLang/julia/pull/25339) में, @ केनो ने यह पता लगाने के लिए applicable(start, (x,)) का उपयोग करने का सुझाव दिया कि x चलने योग्य है या नहीं। क्या हमें यहां भी यही तरीका अपनाना चाहिए? मुझे इटरेटर्स की अधिक स्पष्ट परिभाषा (या तो Base.iteratorsize या एक विशेषता पर आधारित) होना स्पष्ट होगा, लेकिन start भी समझ में आता है।

हमारे पास एक स्पष्ट विशेषता हो सकती है जो डिफ़ॉल्ट रूप से applicable(start, (x,)) ; यदि आवश्यक हो तो इसे ओवरराइड करने की अनुमति देगा।

मैंने संभावित समाधानों और उनकी कमियों को स्पष्ट करने के लिए #25356 दायर किया है।

@stevengj के उदाहरण से ["bug", "cow", "house"] .* "s" ----> ["bugs", "cows", "houses"] , पुनरावृत्ति पर्याप्त प्रतीत नहीं होती है, क्योंकि तार चलने योग्य हैं लेकिन वहां स्केलर की तरह कार्य करते हैं। यदि आपको किसी विशेषता को वैसे भी परिभाषित करने की आवश्यकता है, तो सभी पुनरावृत्तियों के लिए आवश्यकताओं को जोड़ने के बजाय, प्रसारण के लिए ऑप्ट-इन की आवश्यकता को जारी रखना सबसे अच्छा हो सकता है।

सौभाग्य से keys(dict) अब एक AbstractSet लौटाता है, इसलिए यदि हम AbstractSet लिए एक प्रसारण विशेषता जोड़ते हैं तो यह ओपी में उदाहरण को ठीक कर देगा। हम कुछ सामान्य मामलों को पकड़ने के लिए Generator प्रसारण के लिए एक त्रुटि भी जोड़ सकते हैं।

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

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

हो सकता है कि उत्तर प्रसारित करने वाले (कोशिश करें) पुनरावृत्तियों के पास है HasShape , और बाकी सब कुछ स्केलर के रूप में व्यवहार करना जारी रखें? ओपी को ठीक नहीं करेगा, लेकिन अन्यथा बहुत सुंदर है।

अन्य यादृच्छिक विचार: शायद 1 तर्क (जैसे string.(x) ) पर प्रसारित करना एक विशेष मामला होना चाहिए जो map जैसा काम करता है, क्योंकि आकार संगतता कोई मुद्दा नहीं है?

हो सकता है कि इसका उत्तर हैशशैप वाले इटरेटर्स को प्रसारित करना (कोशिश करना) है, और बाकी सब कुछ स्केलर के रूप में व्यवहार करना जारी रखें? ओपी को ठीक नहीं करेगा, लेकिन अन्यथा बहुत सुंदर है।

मुझे यकीन नहीं है कि हमारे पास HasLength पुनरावृत्तियों को बाहर करने का एक मजबूत कारण है। हम टुपल्स पर प्रसारण का समर्थन करते हैं (जो size लागू नहीं करते हैं), तो क्यों न टुपल्स जैसे आकारहीन इटरेटर का इलाज किया जाए? उदाहरण के लिए, keys(::OrderedDict) साथ broadcast के परिणाम का उपयोग करने में सक्षम होने के लिए यह सही समझ में आता है। अगर हम इसका समर्थन नहीं करते हैं, तो लोग अपने इटरेटर्स को HasShape रूप में परिभाषित करने के लिए लुभाएंगे ताकि वे broadcast (और अच्छा डॉट सिंटैक्स) के साथ प्रयोग योग्य हो सकें।

स्टीव को उद्धृत करने के लिए,

broadcast आकार वाले कंटेनरों के लिए है

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

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

हो सकता है कि @stevengj विकसित हो सकता है कि वह क्यों सोचता है कि broadcast को केवल आकार वाले कंटेनरों का समर्थन करना चाहिए? क्या आप टुपल्स को स्केलर मानने का भी समर्थन करेंगे?

मुझे लगता है कि broadcast (#16986) में टुपल्स को कंटेनरों के रूप में व्यवहार करने का औचित्य यह था कि व्यवहार में उन्हें अक्सर अनिवार्य रूप से स्थिर वैक्टर के रूप में उपयोग किया जाता है, और उन्हें broadcast में "स्केलर" के रूप में व्यवहार करना बस नहीं था वैसे भी बहुत उपयोगी। इसके विपरीत, स्ट्रिंग्स (ए) को अक्सर स्ट्रिंग-प्रोसेसिंग संचालन के लिए "परमाणु" के रूप में माना जाता है और (बी) में सामान्य रूप से लगातार अनुक्रमण नहीं होता है, इसलिए वे broadcast ढांचे में बहुत खराब रूप से फिट होते हैं।

सिद्धांत रूप में, मैं समर्थन करेगा HasShape iterators में कंटेनर के रूप में इस्तेमाल किया जा रहा broadcast । मुख्य समस्या, जैसा कि मैंने ऊपर उल्लेख किया है, यह है कि HasShape होने की गारंटी नहीं है कि getindex काम करता है।

मुख्य समस्या, जैसा कि मैंने ऊपर उल्लेख किया है, यह है कि HasShape होने की गारंटी नहीं है कि getindex काम करता है

क्या #22489 कुछ मदद करेगा, यानी एक पुनरावर्तक विशेषता जो इंगित करती है कि एक पुनरावर्तक अनुक्रमित है या नहीं?

क्या #22489 कुछ मदद करेगा, यानी एक पुनरावर्तक विशेषता जो इंगित करती है कि एक पुनरावर्तक अनुक्रमित है या नहीं?

लेकिन तब केवल इंडेक्सेबल इटरेटर्स को broadcast साथ सपोर्ट किया जाएगा? यह बहुत प्रतिबंधात्मक लगता है, जैसा कि किसी भी चलने योग्य (उदाहरण के लिए keys(::OrderedDict) ) के लिए string.(itr, "1") जैसी चीजों को करने में सक्षम होने के लिए बहुत उपयोगी होगा, और इसे लागू करने के लिए अनुक्रमण की आवश्यकता नहीं है। मुझे लगता है कि हम उन सभी पुनरावृत्तियों के लिए एक त्रुटि फेंक देंगे जो 0.7/1.0 में अनुक्रमण का समर्थन नहीं करते हैं, और बाद के रिलीज में उनका समर्थन करने का प्रयास करते हैं। वैसे भी इटरेटर्स को स्केलर के रूप में व्यवहार करना बहुत उपयोगी नहीं है। फिर हम 1.x रिलीज में जो भी व्यवहार चाहते हैं उसे लागू कर सकते हैं।

@stevengj मैं स्ट्रिंग्स और HasLength इटरेटर्स को टुपल्स के रूप में क्यों नहीं मानना ​​​​चाहिए? मैंने अब तक इसका कोई औचित्य नहीं पढ़ा है।

@nalimilan , मुझे लगता है कि केवल इंडेक्सेबल + हैशैप इटरेटर्स को broadcast द्वारा समर्थित किया जाना चाहिए। इस फ़ंक्शन में सामान्य पुनरावृत्तियों को रटने की कोशिश करना इसके अर्थ को बहुत अधिक भ्रमित करता है - किसी बिंदु पर, आपको बस उपयोग करना चाहिए map ।

किसी भी चलने योग्य के लिए string.(itr, "1") चीजों को करने में सक्षम होने के लिए बहुत उपयोगी होगा ... वैसे भी इटरेटर्स को स्केलर के रूप में व्यवहार करना बहुत उपयोगी नहीं है।

स्ट्रिंग्स का मामला इसके विपरीत है - "1" तर्क स्वयं आपके उदाहरण में चलने योग्य है। बहुत सी चीजें चलने योग्य हैं (उदाहरण के लिए PyObject s PyCall में start आदि को परिभाषित करता है), जिसमें अनियंत्रित सेट जैसी चीजें शामिल हैं जहां broadcast अवधारणा वास्तव में टूट गई है।

यह भी ध्यान दें कि #24990 map को अब की तुलना में और भी आसान बना देगा, उदाहरण के लिए आप map(string(_,"1"), itr) कर पाएंगे।

@nalimilan , मुझे लगता है कि केवल अनुक्रमणीय + हैशैप इटरेटर प्रसारण द्वारा समर्थित होना चाहिए। इस फ़ंक्शन में सामान्य पुनरावृत्तियों को रटने की कोशिश करना इसके अर्थ को बहुत अधिक भ्रमित करता है - किसी बिंदु पर, आपको बस उपयोग करना चाहिए map.

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

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

(एफडब्ल्यूआईडब्ल्यू, PyObject मेरे लिए एक महान उदाहरण की तरह नहीं लगता है क्योंकि आईआईयूसी यह पुनरावृत्ति प्रोटोकॉल को लागू करता है क्योंकि यह पहले से नहीं जानता है कि यह पायथन इटरेटर को लपेटेगा या नहीं। PyObject स्पष्ट रूप से यहां एक अपवाद है, जैसे इसे मानक जूलिया ऑब्जेक्ट की तरह दिखने के लिए getfield ओवरलोडिंग का उपयोग करने की आवश्यकता है। सेट अधिक जूलियन उदाहरण हैं।)

हम अनुक्रमणीय HasShape पुनरावृत्तियों के लिए एक विशेषता जोड़ सकते हैं, जैसा कि कहीं और सुझाया गया है।

ट्राइएज को सभी तर्कों (जैसे मानचित्र) पर प्रसारण पुनरावृति बनाने का विचार पसंद है, और एक ऑपरेटर चरित्र जोड़ना (जैसे const & = Ref जैसा कि पहले किसी अन्य मुद्दे में प्रस्तावित किया गया था, या शायद ~ ) स्पष्ट रूप से चिह्नित करने के लिए 0-डी तर्क।

@vtjnash , गैर- HasShape पुनरावर्तक के लिए इसका क्या अर्थ है? क्या आपका मतलब है कि आप स्ट्रिंग्स और सेट जैसी चीज़ों पर पुनरावृति करने के लिए प्रसारण करना चाहते हैं? वर्तमान broadcast कार्यान्वयन getindex निकटता से जुड़ा हुआ है ... क्या आपने सोचा है कि आप इसे getindex बिना कैसे कार्यान्वित करेंगे, विशेष रूप से विभिन्न आयामों के तर्कों के संयोजन के लिए?

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

ऐसा लगता है कि पीआर https://github.com/JuliaLang/julia/pull/22489 से IteratorAccess विशेषता को इंडेक्सेबल इटरेटर्स का पता लगाने के लिए अनुकूलित/पुन: उपयोग किया जा सकता है। https://github.com/JuliaLang/julia/pull/24774 के लिए यह जानना भी आवश्यक है कि कौन से इटरेटर अनुक्रमित हैं (और इसलिए keys लागू करना चाहिए) ।

सीसी: @rfourquet

ट्राइएज इसे एक त्रुटि (सुरक्षित विकल्प) बनाने या इस पर कॉल करने (यदि करना आसान है) की सिफारिश करता है।

क्या ट्राइएज यहां अपनाने के लिए एक विशिष्ट रणनीति तय कर सकता है? उदाहरण के लिए ऊपर @JeffBezanson की टिप्पणी में "यह" क्या है? क्या हमें उन सभी इटरेटर्स के लिए त्रुटियां फेंकनी चाहिए जो इंडेक्सिंग का समर्थन नहीं करते हैं (अभी के लिए सबसे सुरक्षित विकल्प, ताकि हम बाद में कुछ भी कर सकें), या क्या हमें कुछ इटरेटर्स को स्केलर के रूप में मानना ​​​​चाहिए? क्या हमें इंडेक्सेबल इटरेटर्स के लिए एक विशेषता जोड़नी चाहिए, और यदि हां, तो किस रूप में (नई विशेषता बनाम नई पसंद Base.IteratorSize )? क्या हमें सामान्य रूप से इटरेटर के लिए एक विशेषता जोड़नी चाहिए (ताकि हम उन्हें स्केलर से अलग कर सकें)?

निम्नलिखित व्यवहार अच्छा लगता है:

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

क्या आप अंतिम बिंदु (शायद एक उदाहरण के साथ) पर नोट को स्पष्ट कर सकते हैं? मुझे यकीन नहीं है कि विशेषता के अस्तित्व के लिए इसका क्या अर्थ है लेकिन पुनरावृत्त बनाम पुनरावृत्ति के बीच चयन करने के लिए उपयोग नहीं किया जाता है।

तो मूल रूप से "हर तर्क को पुनरावृत्त और प्रसारित करने का प्रयास करें" का तात्पर्य है कि हमें सभी गैर-संग्रह प्रकारों के लिए Scalar() वापस करने के लिए BroadcastStyle को परिभाषित करने की आवश्यकता है (विशेष रूप से Number , Symbol और AbstractString )? ऐसा लगता है कि "लक्षण" आखिरी गोली का उल्लेख करता है।

ईमानदारी से, मुझे गैर-इंटरैबल्स/स्केलर के लिए एक विशेषता को परिभाषित करने की तुलना में पुनरावृत्तियों के लिए एक विशेषता को परिभाषित करना कम खर्चीला लगेगा। मुझे डर है कि सभी गैर-संग्रह प्रकार किसी बिंदु पर उस Scalar विशेषता को लागू करेंगे, क्योंकि यह कुछ (संभवतः दुर्लभ) मामलों में उपयोगी हो सकता है।

ऐसा लगता है कि "लक्षण" आखिरी गोली का उल्लेख करता है

नहीं, आखिरी बुलेट का मतलब है कि अगर कुछ पुनरावृत्ति लागू करता है, तो प्रसारण इसे पुनरावृत्त करता है - स्केलर विशेषता चली जाएगी। कुछ सामान्य रूप से गैर-पुनरावृत्तीय प्रकारों (जैसे Type और Function उपप्रकार) के लिए, तो हम एक NotIterable विशेषता चाहते हैं जो MethodError एक पुनरावृत्ति में जो एक मान (वह वस्तु) उत्पन्न करता है। मुझे वास्तव में याद नहीं है कि यह क्यों जरूरी था।

तो मूल रूप से "हर तर्क को फिर से प्रसारित करने और प्रसारित करने का प्रयास करें" का तात्पर्य है कि हमें सभी गैर-संग्रह प्रकारों (विशेष रूप से संख्या, प्रतीक और सारस्ट्रिंग) के लिए स्केलर() को वापस करने के लिए ब्रॉडकास्ट स्टाइल को परिभाषित करने की आवश्यकता है? ऐसा लगता है कि "लक्षण" आखिरी गोली का उल्लेख करता है।

नहीं, Number सभी अदिश उपप्रकार स्वयं को पुनरावृत्त करते हैं और इसलिए ठीक हैं। हमें इसे प्रतीक के लिए परिभाषित करने की आवश्यकता होगी। AbstractString एक संग्रह के रूप में काम करेगा।

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

मुझे अभी भी लगता है कि प्रसारण को केवल हैशैप इटरेटर्स को कंटेनर के रूप में मानना ​​​​चाहिए; यह शुरू से ही प्रसारण के डिजाइन के अनुरूप है। उसमे गलत क्या है?

इसके साथ समस्या ओपी में एक है; यदि आपके पास आकार के बिना एक पुनरावर्तक है, तो इसे एक स्केलर के रूप में मानना ​​​​एक पागल जवाब देता है।

साथ ही, मुझे प्रस्ताव के "लक्षण" भाग को छोड़ने में पूर्ण प्रसन्नता होगी। कोई शिकायत नहीं करता

julia> map(string, [1,2], :a)
ERROR: MethodError: no method matching start(::Symbol)

संभवतः ओपी में परिणाम अप्रत्याशित होने का कारण यह है कि कोई भी वास्तव में _all_ तर्कों को स्केलर के रूप में मानने के लिए प्रसारण कॉल का इरादा नहीं रखता है; यदि केवल एक तर्क है और इसे संग्रह/पुनरावर्तक के रूप में व्यवहार करने का कोई तरीका है जो लगभग निश्चित रूप से उपयोगकर्ता का इरादा रखता है। हालांकि निश्चित रूप से 1 .+ 1 को काम करना जारी रखना चाहिए?

यह मेरे साथ हुआ है, लेकिन यह एक तर्क को एक विशेष मामला बनाने के लिए भ्रमित करने वाला लगता है।

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

मुझे अभी भी लगता है कि प्रसारण को केवल हैशैप इटरेटर्स को कंटेनर के रूप में मानना ​​​​चाहिए; यह शुरू से ही प्रसारण के डिजाइन के अनुरूप है। उसमे गलत क्या है?

@stevengj क्या गलत IMHO है कि यह काम नहीं कुछ कार्यों में आता है जब एक पूरी तरह से उचित व्यवहार लागू किया जा सकता है: इलाज HasLength जैसे iterators Tuple , जो वर्तमान में है विशेष मामलों। यहां तक ​​कि अगर हम अभी उनका समर्थन नहीं करते हैं, तो मैं 1.x में किसी बिंदु पर उनका समर्थन करने की संभावना को खुला छोड़ना चाहता हूं।

कोई शिकायत नहीं करता

जूलिया> नक्शा (स्ट्रिंग, [1,2],: ए)
त्रुटि: MethodError: कोई विधि मिलान प्रारंभ नहीं (:: प्रतीक)

@JeffBezanson OTC, मैं broadcast के वर्तमान व्यवहार का समर्थन करता हूं, जो आवश्यकतानुसार :a दोहराता है। इस तरह की चीज बहुत उपयोगी हो सकती है जैसे DataFrame कॉलम की श्रृंखला का नाम बदलना। क्या आप broadcast को map जैसी त्रुटि फेंकने के लिए बदलने का सुझाव देते हैं?

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

यह आसान है, लेकिन काफी असुविधाजनक है। मैं @stevengj से सहमत स्केलर्स को डिफ़ॉल्ट रूप से प्रसारित किया जाना चाहिए, न कि कोई त्रुटि। बेशक Number प्रकार चलने योग्य हैं, झुंझलाहट हमेशा दिखाई नहीं देगी, लेकिन जैसा कि Symbol उदाहरण से पता चलता है कि यह सामान्य रूप से बहुत उपयोगी नहीं होगा। Char एक और होगा, और पैकेज में परिभाषित कई कस्टम प्रकार भी इससे पीड़ित होंगे (और अंत में उनके BroadcastStyle को Scalar() रूप में परिभाषित करेंगे)।

मुझे लगता है कि इस मुद्दे की जड़ यह है कि हमारे पास संग्रह को स्केलर से अलग करने की विशेषता नहीं है। तो सबसे सीधा समाधान वास्तव में HasShape पुनरावृत्तियों को संग्रह के रूप में, और अन्य प्रकारों को स्केलर के रूप में व्यवहार करना था ( HasLength पुनरावृत्तियों सहित, क्योंकि यह सभी प्रकार के लिए डिफ़ॉल्ट है)। व्यक्तिगत रूप से मुझे लगता है कि संग्रह/पुनरावृत्तियों के लिए एक विशेषता का परिचय देना बहुत मायने रखता है, लेकिन अगर हम ऐसा करने के लिए तैयार नहीं हैं और अगर हम start पर भरोसा नहीं कर सकते हैं, तो इसे पुनरावृत्तियों का पता लगाने के लिए परिभाषित किया जा सकता है, मैं हूं डर है कि हमें वर्तमान व्यवहार रखना होगा।

जेफ के प्रस्ताव में https://github.com/JuliaLang/julia/issues/18618#issuecomment -360594955 में Symbol और Char को "स्केलर" प्रकार के रूप में मानते हुए प्रसारण की अनुमति देने के लिए जगह है - वे बस व्यवहार में ऑप्ट-इन करने की आवश्यकता है। डिफ़ॉल्ट रूप से वे एक त्रुटि होगी, क्योंकि वे start लागू नहीं करते हैं।

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

हालाँकि, यहाँ एक मस्सा है। चूंकि संख्याएँ चलने योग्य हैं (वे HasShape ) भी हैं, उन्हें शून्य-आयामी कंटेनर के रूप में माना जाएगा। इसका मतलब है कि, अपने तार्किक निष्कर्ष पर ले जाया गया, 1 .+ 2 != 3 । इसके बजाय यह fill(3, ()) होगा।

संपादित करें: धागे को आगे बढ़ाने से बचने के प्रयास में, प्रवचन में चले गए:

https://discourse.julialang.org/t/lazycall-again-sorry/8629

# 18618 (टिप्पणी) में जेफ के प्रस्ताव में प्रतीक और चार को "स्केलर" प्रकार के रूप में प्रसारित करने की अनुमति देने के लिए जगह है - उन्हें केवल व्यवहार में ऑप्ट-इन करने की आवश्यकता है। डिफ़ॉल्ट रूप से वे एक त्रुटि होगी, क्योंकि वे प्रारंभ को लागू नहीं करते हैं।

हाँ, मेरी स्थिति सिर्फ इस धारणा पर आधारित है कि स्केलर एक अधिक प्राकृतिक फॉलबैक हैं, विशेष रूप से यह देखते हुए कि संग्रह को कुछ विधियों (पुनरावृत्ति, संभवतः अनुक्रमण) को लागू करने की आवश्यकता है, जबकि स्केलर केवल "बाकी" हैं और उनमें कुछ भी सामान्य नहीं है। अंत में कोई भी प्रकार किसी भी व्यवहार को लागू करने में सक्षम होगा, लेकिन हमें इसे यथासंभव सुविधाजनक और तार्किक बनाना चाहिए, जो विशेष रूप से विसंगतियों से बचने में मदद करनी चाहिए (उदाहरण के लिए कुछ प्रकार घोषित और स्केलर के रूप में व्यवहार करना और अन्य नहीं)।

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

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

• map को पुनरावृत्ति प्रोटोकॉल से दृढ़ता से जोड़ा जा सकता है - यह मान्य लगता है कि हम किसी भी मनमानी iterable लिए आलसी out = map(f, iterable) बना सकते हैं जैसे कि first(out) है f(first(iterable)) , और मुझे ऐसा लगता है कि यह सामान्य आलसी ऑपरेशन उपयोगी हो सकता है।
• broadcast को इंडेक्सिंग इंटरफ़ेस से मजबूती से जोड़ा जा सकता है - यह मान्य लगता है कि हम एक आलसी out = broadcast(f, indexable) जैसे कि out[i] f(indexable[i]) , और मुझे ऐसा लगता है कि यह सामान्य आलसी ऑपरेशन उपयोगी हो सकता है। जाहिर है broadcast कई इनपुट के साथ अभी भी वह सभी फैंसी सामान कर सकता है जो वह अब करता है। प्रसारण के उद्देश्य के लिए, स्केलर वे चीजें होंगी जिन्हें अनुक्रमित नहीं किया जा सकता है (या Number और Ref और AbstractArray{0} जैसे मामूली रूप से अनुक्रमणिका)।

मुझे यह भी लगता है कि यह वांछनीय होगा यदि एक-तर्क map और एक-तर्क broadcast संग्रह के लिए बहुत समान चीजें करते हैं जो पुनरावर्तनीय और अनुक्रमित दोनों हैं। हालांकि, तथ्य यह है कि AbstractDict पुनरावृत्ति getindex तुलना में अलग-अलग चीजें लौटाती है, ऐसा लगता है कि यहां एक अच्छा एकीकरण अवरुद्ध है। :frowning_face: (हमारे अन्य संग्रह प्रकार ठीक लगते हैं)

(मेरे लिए, तथ्य यह है कि स्ट्रिंग्स जैसी चीजों को स्पष्ट रूप से लपेटना पड़ सकता है जैसे ["bug", "cow", "house"] .* ("s",) यहां डील-ब्रेकर की तरह नहीं लगता है। मुझे एक ही समस्या है जब मैं 3-वेक्टर के बारे में सोचना चाहता हूं "एकल 3D बिंदु" होने के नाते और इससे निपटना बहुत कठिन नहीं है (xref #18379))।

मैं सहमत हूं कि broadcast इंडेक्सेबल कंटेनरों के लिए होना चाहिए, लेकिन मुझे लगता है कि यह लगातार इंडेक्सेबल होना चाहिए, जिसमें स्ट्रिंग्स शामिल नहीं हैं। उदाहरण के लिए collect(eachindex("aαb🐨γz")) [1, 2, 4, 5, 9, 11] , जो अनुक्रमण के आधार पर किसी भी broadcast कार्यान्वयन के साथ बुरी तरह से खेलेगा।

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

मुझे यकीन नहीं है कि लगातार सूचकांक एक अच्छी बाधा है - उदाहरण के लिए शब्दकोशों में मनमानी सूचकांक होंगे।

हालांकि, broadcast(f, ::String) एक नया String नहीं बना सकता है और गारंटी देता है कि आउटपुट इंडेक्स इनपुट इंडेक्स के समान ही रहेंगे क्योंकि यूटीएफ -8 कैरेक्टर चौड़ाई f तहत बदल सकती है ( उस गारंटी को बनाने के लिए इसे AbstractDict{Int, Char} तरह कुछ बदलना होगा, जो वास्तव में बहुत उपयोगी नहीं लगता है!) मैं लगभग यही कहूंगा कि एक String सूचकांक शब्दार्थ-महत्वपूर्ण सूचकांकों के बजाय तेजी से देखने के लिए "टोकन" की तरह हैं (उदाहरण के लिए आप एक समकक्ष यूटीएफ -32 स्ट्रिंग में कनवर्ट कर सकते हैं और सूचकांक बदल जाएंगे)।

अगर हम प्रसारण व्यवहार को विशेषता के माध्यम से ऑप्ट-इन करते हैं तो मुझे कोई आपत्ति नहीं है; मैं सिर्फ इतना कह रहा हूं कि कल्पना करना कि एक सामान्य broadcast(f, ::Any) व्यवहार करता है, broadcast(f, ::AbstractDict) जैसी चीजों के कार्यान्वयन का मार्गदर्शन करने का एक अच्छा तरीका है (और स्वाभाविक रूप से उस प्रश्न का उत्तर देगा जो मैंने # २५९०४ में उठाया था, अर्थात प्रसारण पर शब्दकोश मान और कुंजी-मूल्य जोड़े नहीं)।

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

मैं उन चीजों पर प्रसारित करता हूं जिन्हें स्केलर के रूप में माना जाना चाहिए _हर समय_।

वे चीजें किस प्रकार की हैं?

कुछ भी हो सकता है। उदाहरण के लिए, एक पैकेज में जो एक अनुकूलन मॉडल प्रकार Model और एक निर्णय चर प्रकार Variable को परिभाषित करता है, आपके पास x::Vector{Variable} हो सकता है जिसके लिए आप हल करने के बाद मान प्राप्त करना चाहते हैं मॉडल model फ़ंक्शन का उपयोग करके value(::Variable, ::Model)::Float64 । पहले, आप ऐसा कर सकते थे:

value.(x, model)

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

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

संक्षेप में, चार विकल्प हैं जो गलत फ़ॉलबैक से बचते हैं:

1. कुछ विधि को लागू करने के लिए _everything_ की आवश्यकता होती है जो वर्णन करती है कि वे कैसे प्रसारित करते हैं
2. चीजों को कंटेनर के रूप में मानने के लिए डिफ़ॉल्ट और गैर-कंटेनरों के लिए त्रुटि/बहिष्कार।
   
   
   
   • हम केवल iterate अज्ञात वस्तुओं की कोशिश करेंगे और यह स्केलर्स के लिए त्रुटि होगी
   
   
   • स्केलर्स के लिए दो एस्केप हैच हैं - उपयोगकर्ता उन्हें कॉल साइट पर लपेट सकते हैं और लाइब्रेरी लेखक अलिखित स्केलर-जैसे प्रसारण के लिए ऑप्ट-इन कर सकते हैं।
   
   
3. चीजों को अदिश के रूप में मानने के लिए डिफ़ॉल्ट और अज्ञात कंटेनरों के लिए त्रुटि
   
   
   
   • यह देखते हुए कि केवल स्केलर्स के लिए परिभाषित कोई प्रासंगिक विधियां नहीं हैं, हमें यह दावा करना होगा कि iterate एक विधि त्रुटि फेंकता है। यह धीमा और घुमावदार है।
   
   
   • कस्टम कंटेनर के लिए केवल एक एस्केप हैच उपलब्ध होगा ताकि त्रुटि न हो: उनके पुस्तकालय लेखक स्पष्ट रूप से प्रसारण के लिए ऑप्ट-इन करें। यह एक ऐसे फ़ंक्शन के लिए काफी पीछे की ओर लगता है जिसका प्राथमिक उद्देश्य कंटेनरों के साथ काम करना है।
   
   
4. applicable(iterate, …) जांचें और उसके अनुसार व्यवहार बदलें
   
   
   
   • यह वर्तमान में प्रारंभ/अगले/किए गए बहिष्करण तंत्र के कारण काम नहीं करता है, और आम तौर पर रैपर प्रकारों के लिए गलत हो सकता है जो किसी सदस्य को विधियों को स्थगित कर देता है।
   
   

विकल्प 1 सभी के लिए बदतर है, विकल्प 2 यथास्थिति है, और विकल्प 3 पीछे की ओर है, और विकल्प 4 कुछ ऐसा है जो हमने पहले कभी नहीं किया है और यह छोटी गाड़ी होने की संभावना है।

मुझे लगता है कि कुछ चर्चा पर्दे के पीछे हुई होगी, लेकिन मैं इस धागे में और https://github.com/JuliaLang/julia/pull/25356 में nalimilan खिलाफ देखे गए तर्कों से आश्वस्त नहीं हूं। stevengj की स्थिति।

कस्टम कंटेनर के लिए केवल एक एस्केप हैच उपलब्ध होगा ताकि त्रुटि न हो: उनके पुस्तकालय लेखक स्पष्ट रूप से प्रसारण के लिए ऑप्ट-इन करें। यह एक ऐसे फ़ंक्शन के लिए काफी पीछे की ओर लगता है जिसका प्राथमिक उद्देश्य कंटेनरों के साथ काम करना है।

यह मेरी असहमति का मुख्य बिंदु है। मेरे लिए ऐसा लगता है कि सभी जूलिया कोड में # of iterator types << # of types that should be treated as scalars in a broadcast situation < # of broadcast calls । तो मैं इसे पसंद करूंगा यदि प्रसारण कॉल की संख्या के बजाय, कुछ 'अतिरिक्त' को इटरेटर प्रकारों की संख्या के साथ स्केल करने की आवश्यकता होती है। और यदि कोई पुस्तकालय लेखक एक पुनरावर्तक को परिभाषित करता है, तो उनसे एक और विधि को परिभाषित करने के लिए कहना पूरी तरह से अनुचित नहीं है, जबकि यह _is_ पूरी तरह से अनुचित है कि प्रत्येक पैकेज लेखक को उनके सभी गैर-पुनरावृत्त प्रकारों के लिए Base.broadcastable(x) = Ref(x) को परिभाषित करने के लिए कहा जाए। broadcast कॉल के उच्च प्रतिशत में बदसूरत (IMHO) Ref s से बचें।

मुझे पता है कि पुनरावृत्ति को परिभाषित करने के लिए लागू करने के लिए एक ही विधि अच्छी है, लेकिन यह एक नई विशेषता के लिए एक और को लागू करने के लिए इतना काम नहीं है , या इसे एक नए इटरेटर के लिए Base.iteratorsize निर्दिष्ट करने की आवश्यकता है (और समस्याग्रस्त HasLength डिफ़ॉल्ट से छुटकारा पाना)। फ़ॉलबैक broadcastable विधि तब उस विशेषता पर आधारित हो सकती है। या, यदि आप वास्तव में एक विधि के साथ पुनरावृत्ति को परिभाषित करने के प्यार में हैं, तो आप (पोस्ट-डिप्रेशन-रिमूवल) उस स्पष्ट विशेषता को applicable(iterate, ...) रूप में https://github.com/JuliaLang/ में डिफ़ॉल्ट कर सकते हैं। String जैसे कोने के मामलों को अभी भी broadcastable विशेषज्ञता के द्वारा नियंत्रित किया जा सकता है।

यह प्रभावी रूप से 0.6 का डिज़ाइन है, जिसके कारण यह समस्या हुई और #26421 और #19577 और #23197 और #23746 और संभवतः अधिक - इसकी खोज करना कठिन है।

इसका मतलब है कि बेस एक डिफ़ॉल्ट फ़ॉलबैक प्रदान कर रहा है जो कि ऑब्जेक्ट के पूरे वर्ग के लिए गलत है। इसलिए मैं एक ऐसा तंत्र पसंद करता हूं जो त्रुटिपूर्ण हो, जब तक कि आप एक या दूसरे तरीके से ऑप्ट इन नहीं करते। यह राय है और संक्रमण एक दर्द है, लेकिन यह आपको स्पष्ट होने के लिए मजबूर करता है।

आप सही हो सकते हैं कि इटरेटर-जैसे लोगों की तुलना में अधिक "स्केलर-जैसे" कस्टम प्रकार हैं, लेकिन मैं इस तथ्य से खड़ा हूं कि प्रसारण सबसे पहले और सबसे महत्वपूर्ण कंटेनरों पर एक ऑपरेशन है। मुझे उम्मीद है कि f.(x) किसी प्रकार की मैपिंग करेगा और न केवल f(x) ।

और, अंत में, कंटेनर जो स्केलर-डिफॉल्ट उपचार प्राप्त करते हैं, वे प्रसारण के साथ तत्व के अनुसार उपयोग करने में सक्षम नहीं हैं। उदाहरण के लिए, String एक संग्रह प्रकार है जिसे स्केलर की तरह व्यवहार करने के लिए हमारे पास विशेष-आवरण है; "पहुंचना" और तत्व के अनुसार काम करना संभव नहीं है, भले ही यह कुछ स्थितियों में समझ में आता हो (उदाहरण के लिए, isletter.("a1b2c3") )। यह विषमता तर्क है: आप कंटेनरों को रेफरी में अधिक कुशलता से लपेट सकते हैं ताकि आप उन्हें वास्तव में प्रसारण योग्य संग्रह में collect तुलना में स्केलर के रूप में मान सकें।

वे मुख्य तर्क हैं। जहां तक ​​रेफरी की कुरूपता का सवाल है, मैं पूरी तरह सहमत हूं। एक समाधान # 27608 है।

काफी उचित। मेरे पास उन समस्याओं का कोई नॉकडाउन तर्क या जादुई समाधान नहीं है, और https://github.com/JuliaLang/julia/pull/27608 चीजों में सुधार करेगा।

@tkoolen मुझे वही चिंताएं थीं और केस का उपयोग करें ।

@mbauman ऊपर दिए गए तर्क पूरी तरह से आश्वस्त नहीं हो सकते हैं। अधिक पूर्ण होने के लिए यहां दो प्रश्न दिए गए हैं:

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

2) तो यह f.(x) लिए त्रुटि होने की इच्छा पर निर्भर करता है यदि x एक अदिश के रूप में प्रसारित होता है।
f.(x, y, z) लिए एक लिंटर चेतावनी/त्रुटि क्यों नहीं, जैसे "'f' के सभी तर्क स्केलर के रूप में प्रसारित होते हैं"?

वैसे भी, #२७५६३ (जैसे #२७६०८) को ठीक करना और उपयोगकर्ताओं को १.०.० से पहले इसके साथ खेलने देना बुद्धिमानी हो सकती है।
[०.७ और १.०.०-आरसी१.० को बिना किसी सुधार के जारी किया गया]।

वैसे भी, #२७५६३ (जैसे #२७६०८) को ठीक करना और उपयोगकर्ताओं को १.०.० से पहले इसके साथ खेलने देना बुद्धिमानी हो सकती है।
[०.७ और १.०.०-आरसी१.० को बिना किसी सुधार के जारी किया गया]।

मुझे लगता है कि आप इस खबर से चूक गए कि 1.0 जारी कर दिया गया है ।

@StefanKarpinski वास्तव में याद किया। सभी डेवलपर्स को बधाई, जूलिया अद्भुत है, जारी रखें!