Julia: आलसी मानचित्र के लिए संकेतन

संदर्भ। https://github.com/JuliaLang/julia/issues/16285#issuecomment -237320513 के आसपास चर्चा (कॉम्पैक्ट ब्रॉडकास्ट सिंटैक्स को कॉम्पैक्ट उच्च-आदेश फ़ंक्शन सिंटैक्स के लिए सामान्यीकृत करना, ऊपर वर्णित व्यवहार को देखते हुए प्रासंगिक mapreduce जैसा लगता है)। श्रेष्ठ!

विशेष वाक्य रचना के साथ यही समस्या है; इसमें से कभी भी पर्याप्त नहीं है। मुझे लगता है कि इस मामले में बिंदु बहुत अस्पष्ट हैं। क्या अच्छा हो सकता है, और पहले प्रस्तावित किया गया है, f(2x + y) over x , जो f(2x_ + y) for x_ in x विस्तारित हो सकता है।

f(2x + y) for x in x काम करता है और f(2x + y) over x से अधिक वर्बोज़ नहीं है, इसलिए मुझे वास्तव में over की बड़ी आवश्यकता नहीं दिखती है।

(एक झुंझलाहट प्राथमिकता है: for प्राथमिकता = से कम नहीं होनी चाहिए? वर्तमान में, g = f(2x + y) for x in x एक सिंटैक्स त्रुटि देता है।)

#16285 में हमने sum..(f.(x)) (या शायद sum:(f.(x)) ) को sum(f, x) बराबर बनाने पर चर्चा की। इसका लाभ यह है कि यह फ़्यूज़िंग होगा, उदाहरण के लिए sum..(f.(g.(x)) sum(x -> f(g(x)), x) बराबर होगा।

मुझे https://github.com/JuliaLang/julia/issues/16285 के बारे में पता नहीं था

वैसे भी, मुझे लगता है कि मैं मानचित्र को भौतिक बनाने की तुलना में आलसी नक्शा पसंद करता हूं। आईएमएचओ, मैं पसंद करूंगा कि f.(v) जनरेटर लौटाए:

(f(x) for x in v)

अगर मैं इसे अमल में लाना चाहता तो मैं collect(f.(v)) ।

दूसरी तरफ, अगर यह एक सरणी देता है तो मैं f.(v) "अनमटेरियलाइज" नहीं कर सकता। इसलिए मुझे लगता है कि आलसी f.(v) अधिक सामान्य है और अधिक उपयोगी हो सकता है। इसके अतिरिक्त, "फ्यूजिंग" आलसी f.(v) साथ स्वचालित है।

f.(v) एक broadcast ऑपरेशन है, जो map या जनरेटर के अलावा अन्य तरीकों से अधिक सामान्य है। ( map और broadcast की कार्यक्षमता प्रतिच्छेद करती है, लेकिन न तो दूसरे को सम्मिलित करती है।)

यह एक दिलचस्प सवाल है कि क्या कोई आलसी प्रसारण कर सकता है जो एक फ़्यूज़िंग भौतिककरण प्रसारण के रूप में कुशल है। यानी, मान लीजिए f.(x,y) ने एक AbstractArray उपप्रकार लौटाया जो आलसी रूप से इसके तत्वों की गणना करता है। मैं अनुमान लगा रहा हूं कि व्यवहार में उत्तर दुर्भाग्य से "नहीं" है।

उदाहरण के लिए, मान लें कि आप इन कार्यों के अनुक्रम को कैस्केड करते हैं: z .= abs.(x.^2 .+ sin.(sqrt.(y .* 2))) । हमारा फ़्यूज़िंग भौतिकीकरण प्रसारण पूरी तरह से रचना के ऊपरी हिस्से को मिटा सकता है, और अनिवार्य रूप से एक हस्तलिखित लूप के समान प्रदर्शन देता है जो z को जगह में लिखता है। इसके बजाय, कल्पना करें कि इनमें से प्रत्येक ऑपरेशन ने एक आलसी AbstractArray , ताकि असाइनमेंट के दाहिने हाथ की अनुक्रमणिका आलसी getindex कॉल के अनुक्रम के माध्यम से कैस्केड हो। हालांकि कोई बड़ी अस्थायी सरणी आवंटित नहीं की जाएगी, मुझे लगता है कि हमें कंपाइलर को इनलाइन करने और ओवरहेड को खत्म करने के लिए उन सभी getindex कॉलों को खत्म करने में कठिनाई हो सकती है।

हां --- आलस्य के साथ, प्रदर्शन भिन्नता बढ़ जाती है।

मेरी अज्ञानता को क्षमा करें, लेकिन क्या जनरेटर को "फ्यूज" करना संभव है (जैसा कि भौतिक प्रसारण में किया जाता है)? यानी क्या फ्यूज करना संभव है

abs.(sin.(v))

में

(abs(sin(x)) for x in v)

के स्थान पर

(abs(x) for x in (sin(y) for y in v))

क्या यह संकलक द्वारा स्वचालित रूप से किया जा सकता है? फिर आलसी f.(v) की दक्षता के मुद्दे दूर हो जाएंगे, है ना?

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

मेरा कहना है कि आलसी f.(v) आप चाहें तो अमल में ला सकते हैं ( collect(f.(v)) , जो अभी भी बहुत संक्षिप्त है), लेकिन अगर f.(v) अमल में आता है, तो आपको जनरेटर का उपयोग करने के लिए मजबूर किया जाता है आलसी संस्करण प्राप्त करें।

यह तब स्वाद की बात है:

या तो आप प्रसारण को मूर्त रूप देने के लिए लघु सिंटैक्स पसंद करते हैं, और आलसी मानचित्र (जनरेटर) के लिए लंबे सिंटैक्स का उपयोग करते हैं (यह अब ऐसा ही है)।

या आप प्रसारण को अमल में लाने के लिए थोड़ा बड़ा सिंटैक्स पसंद करते हैं ( collect(f.(v)) ) और आलसी प्रसारण के लिए छोटा सिंटैक्स ( f.(v) )।

मैं स्पष्ट (उच्च-क्रम?) फ़ंक्शन संरचना (#17184, https://github.com/FugroRoames/CoordinateTransformations.jl) के विचार के साथ खेल रहा था और मुझे लगता है कि रचनाएं बनाना और फिर (संभवतः बाद में) उन्हें लागू करना कार्य "आलसी" मूल्यांकन करने का एक अविश्वसनीय रूप से शक्तिशाली तरीका है। विचार यह है कि f ∘ g एक नया फ़ंक्शन (या फ़ंक्शन-जैसी वस्तु) बनाता है जैसे कि (f∘g)(x) = f(g(x)) । एक समान ऑपरेटर बनाना सीधा होगा, इसे .∘ (शायद खराब सिंटैक्स) कहते हैं, जो एक साथ समान तरीके से कार्यों को प्रसारित करता है ( (f.∘g)(x) = f.(g.(x)) )

यह चीजों को करने के कुछ दिलचस्प तरीकों की ओर जाता है - आप (ए) कार्यों की पूरी श्रृंखला का निर्माण तब तक कर सकते हैं जब तक कि आप अपेक्षाकृत आसानी से "पूर्ण" आउटपुट नहीं चाहते हैं और फिर उसे कॉल करें, या (बी) इन्हें किसी तरह से लपेटें "आलसी" प्रसारण रचना (शायद किसी अन्य ऑपरेटर के साथ), या (सी) इसे अनुकूलित करने के लिए फ़ंक्शन श्रृंखला का स्थिर (या गतिशील) विश्लेषण करें, उसी तरह जैसे SQL एक क्वेरी को अनुकूलित करेगा। मैंने इस आखिरी विचार के साथ खेलना शुरू कर दिया था, लेकिन इसके लिए प्रतिबद्ध होने का समय नहीं था - लेकिन सिद्धांत रूप में यह Query.jl जैसा होगा लेकिन बिना किसी मैक्रोज़ के।

मुझे संदेह है कि (बी) आप जो चाहते हैं उसके बहुत करीब है - और बड़ी बात यह है कि आपको इसे प्राप्त करने के लिए पार्सर, कंपाइलर या Base से _any_ और समर्थन की आवश्यकता नहीं है। बस कई उपलब्ध ऑपरेटरों में से एक को चुना और मज़े करें!

अब जब हमारे पास आंतरिक रूप से #26891 के माध्यम से एक आलसी प्रसारण वस्तु है, तो एक सिंटैक्स होना अच्छा हो सकता है ताकि फ्यूज्ड डॉट कॉल x .+ f.(x) जैसे आलसी रैपर के लिए materialize(...) कॉल के बिना कम हो। सीसी @mbauman.

उपलब्ध (गैर-ब्रेकिंग) सिंटैक्स में .(x .+ f.(x)) , (for x .+ f.(x)) , <strong i="10">@lazy</strong> x .+ f.(x) ।

कोई एक मैक्रो @lazy या @lazydot भी बना सकता है जो @views है जिसमें यह कोड के ब्लॉक में सभी डॉट कॉल को आलसी बना देगा।

#16285 में, सिंटैक्स sum:(x .+ f.(x)) और sum..(x .+ f.(x)) भी सुझाए गए थे। चूंकि : और .. पहले से ही इंफिक्स ऑपरेटर हैं, हालांकि, यह सिद्धांत रूप में टूट सकता है।

मुझे run(bc::Broadcastable) (शायद विशेष सिंटैक्स के साथ) जैसा कुछ भी पसंद आएगा, जो साइड इफेक्ट वाले कार्यों के लिए 'प्रसारित foreach ' की तरह काम करता है। materialize(bc::Broadcasted) विपरीत, जो एक आउटपुट सरणी को आवंटित और पॉप्युलेट करता है, यह केवल ब्रॉडकास्ट फ़ंक्शन को उचित तर्कों के साथ कॉल करेगा, जबकि रिटर्न वैल्यू को छोड़ देगा।

शायद अर्धविराम सिंटैक्स का उपयोग एक संकेत के रूप में किया जा सकता है कि अभिव्यक्ति को अकेले साइड इफेक्ट के लिए चलाया जाना है: x .+ f.(x);

[संपादित करें: दूसरे विचार पर, मुझे नहीं लगता कि यह उतना आसान होगा जितना यह लग रहा था, क्योंकि आप कल्पना कर सकते हैं कि a = x.+ f.(x); जो कि अमल में लाना चाहेगा]

मैक्रो एक आसान समाधान हो सकता है, जैसे <strong i="5">@discard</strong> f.(x, y, z) ।

@tkoolen , ऐसा लगता है कि एक गैर-भौतिक प्रसारण वाक्यविन्यास द्वारा सम्मिलित किया गया है, तब से आप केवल foreach उपयोग कर सकते हैं

उदाहरण के लिए, यदि हम गैर-भौतिक प्रसारण के लिए (for ...) सिंटैक्स अपनाते हैं, तो आप foreach(for g.(f.(x))) ।

foreach(for g.(f.(x)))

यह एक छोटा सा वाक्य होगा क्योंकि Broadcasted s कॉल करने योग्य नहीं हैं ... और यदि वे थे, तो मैं foreach(::Broadcasted) को ठीक एक बार निष्पादित करने की अपेक्षा करता हूं (जैसे foreach(println) ) हम शायद इसे अतीत में देख सकते हैं, लेकिन तकनीकी रूप से सही संस्करण कुछ ऐसा होगा:

bc = (for g.(f.(x))) # or whatever
foreach(i->bc[i], CartesianIndices(axes(bc)))

@mbauman , मेरी सोच यह है कि अभौतिक Broadcasted वस्तुओं को चलने योग्य होना चाहिए ताकि आप उन्हें पुनरावृत्ति प्रोटोकॉल की अपेक्षा करने वाली किसी भी चीज़ पर पास कर सकें।

(अभी, हमारे पास एकल-तर्क foreach फ़ंक्शन नहीं है, लेकिन यह मेरे लिए समझ में आता है कि foreach(itr) foreach(identity, itr) बराबर होना चाहिए ।)

आह, बिल्कुल। मैं कोड के बहुत करीब बैठकर अंधा हो गया हूं। Broadcasted s (अभी तक) चलने योग्य नहीं हैं, लेकिन चलिए उन्हें ऐसा बनाते हैं।

उस ने कहा, हमारे पास शून्य-तर्क है foreach :

julia> foreach(()->println("hello"))
hello

यह सिर्फ एक vararg में पतित 0-arg मामला है, f को बिना किसी तर्क के एक बार कॉल करना। एक चलने योग्य bc::Broadcasted , मैं इसे foreach(identity, bc) ।

मुझे लगता है कि Broadcasted वस्तुओं के चलने योग्य होने से इस विशेष उपयोग के मामले की परवाह किए बिना बहुत कुछ समझ में आता है। हालांकि, identity के पहले तर्क के रूप में foreach होना मेरी राय में थोड़ा अजीब है। f.(x, y, z) के मामले में मुझे उम्मीद है कि f पहला तर्क होगा। मुझे लगता है कि यदि आपको पुनरावर्ती प्रसारण के लिए पूर्ण समर्थन की आवश्यकता है, तो आपको identity संस्करण जैसे कुछ का उपयोग करना होगा, लेकिन हो सकता है कि गैर-पुनरावर्ती मामले को और अधिक आकर्षक बनाने का कोई तरीका हो? इस मामले में, आपके पास भी हो सकता है

foreach(args -> f(args...), <strong i="12">@lazy</strong> tuple.(x, y, z))

जो, हालांकि वह सुंदर नहीं है, कम से कम f को 'सही' स्थिति में रखता है। अगर पहले तर्क के रूप में f का कोई तरीका था, तो यह मेरे विचार में बेहतर होगा, क्योंकि यह do सिंटैक्स के साथ अच्छी तरह से काम करेगा।

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

foreach(<strong i="7">@lazy</strong> tuple.(x, y, z)) do (a, b, c)
    println(a + b * c)
end

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

पहला सवाल यह है कि गैर-भौतिक प्रसारण कैसे प्राप्त किया जाए; मैं for सिंटैक्स के लिए आंशिक हूँ क्योंकि यह संक्षिप्त है और जनरेटर सिंटैक्स की याद दिलाता है। लेकिन यह एकमात्र विकल्प से बहुत दूर है।

दूसरी शर्त यह है कि ब्रॉडकास्टेड ऑब्जेक्ट को चलने लायक बनाया जाए।

दूसरी शर्त यह है कि ब्रॉडकास्टेड ऑब्जेक्ट को चलने लायक बनाया जाए।

https://github.com/JuliaLang/julia/issues/18618? और चूंकि हम प्रसारण को पुनरावृत्ति के संदर्भ में परिभाषित करने का विकल्प चुन रहे हैं (https://github.com/JuliaLang/julia/pull/26435, map ), यह उचित लगता है। क्या मुझे कुछ याद आ रहा है (उदाहरण के लिए क्या हमें इस मुद्दे को ट्राइएज की आवश्यकता है)?

ब्रॉडकास्ट की "पुनरावृत्ति" के तीन अलग-अलग पहलू हैं। आंतरिक कार्यान्वयन, खुला एपीआई, और समर्थित तर्क। मेरी वर्तमान योजना है:

• अनुक्रमण पर प्रसारित आंतरिक कार्यान्वयन को आधार बनाएं — यथास्थिति
• केवल getindex पर प्रॉक्सी करके एक चलने योग्य API (प्रसारण पर पुनरावृति) का समर्थन करें - यह # 26987 है।
• उपयोग करने से पहले केवल collect द्वारा चलने योग्य तर्कों का समर्थन करें - 0.7 बहिष्करण हटा दिए जाने के बाद।

हालांकि ऐसा लगता है कि हमें केवल पुनरावृत्ति (और अनुक्रमण नहीं) के आधार पर पूरी तरह से काम करने के लिए प्रसारण को दोबारा करने में सक्षम होना चाहिए, मुझे लगता है कि यह वास्तव में कठिन और संभवतः असंभव तर्कों के कुछ संयोजनों के लिए असंभव होगा। प्रदर्शनकारी ढंग से ऐसा करना और भी बुरा है। हमें पुनरावृत्ति और नेस्टेड लूप के क्रम को बहुत सावधानी से तैयार करना होगा ताकि हमें आयामों को बैकट्रैक करने की आवश्यकता न हो। साथ ही यह _प्रसारण_के शब्दार्थ को बदल देगा। उदाहरण के लिए, एक शुद्ध पुनरावृत्ति कार्यान्वयन के साथ, f.(1:3) .+ g.([1 2]) .+ h.() मैं f को तीन बार निष्पादित करने की अपेक्षा करता हूं, g दो बार निष्पादित करने के लिए, और h निष्पादित करने के लिए एक बार। जैसा कि यह खड़ा है, तीनों कार्य 6 बार निष्पादित होते हैं। लोग A .*= rand.() जैसी चीज़ों के लिए इस व्यवहार पर भरोसा करते हैं। इसलिए मैं इसे अकेला छोड़ने के लिए संतुष्ट हूं।

अब जब प्रसारित वस्तुएं चलने योग्य हैं, तो हमें गैर-भौतिक डॉट कॉल के लिए सिंटैक्स को बाइकशेड करना चाहिए। बस चीजों को शुरू करने के लिए, शायद कुछ गैर-ब्रेकिंग विकल्पों का एक गैर-बाध्यकारी स्ट्रॉ पोल (जो समाप्त करता है f..(x) ):

• :अंगूठा: for f.(x) (वर्तमान x for y in z जनरेटर सिंटैक्स की तरह)
• :टाडा: .(f.(x))
• :heart: <strong i="13">@lazy</strong> f.(x) ( Lazy.jl से टकराता है) या <strong i="16">@lazy</strong> f(x) ( @. तरह अभिनय)
• 😕 उपरोक्त में से किसी के लिए नहीं

for f.(x) वास्तविक लूप के लिए सिंटैक्स के साथ नहीं टकराएगा?

@cossio , नहीं, इसे जेनरेटर सिंटैक्स की तरह ही संभाला जाएगा। वैसे ही जैसे आप वर्तमान में क्या कर सकते हैं sum(x^2 for x in x) , तुम कर सकते हो sum(for x.^2) ।

और एक जनरेटर की तरह, आप अन्य परिस्थितियों में (आवश्यकतानुसार) माता-पिता का उपयोग करके असंबद्ध होंगे, उदाहरण के लिए हम वर्तमान में x = (y.^2 for y in 1:3) , और इसी तरह आप x = (for y.^2) ।

sum(for x.^2) और x = (for y.^2) वर्तमान में सिंटैक्स त्रुटियां हैं, इसलिए कोई टूट-फूट नहीं होगी।

यह मुझे लगता है यह नहीं है कि (for f.(x)) का अच्छा उपयोग है for : में f(x) for x in X , उस कीवर्ड चर इनपुट में एक प्रविष्टि का प्रतिनिधित्व करने से पहले प्रयोग किया जाता है, लेकिन यहाँ यह इसके बजाय परिवर्तन से पहले दिखाई देगा। यह वास्तव में तार्किक नहीं है। यदि कुछ भी हो, तो यह (f.(x) for) होना चाहिए, जो निश्चित रूप से अजीब है।

कम से कम @lazy स्पष्ट होगा, इस कमी के साथ कि यह वर्बोज़ है। हम @view / @views भी उपयोग कर सकते हैं, क्योंकि परिणाम प्रसारण संचालन का एक प्रकार का दृश्य होगा (और आप आलसी प्रसारण के साथ ही सरणी दृश्यों का उपयोग करने की संभावना रखते हैं यदि अभिव्यक्ति में अनुक्रमण भी शामिल है)।

मुझे sum:(f.(x)) या sum..(f.(x)) का विचार भी पसंद है, लेकिन ..(f.(x)) अलगाव में अजीब लगता है और :(f.(x)) पहले ही लिया जा चुका है, इसलिए दुर्भाग्य से यह वास्तव में एक नहीं है सामान्य रूप से आलसी Broadcasted ऑब्जेक्ट बनाने का समाधान।

for f.(x) सिंटैक्स के साथ मैं #2675 पर वापस सोच रहा था: यदि आप for X बजाय for x in X लिखते हैं, तो X को एक पुनरावर्तक के रूप में व्याख्या करना बहुत स्वाभाविक है .

मैं सहमत हूं कि @lazy में एक बोधगम्यता लाभ है। एक विकल्प जो इसकी वाचालता के साथ मदद कर सकता है, वह होगा @lazy को @. तरह कार्य करना, जिसमें डॉट कॉल शामिल हों। यानी आप सिर्फ sum(<strong i="13">@lazy</strong> f(x^2)) वगैरह लिखेंगे और यह आपके लिए "डॉट्स ऐड" करेगा।

sum:(f.(x)) और sum..(f.(x)) परिवर्तन तोड़ने वाले होंगे, इसलिए जब तक हम जूलिया 2.0 की प्रतीक्षा नहीं करना चाहते, वे गैर-शुरुआत हैं।

वैसे, क्या broadcasted अब निर्यात किया जाना चाहिए (कार्यात्मक इंटरफ़ेस पसंद करने वाले लोगों के लिए broadcast से मेल खाने के लिए)? क्या इसे Broadcast से निर्यात किया जाना चाहिए लेकिन Base ( Iterators से मेल खाने के लिए) नहीं?

@lazy लिए एक संभावित नकारात्मक पहलू यह है कि उन परिस्थितियों की कल्पना करना वास्तव में आसान है जहां मिश्रित बिंदीदार और आलसी कॉल चाहते हैं, और यह वाक्यविन्यास विकल्प अभी भी उस पर पेंट करता है।

मुझे लगता है कि f.:(x) हालांकि उपलब्ध है, है ना?
.: 3 बिंदुओं का एक छोटा सा पैटर्न है।
बृहदान्त्र में एक प्रकार का प्राकृतिक "इसका अनुसरण करने वाली चीज़ एक सूची का प्रभाव है,

मुझे लगता है कि f:.(x) भी उपलब्ध है, हालांकि मुझे इसे पढ़ना कठिन लगता है क्योंकि कोलन खुले ब्रैकेट के बगल में नहीं है।

क्या इसका उपयोग Base.:(=)(a::Foo, b::Foo) = a.bar == b.bar जैसी किसी चीज़ में किया जाता है?
मुझे लगता है कि यह हो सकता है, लेकिन यदि ऐसा है, तो मुझे लगता है कि यह अस्पष्ट है कि यह आरएचएस मूल्य में है,

@oscardssmith , यदि @lazy फ़ंक्शन कॉल में डॉट्स जोड़ता है (जैसे @. ) तो आप इसे परिभाषित कर सकते हैं ताकि शाब्दिक डॉट कॉल आलसी न हों। यानी अगर आपने <strong i="8">@lazy</strong> f(g(h.(x))) तो f और g कॉल फ्यूज और आलसी होंगे, लेकिन h.(x) एक सामान्य डॉट कॉल होगा।

और @. आप उन कॉलों को विभाजित कर सकते हैं जिन्हें आप प्रभावित नहीं करना चाहते हैं, उदाहरण के लिए sum(<strong i="15">@lazy</strong> sqrt($sort(x))) सामान्य तरीके से sort कॉल करेंगे।

@lazy बारे में दूसरी अच्छी बात यह है कि इसे अब एक पैकेज में लागू किया जा सकता है, और 1.1 में बेस में फोल्ड किया जा सकता है। (केवल झुंझलाहट Lazy.jl के साथ संघर्ष है। पैकेज को क्या कहा जाएगा?)

पैकेज को क्या कहा जाएगा?

इस उद्देश्य के लिए IIRC के लिए Experimental / Future मॉड्यूल पर चर्चा की गई है। यह कार्यक्षमता ऐसे के लिए एक आदर्श उम्मीदवार की तरह लगती है? श्रेष्ठ!

एक अन्य विकल्प @cossio की पिछली टिप्पणी पर पुनर्विचार करना हो सकता है, यानी आलसी संस्करण को डिफ़ॉल्ट बनाने के लिए और collect को अमल में लाने के लिए। मेरी राय में, यह सबसे साफ समाधान है क्योंकि इसके लिए किसी नए सिंटैक्स या मैक्रोज़ की आवश्यकता नहीं है, लेकिन निश्चित रूप से यह एक बड़ा बदलाव है।

वैसे, क्या इस बिंदु पर materialize सिर्फ collect तरीके होने चाहिए?

collect यहां गलत कार्य हो सकता है, क्योंकि इसे हमेशा Array लौटाने के लिए परिभाषित किया गया है जबकि broadcast को एक स्केलर ( 2 .+ 1 ), टपल वापस करने के लिए परिभाषित किया गया है ( (1, 2) .+ (3, 4) ) या एक Array , साथ ही अन्य कस्टम प्रकारों की संभावना के साथ।

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

@lazy मैक्रो को लागू करने के लिए उपयोग किए जाने वाले @dawbarton के _lazy फ़ंक्शन में विचार के आधार पर (देखें https://discourse.julialang.org/t/19641/20), मैंने अभी देखा कि Broadcasted को केवल एक डॉट कॉल के साथ निकाला जा सकता है, यहां तक ​​कि मैक्रो के बिना भी:

"""
    air.(broadcasting_expression)

Broadcast without materialization.
"""
air(::Any) =
    error("Function `air` must be called with a dot as in: ",
          "`air.(YOUR .+ BROADCASTING .* EXPRESSION ./ HERE)`")

struct Aired{T}
    value::T
end
Broadcast.broadcasted(::typeof(air), x) = Aired(x)
Base.materialize(x::Aired) = x.value

फिर:

julia> air.(sin.(1:3))
Base.Broadcast.Broadcasted(sin, (1:3,))

ऐसा कहकर, ऐसा करने के लिए एक छोटा वाक्यविन्यास अच्छा होगा ...

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

यह होना अच्छा होगा, और प्रसारण के साथ खिलवाड़ करने के ये विचार चतुर हैं।

इन्हें संक्षेप में प्रस्तुत करने के लिए (जैसा कि ऊपर प्रवचन सूत्र में है) ध्यान दें कि वे उतने तेज़ नहीं हैं जितने वे हो सकते हैं:

julia> using BenchmarkTools, LazyArrays

julia> a = rand(10_000); b = rand(10_000); c = b';

julia> <strong i="8">@btime</strong> sum($a .+ $b);
  4.263 μs (2 allocations: 78.20 KiB)

julia> <strong i="9">@btime</strong> sum(air.($a .+ $b)); # or <strong i="10">@lazy</strong> $a .+ $b
  8.733 μs (2 allocations: 48 bytes)

julia> <strong i="11">@btime</strong> sum(BroadcastArray(+, $a, $b)); 
  1.471 μs (3 allocations: 80 bytes)

air -स्टाइल आलसी प्रसारणों में कटौती के संबंध में, मुझे चार (संपादित करें: 5) समस्याएं/प्रश्न दिखाई देते हैं:

1. हम कब चेक करते हैं DimensionMismatch ? वर्तमान air पहुँच पर जाँच करता है, लेकिन आकृतियों की उत्सुकता से जाँच करने के लिए एक तर्क होगा।
2. क्या हम छोटी Broadcasted वस्तु के आवंटन से भी बच सकते हैं? इसके लिए थोड़ी मालिश की आवश्यकता होती है। वास्तव में Broadcasted ऑब्जेक्ट का उपयोग केवल त्रुटि पथों पर किया जाता है, तो हो सकता है कि ऑप्टिमाइज़र हमारे लिए इसे ठीक कर सके? (लक्ष्य: new बयान जो केवल त्रुटि पथ में उपयोग किए जाते हैं (एक फेंक द्वारा उलटा-वर्चस्व वाला) डुप्लिकेट हो जाते हैं और त्रुटि पथ में स्थगित हो जाते हैं)
3. स्थिरता टाइप करें (खाली कटौती का मुद्दा)। हमारा लक्ष्य यह है कि उपयोगकर्ताओं के लिए अच्छा प्रदर्शन करने वाली कटौती लिखना आसान हो और eltype उपलब्ध न हो।
4. सिमड.
5. कुछ आयामों में कटौती, जैसे sum(air.(a.*b), dims=1)

प्रदर्शन के संबंध में, air संस्करण कुछ कस्टम कटौती के लिए बहुत अच्छा प्रदर्शन करता है। हम शायद Broadcasted -ऑब्जेक्ट्स के लिए सबसे महत्वपूर्ण मामलों में विशेषज्ञता के साथ दूर हो सकते हैं।

julia> air(::Any) =
           error("Function `air` must be called with a dot as in: ",
                 "`air.(YOUR .+ BROADCASTING .* EXPRESSION ./ HERE)`");
julia> struct Aired{T}
           value::T
       end
julia> Broadcast.broadcasted(::typeof(air), x) = Aired(x)
julia> Base.Broadcast.materialize(x::Aired)=x.value

julia> function ndot(a,b)
       length(a)==length(b)>0 || error()
       <strong i="23">@inbounds</strong> s=a[1]*b[1]
       <strong i="24">@simd</strong> for i=2:length(a)
       <strong i="25">@inbounds</strong> s += a[i]*b[i]
       end
       s
       end;
julia> Base.<strong i="26">@propagate_inbounds</strong> function airsum(x)
       s = x[1]
       <strong i="27">@simd</strong> for i=2:length(x)
       <strong i="28">@inbounds</strong> s += x[i]
       end
       s
       end

julia> airdot(a,b) = airsum(air.(a.*b));
julia> airdot_ib(a,b) = <strong i="29">@inbounds</strong> airsum(air.(a.*b));
julia> airdotsum(a,b)=<strong i="30">@inbounds</strong> sum(air.(a.*b))
julia> a=rand(10_000); b=copy(a);
julia> begin
       <strong i="31">@btime</strong> ndot($a,$b);
       <strong i="32">@btime</strong> airdot($a,$b);
       <strong i="33">@btime</strong> airdot_ib($a,$b);
       <strong i="34">@btime</strong> airdotsum($a,$b);
       end;
  3.784 μs (0 allocations: 0 bytes)
  3.798 μs (2 allocations: 48 bytes)
  3.786 μs (0 allocations: 0 bytes)
  18.308 μs (2 allocations: 48 bytes)

airsum की तर्ज पर मेरा प्रयास यहां दिया गया है, जो sum(air.(a .* b')) भी इलाज करता है:

julia> function bsum(bc)
           T = Broadcast.combine_eltypes(bc.f, bc.args)
           tot = zero(T)
           <strong i="8">@simd</strong> for I in eachindex(bc)
               <strong i="9">@inbounds</strong> tot += bc[I]
           end
           tot
       end;

क्या sum(air.(a .* b'), dims=1) काम करने का कोई अच्छा तरीका है? शायद यह आपकी सूची में नंबर 5 हो सकता है।

(संपादित करें: छोटा)

शायद ऐसा करने का सही तरीका air.(...) लिए कुछ <: AbstractArray में अमल में लाना है। और ऐसा करने का सबसे आसान तरीका BroadcastArray का फिर से उपयोग करना होगा, जिसे मैंने इस पीआर में आजमाया था: https://github.com/JuliaArrays/LazyArrays.jl/pull/21

क्या हम गैर-भौतिक प्रसारण के लिए मैक्रो @: उपयोग कर सकते हैं? ऐसा लगता है कि यह इस समय वाक्य रचनात्मक रूप से अमान्य है। लेकिन मुझे लगता है कि इसे वैध बनाना तोड़ना नहीं है? यह अच्छा है क्योंकि यह छोटा है और वाक्य रचना में एक नई अवधारणा का परिचय नहीं देता है (मुझे लगता है?)

मैंने @: साथ एक ब्रॉडकास्टेड ऑब्जेक्ट बनाने के लिए एक पैच #31088 बनाया, यह देखने के लिए कि क्या इसे जोड़ने से जूलिया में मौजूदा सिंटैक्स टूटता नहीं है। #31020 के साथ, हम डॉट उत्पाद की गणना करने के लिए sum(@: x .* y) कर सकते हैं जो लगभग LinearAlgebra.dot जितना तेज़ है लेकिन अधिक लचीला है।

इसे आगे बढ़ाने के लिए धन्यवाद!

वाक्य रचना के संबंध में, मुझे यकीन नहीं है कि मुझे @: । यह थोड़ा सा @. जैसा दिखता है, फिर भी इसके विपरीत यह फ़ंक्शन कॉल को डॉट-कॉल में नहीं बदलता है: यह केवल मौजूदा डॉट-कॉल को प्रभावित करता है। और : जूलिया में प्रसारण से संबंधित नहीं है, बल्कि श्रेणियों से संबंधित है। ऊपर @lazy का उपयोग करने का सुझाव दिया गया था, जो अधिक स्पष्ट है। मैंने इस अर्थ को @views जोड़ने का भी प्रस्ताव दिया है, यह देखते हुए कि Broadcasted ऑब्जेक्ट इसके इनपुट पर एक प्रकार का दृश्य है (यानी यह प्रतियों से बचता है और इनपुट को संशोधित करने से परिणाम प्रभावित होगा)।

टिप्पणियों के लिए धन्यवाद!

और : जूलिया में प्रसारण से संबंधित नहीं है, बल्कि श्रेणियों से संबंधित है।

मैं श्रेणियों के बजाय उद्धरणों से संबंधित होने के लिए @: देख रहा हूं। अर्थात्, :(expression) "गार्ड्स" expression मूल्यांकन के विरुद्ध और @:(expression) "गार्ड्स" भौतिककरण के विरुद्ध। @: में दो बिंदु हैं इसलिए डॉट कॉल से संबंधित होना मुश्किल नहीं है।

ऊपर @lazy का उपयोग करने का सुझाव दिया गया था, जो अधिक स्पष्ट है।

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

साथ ही, मुझे लगता है कि @lazy बहुत सामान्य शब्द है क्योंकि प्रोग्रामिंग अवधारणाओं में बहुत अधिक आलसी चीजें हैं। यह पहले ही नोट किया जा चुका है कि नाम Lazy.jl के नाम के साथ क्रैश हो जाता है। अधिक विशिष्ट अंकन होना बेहतर है।

मैंने इस अर्थ को @views जोड़ने का भी प्रस्ताव दिया है, यह देखते हुए कि Broadcasted ऑब्जेक्ट अपने इनपुट पर एक प्रकार का दृश्य है (यानी यह प्रतियों से बचा जाता है और इनपुट को संशोधित करने से परिणाम प्रभावित होगा)।

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

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

कुछ उपाय: @, , @gen , @.. ।

FWIW, उस परिवार के तीन मैक्रो @: , @. , @views एक साथ अच्छा खेलते हैं: sum(@: @. <strong i="8">@views</strong> a[I] * b[I]) छह क्रमपरिवर्तनों में से किसी में भी अपेक्षित रूप से काम करता है।

इस व्यवहार को @views जोड़ना दुर्भाग्य से टूट जाएगा

अच्छी बात। अगर हमें ऐसा करना है तो यह एक नया मैक्रो होना चाहिए। लेकिन लोग पुस्तकालयों में इंटरफेस के साथ प्रयोग कर सकते हैं यदि हमारे पास आलसी प्रसारण के लिए अच्छा समर्थन है।

इस संकेतन के लिए एक और प्रेरणा यह है कि यह "प्रसारण योग्य कॉल अधिभार" को परिभाषित करने के लिए उपयोगी है: https://discourse.julialang.org/t/best-practice-for-broadcastable-callables/21000

ट्राइएज द्वारा प्रस्तावित नया सिंटैक्स for f.(args...) https://github.com/JuliaLang/julia/pull/31088#issuecomment -473030504 #31553 में लागू किया गया है

एक अन्य समाधान ArrayReducer संरचना को लागू करना है जो कम करने वाले ऑपरेशन को लागू करता है, लेकिन कार्य करता है जैसे कि इसका उपयुक्त आकार था। देखें https://discourse.julialang.org/t/is-there-something-like-broadcast-mapreduce/6076/15 (मुझे लगता है कि यह बहुत चालाक है, क्या आप @meggart हैं?) फिर आप उस पर साधारण broadcast! को कॉल कर सकते हैं। मुझे लगता है कि यह विचार करने लायक एक विकल्प है।

हमें "बस" वाक्यविन्यास तय करना है (जो शायद हमेशा सबसे कठिन हिस्सा है ...) दुर्भाग्य से, ऐसा लगता है कि ट्राइएज में कोई आम सहमति नहीं है https://github.com/JuliaLang/julia/pull/31553#issuecomment -479758476। मैंने प्रूफ-ऑफ-कॉन्सेप्ट्स को लागू करके चर्चा को आगे बढ़ाने की कोशिश की लेकिन मैं "बुलेट से बाहर" एटीएम हूं।

प्रसारण में कमी के _कार्यान्वयन_ के संबंध में, पहले से ही #31020 है। मेरा मानना ​​है कि विशेषज्ञता mapreduce (और mapfoldl ) जाने के लिए सही दिशा है (बजाय "हैकिंग" broadcast! जैसा कि ArrayReducer , IIUC में किया गया है)।

मैं इसे दूसरा करूंगा। ArrayReducer हैक बड़े 1.0 प्रसारण परिवर्तनों से पहले किया गया था, जिसने मेरी तत्काल समस्या को हल कर दिया, इसलिए मैं सहमत हूं कि यह यहां कुछ भी महत्वपूर्ण नहीं जोड़ेगा, और विशेष रूप से # 31020 बहुत अधिक शक्तिशाली है।

वैसे भी आलसी मानचित्र के लिए एक वाक्यविन्यास खोजने में शुभकामनाएँ, मैं इसे जूलिया बेस में भी रखने के लिए उत्सुक हूँ।

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