+1

या func.(args...) के लिए वाक्यात्मक चीनी के रूप में

broadcast(func, args...)

लेकिन शायद मैं अकेला हूँ जो इसे पसंद करेगा?
किसी भी तरह, +1।

:-1: यदि कुछ भी हो, तो मुझे लगता है कि स्टीफन के f[...] के अन्य सुझाव में समझ के लिए एक अच्छी समानता है।

@ihnorton की तरह, मुझे भी इस विचार का बहुत शौक नहीं है। विशेष रूप से, मुझे a .+ b और sin.(a) दोनों होने की विषमता नापसंद है।

शायद हमें विशेष वाक्यविन्यास की आवश्यकता नहीं है। #1470 के साथ, हम कुछ ऐसा कर सकते हैं

call(f::Callable,x::AbstractArray) = applicable(f,x) ? apply(f,x) : map(f,x)

सही? हालांकि, किसी भी फ़ंक्शन पर ऑटो-मैप प्राप्त करने के लिए शायद यह बहुत जादुई होगा।

@quinnj वह एक पंक्ति कॉल ओवरलोडिंग की अनुमति देने के बारे में मेरे सबसे बड़े डर को सारांशित करती है। मैं कई दिनों तक सो नहीं पाऊंगा।

अभी तक सुनिश्चित नहीं है कि यह वाक्य रचनात्मक रूप से संभव है, लेकिन .sin(x) के बारे में क्या? क्या यह a .+ b के समान है?

मुझे लगता है कि [] बहुत अधिक भारित हो रहा है और इस उद्देश्य के लिए काम नहीं करेगा। उदाहरण के लिए, हम शायद Int(x) लिखने में सक्षम होंगे, लेकिन Int[x] एक सरणी बनाता है और इसलिए इसका मतलब map नहीं हो सकता।

मैं .sin(x) के साथ जहाज पर रहूंगा।

हमें उसके लिए कुछ सिंटैक्स वापस करना होगा, लेकिन यदि Int(x) स्केलर संस्करण है तो Int[x] तत्व प्रकार के वेक्टर के निर्माण के लिए समानता से उचित है Int । मेरे दिमाग में उस वाक्य रचना को और अधिक सुसंगत बनाने का अवसर वास्तव में f[v] प्रस्ताव के सबसे आकर्षक पहलुओं में से एक है।

f[v] के लिए map सिंटैक्स बनाने से सिंटैक्स अधिक सुसंगत कैसे हो जाता है? मुझे समझ नहीं आ रहा है। map में मौजूदा T[...] सरणी कंस्ट्रक्टर सिंटैक्स की तुलना में एक अलग "आकार" है। Vector{Int}[...] के बारे में क्या? क्या यह काम नहीं करेगा?

लॉल, डराने के लिए खेद है @JeffBezanson! हाहा, कॉल ओवरलोडिंग निश्चित रूप से थोड़ा डरावना है, हर बार थोड़ी देर में, मुझे लगता है कि आप जूलिया में कोड ऑबफस्केशन के प्रकार के बारे में सोच सकते हैं और call के साथ, आप कुछ गड़बड़ चीजें कर सकते हैं।

मुझे लगता है कि .sin(x) भी एक अच्छे विचार की तरह लगता है। क्या बहु-आर्ग के साथ क्या करना है, इस पर आम सहमति थी?

:-1:. उच्च ऑर्डर फ़ंक्शंस का उपयोग करने की तुलना में कुछ वर्णों को सहेजना मुझे नहीं लगता कि पठनीयता में लागत के लायक है। क्या आप कल्पना कर सकते हैं कि .func() / func.() और func() के साथ एक फ़ाइल हर जगह फैली हुई है?

ऐसा लगता है कि हम कम से कम a.(b) सिंटैक्स को वैसे भी हटा देंगे।

वाह, मधुमक्खियों का घोंसला बनाने की बात करते हैं! चर्चा को बेहतर ढंग से दर्शाने के लिए मैंने नाम बदल दिया।

हम 2-तर्क का नाम बदल सकते हैं map से zipWith :)

यदि कुछ सिंटैक्स वास्तव में आवश्यक है, तो [f <- b] या कोष्ठक के अंदर _समझौते पर कोई अन्य वाक्य कैसे होगा?

( @JeffBezanson आपको बस इस बात का डर है कि कोई Don't do stupid stuff: I won't optimize that या Moose.jl लिखने जा रहा है :) ...

वर्तमान में Int[...] लिखना इंगित करता है कि आप तत्व प्रकार Int की एक सरणी बना रहे हैं। लेकिन अगर Int(x) का अर्थ है x को Int में परिवर्तित करना Int को एक फ़ंक्शन के रूप में लागू करके तो आप Int[...] का अर्थ " Int लागू करें" पर भी विचार कर सकते हैं। Int । तो Int[v] [ Int(x) for x in v ] बराबर होगा और Int[ f(x) for x in v ] के बराबर होगा [ Int(f(x)) for x in v ] । बेशक, तब आपने Int[ f(x) for x in v ] लिखने की कुछ उपयोगिता खो दी है - यानी हम स्थिर रूप से जान सकते हैं कि तत्व प्रकार Int है - लेकिन अगर इसे लागू करते हैं तो Int(x) को Int (एक अनुचित बाधा नहीं) प्रकार का मूल्य उत्पन्न करना चाहिए, तब हम उस संपत्ति को पुनर्प्राप्त कर सकते हैं।

मुझे और अधिक वैश्वीकरण/निहित-बिल्ली नरक के रूप में मारता है। Int[x, y] क्या करेगा? या इससे भी बदतर, Vector{Int}[x] ?

मैं यह नहीं कह रहा हूं कि यह अब तक का सबसे अच्छा विचार है या इसके लिए वकालत भी कर रहा है - मैं केवल यह इंगित कर रहा हूं कि यह मौजूदा उपयोग के साथ पूरी तरह से संघर्ष नहीं करता है, जो स्वयं एक हैक का एक सा है। यदि हम मौजूदा उपयोग को अधिक सुसंगत पैटर्न का हिस्सा बना सकते हैं, तो यह एक जीत होगी। मुझे यकीन नहीं है कि f[v,w] का क्या अर्थ होगा - स्पष्ट विकल्प [ f(x,y) for x in v, y in w ] या map(f,v,w) हैं लेकिन अभी भी और विकल्प हैं।

मुझे लगता है कि a.(b) का शायद ही उपयोग किया जाता है। एक त्वरित परीक्षण चलाया और यह जंगली में ~ 4,000 जूलिया स्रोत फ़ाइलों में से केवल 54 में उपयोग किया जाता है: https://gist.github.com/jakebolewski/104458397f2e97a3d57d।

मुझे लगता है कि यह पूरी तरह से टकराता है। T[x] में "आकार" T --> Array{T} है, जबकि map का आकार Array{T} --> Array{S} है। वे काफी असंगत हैं।

ऐसा करने के लिए मुझे लगता है कि हमें T[x,y,z] को कंस्ट्रक्टर के रूप में छोड़ना होगा $ Vector{T} । सादा पुरानी सरणी अनुक्रमण, A[I] जहां I एक वेक्टर है, को map(i->A[i], I) के रूप में देखा जा सकता है। एक सरणी "लागू करना" एक फ़ंक्शन को लागू करने जैसा है (बेशक मैटलैब भी उनके लिए समान वाक्यविन्यास का उपयोग करता है)। उस अर्थ में सिंटैक्स वास्तव में काम करता है, लेकिन हम इस प्रक्रिया में टाइप-वेक्टर सिंटैक्स खो देंगे।

मुझे ऐसा लगता है कि यहां बहस करने वाले वाक्यविन्यास अधिक महत्वपूर्ण परिवर्तन से विचलित होते हैं: map तेज बनाना।

स्पष्ट रूप से map तेज बनाना (जो, वैसे, जूलिया में कार्यों की धारणा के काफी गहन रीडिज़ाइन का हिस्सा बनने की आवश्यकता है) अधिक महत्वपूर्ण है। हालाँकि sin(x) से map(sin, x) तक जाना उपयोगिता के दृष्टिकोण से बहुत महत्वपूर्ण है, इसलिए वास्तव में वेक्टराइजेशन को मारने के लिए सिंटैक्स काफी महत्वपूर्ण है।

हालाँकि, sin(x) से map(sin, x) पर जाना उपयोगिता के दृष्टिकोण से बहुत महत्वपूर्ण है, इसलिए वास्तव में वेक्टराइजेशन को मारने के लिए सिंटैक्स काफी महत्वपूर्ण है।

पूरी तरह से सहमत।

मैं @JeffBezanson से सहमत हूं कि f[x] वर्तमान टाइप किए गए सरणी निर्माण Int[x, y] आदि के साथ काफी असंगत है।

.sin को sin. $ से अधिक पसंद करने का एक अन्य कारण अंत में उपयोग करने की अनुमति देना है जैसे Base.(+) # Base में + फ़ंक्शन तक पहुंचने के लिए (एक बार a.(b) हटा दिया गया है)।

जब कोई मॉड्यूल अपने स्वयं के sin (या जो भी) फ़ंक्शन को परिभाषित करता है और हम वेक्टर पर उस फ़ंक्शन का उपयोग करना चाहते हैं, तो क्या हम Module..sin(v) करते हैं? Module.(.sin(v)) ? Module.(.sin)(v) ? .Module.sin(v) ?

इनमें से कोई भी विकल्प अब वास्तव में अच्छा नहीं लगता है।

मुझे ऐसा लगता है कि इस चर्चा में समस्या की जड़ छूट गई है। यानी: कंटेनरों के लिए एकल तर्क कार्यों को मैप करते समय, मुझे लगता है कि map(func, container) सिंटैक्स _already_ स्पष्ट और संक्षिप्त है। इसके बजाय, कई तर्कों से निपटने के दौरान ही मुझे लगता है कि हम करी के लिए बेहतर सिंटैक्स से लाभान्वित हो सकते हैं।

उदाहरण के लिए map(x->func(x,other,args), container) की वर्बोसिटी लें, या इसे बदतर बनाने के लिए एक फिल्टर ऑपरेशन को चेन करें filter(x->func2(x[1]) == val, map(x->func1(x,other,args), container)) ।

इन मामलों में, मुझे लगता है कि एक छोटा नक्शा सिंटैक्स ज्यादा मदद नहीं करेगा। ऐसा नहीं है कि मुझे लगता है कि ये विशेष रूप से खराब हैं, लेकिन ए) मुझे नहीं लगता कि एक शॉर्ट-हैंड map बहुत मदद करेगा और बी) मुझे हास्केल के कुछ सिंटैक्स के बाद पाइनिंग पसंद है। ;)

आईआईआरसी, हास्केल में उपरोक्त filter ((==val) . func2 . fst) $ map (func1 other args) container को तर्कों के क्रम में मामूली बदलाव के साथ func1 5$#$ लिखा जा सकता है।

एल्म में .func को x->x.func द्वारा परिभाषित किया गया है और यह बहुत उपयोगी है, एल्म रिकॉर्ड देखें। इस सिंटैक्स को map के लिए लेने से पहले इस पर विचार किया जाना चाहिए।

मुझे वह पसंद है।

हालाँकि जूलिया में फील्ड एक्सेस इतनी बड़ी बात नहीं है जितनी कि कई भाषाओं में।

हां, यह यहां कम प्रासंगिक लगता है क्योंकि जूलिया के क्षेत्र "निजी" उपयोग के लिए अधिक हैं। लेकिन ओवरलोडिंग फील्ड एक्सेस के बारे में चल रही चर्चा के साथ, यह और अधिक समझदार हो सकता है।

f.(x) कम समस्याग्रस्त समाधान की तरह दिखता है, अगर यह विषमता के लिए नहीं था .+ । लेकिन . के प्रतीकात्मक जुड़ाव को "तत्व-वार संचालन" में रखना IMHO का एक अच्छा विचार है।

यदि वर्तमान टाइप किए गए सरणी निर्माण को बहिष्कृत किया जा सकता है, तो func[v...] का अनुवाद map(func, v...) में किया जा सकता है, और लिटरल सरणी को T[[a1, ..., an]] (वर्तमान T[a1, ..., an] के बजाय) लिखा जा सकता है

मुझे sin∘v शांत प्राकृतिक भी मिलता है (जब एक सरणी v को इंडेक्स से निहित मानों के लिए एक एप्लिकेशन देखा जाता है), या अधिक सरल रूप से sin*v या v*[sin]' ( जिसके लिए *(x, f::Callable) ) आदि को परिभाषित करने की आवश्यकता है।

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

.( फ़ंक्शन कॉल ऑपरेटर होने का विचार मुझे बहुत दुखी करता है।

@johnmyleswhite केयर विस्तृत करने के लिए? मैं वाक्य रचना की सहजता के बारे में बात कर रहा था, या यह बाकी भाषा के साथ दृश्य स्थिरता है, तकनीकी कार्यान्वयन के बारे में बिल्कुल नहीं।

मेरे लिए, ( भाषा के शब्दार्थ का बिल्कुल भी हिस्सा नहीं है: यह सिर्फ वाक्य रचना का हिस्सा है। इसलिए मैं अलग-अलग शुरू करने के लिए .( और ( के लिए कोई रास्ता नहीं खोजना चाहता। क्या पूर्व $#$ call Expr $#$ के बजाय multicall Expr उत्पन्न करता है?

नहीं, जैसा कि मैंने कहा कि मैं बिल्कुल नहीं कह रहा था कि दो अलग-अलग कॉल ऑपरेटर होने चाहिए। तत्व-वार संचालन के लिए बस एक _visually_ संगत वाक्यविन्यास खोजने का प्रयास कर रहा है।

मेरे लिए इन विकल्पों को क्या मारता है यह सवाल है कि बहु-तर्क कार्यों को कैसे सदिश किया जाए। ऐसा करने का कोई एक तरीका नहीं है और हर संभव तरीके से समर्थन करने के लिए पर्याप्त सामान्य कुछ भी हमारे पास पहले से मौजूद बहुआयामी सरणी समझ की तरह दिखने लगता है।

सभी तर्कों पर पुनरावृति करने के लिए बहु-तर्क map के लिए यह काफी मानक है।
अगर हमने ऐसा किया तो मैं .( कॉल टू मैप के लिए सिंटैक्स। वह सिंटैक्स हो सकता है
विभिन्न कारणों से इतना अच्छा नहीं हो सकता, लेकिन मैं इन पहलुओं के साथ ठीक रहूंगा।

तथ्य यह है कि बहु-तर्क कार्यों के लिए कई सामान्यीकरण संभव हैं, कम से कम कुछ विशेष मामलों का समर्थन करने के खिलाफ तर्क नहीं हो सकता है - जैसे मैट्रिक्स ट्रांसपोज़ उपयोगी होता है, भले ही इसे टेंसर के लिए कई तरीकों से सामान्यीकृत किया जा सके।

हमें बस सबसे उपयोगी समाधान चुनने की जरूरत है। संभावित विकल्पों पर पहले ही यहां चर्चा की जा चुकी है: https://github.com/JuliaLang/julia/issues/8389#issuecomment -55953120 (और निम्नलिखित टिप्पणियां)। जैसा कि @JeffBezanson ने कहा कि map का वर्तमान व्यवहार उचित है। एक दिलचस्प मानदंड @vectorize_2arg को बदलने में सक्षम होना है।

मेरा कहना यह है कि sin.(x) और x .+ y सह-अस्तित्व होना अजीब है। मेरे पास .sin(x) -> map(sin, x) और x .+ y -> map(+, x, y) होगा।

.+ वास्तव में broadcast का उपयोग करता है।

कुछ अन्य विचार, शुद्ध हताशा से बाहर:

1. अधिभार बृहदान्त्र, sin:x । कई तर्कों के लिए अच्छी तरह से सामान्यीकरण नहीं करता है।
2. sin.[x] --- यह वाक्य रचना उपलब्ध है, वर्तमान में अर्थहीन है।
3. sin@x --- उपलब्ध नहीं है, लेकिन संभव हो सकता है

मैं वास्तव में आश्वस्त नहीं हूं कि हमें इसकी आवश्यकता है।

न ही मैं। मुझे लगता है कि f.(x) यहां सबसे अच्छा विकल्प है, लेकिन मुझे यह पसंद नहीं है।

लेकिन इसके बिना हम सभी प्रकार के वेक्टरकृत कार्यों को बनाने से कैसे बच सकते हैं, विशेष रूप से int() जैसी चीजों में? इसने मुझे https://github.com/JuliaLang/julia/issues/8389 में यह चर्चा शुरू करने के लिए प्रेरित किया।

हमें लोगों को map(func, x) का उपयोग करने के लिए प्रोत्साहित करना चाहिए। यह इतना टाइपिंग नहीं है और यह किसी अन्य भाषा से आने वाले किसी भी व्यक्ति के लिए तुरंत स्पष्ट है।

और हां, सुनिश्चित करें कि यह तेज़ है।

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

एक और समस्या संगति है: जब तक आप log , exp , आदि सहित सभी वर्तमान वेक्टरकृत कार्यों को हटाने के लिए तैयार नहीं हैं, और लोगों से इसके बजाय map का उपयोग करने के लिए कहें (जो हो सकता है इस निर्णय की व्यावहारिकता का एक दिलचस्प परीक्षण), भाषा असंगत होने जा रही है, जिससे यह जानना मुश्किल हो जाता है कि कोई फ़ंक्शन वेक्टरकृत है या नहीं (और किस तर्क पर)।

कई अन्य भाषाएं वर्षों से map का उपयोग कर रही हैं।

जैसा कि मैंने सब कुछ वेक्टरिंग को रोकने की योजना को समझा, अधिकांश/सभी वेक्टरकृत कार्यों को हटाना हमेशा रणनीति का हिस्सा था।

हां, _course_ के हम सब कुछ वेक्टर करना बंद कर देंगे। असंगति पहले से ही है: यह जानना पहले से ही कठिन है कि कौन से फ़ंक्शन वेक्टरकृत हैं या होने चाहिए, क्योंकि वास्तव में कोई ठोस कारण नहीं है कि क्यों sin , exp आदि को सरणियों पर निहित रूप से मैप किया जाना चाहिए।

और पुस्तकालय के लेखकों को सभी उपयुक्त कार्यों पर @vectorize लगाने के लिए कहना मूर्खतापूर्ण है; आपको केवल एक फ़ंक्शन लिखने में सक्षम होना चाहिए, और यदि कोई इसे प्रत्येक तत्व के लिए गणना करना चाहता है तो वे map का उपयोग करते हैं।

आइए कल्पना करें कि यदि हम आमतौर पर उपयोग किए जाने वाले वेक्टरकृत गणित कार्यों को हटा दें तो क्या होगा:

1. व्यक्तिगत रूप से, मुझे $#$ exp(x) $#$ के बजाय map(exp, x) लिखने में कोई आपत्ति नहीं है, भले ही बाद वाला थोड़ा छोटा और साफ-सुथरा हो। हालांकि, प्रदर्शन में एक _बड़ा_ अंतर मौजूद है। मेरी मशीन पर मानचित्र की तुलना में वेक्टरकृत कार्य लगभग 5x तेज है।
2. जब आप मिश्रित भावों के साथ काम कर रहे होते हैं, तो समस्या अधिक दिलचस्प होती है। एक यौगिक व्यंजक पर विचार करें: exp(0.5 * abs2(x - y)) , तो हमारे पास है

# baseline: the shortest way
exp(0.5 * abs2(x - y))    # ... takes 0.03762 sec (for 10^6 elements)

# using map (very cumbersome for compound expressions)
map(exp, 0.5 * map(abs2, x - y))   # ... takes 0.1304 sec (about 3.5x slower)

# using anonymous function (shorter for compound expressions)
map((u, v) -> 0.5 * exp(abs2(u - v)), x, y)   # ... takes 0.2228 sec (even slower, about 6x baseline)

# using array comprehension (we have to deal with two array arguments)

# method 1:  using zip to combine the arguments (readability not bad)
[0.5 * exp(abs2(u - v)) for (u, v) in zip(x, y)]  # ... takes 0.140 sec, comparable to using map

# method 2:  using index, resulting in a slightly longer statement
[0.5 * exp(abs2(x[i] - y[i])) for i = 1:length(x)]  # ... takes 0.016 sec, 2x faster than baseline 

यदि हम वेक्टरकृत गणित कार्यों को हटाने जा रहे हैं, तो पठनीयता और प्रदर्शन दोनों में स्वीकार्य एकमात्र तरीका सरणी समझ है। फिर भी, वे वेक्टरकृत गणित की तरह सुविधाजनक नहीं हैं।

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

ये आधार में हैं या नहीं यह एक अलग चर्चा और एक बड़ी चर्चा है, लेकिन आवश्यकता वास्तविक है और प्रदर्शन हमारे पास जो है उससे अधिक हो सकता है।

@lindahua और @ViralBShah : आपकी कुछ चिंताएं इस धारणा पर आधारित प्रतीत होती हैं कि हम map में सुधार करने से पहले वेक्टरकृत कार्यों से छुटकारा पा लेंगे, लेकिन मुझे विश्वास नहीं है कि किसी ने ऐसा करने का प्रस्ताव दिया है।

मुझे लगता है कि @lindahua का उदाहरण काफी बता रहा है: वेक्टरकृत वाक्यविन्यास अन्य समाधानों की तुलना में गणित के फार्मूले के बहुत अच्छे और बहुत करीब है। मुझे इसे खोना काफी बुरा होगा, और अन्य वैज्ञानिक भाषाओं से आने वाले लोग शायद इसे जूलिया में एक नकारात्मक बिंदु मानने जा रहे हैं।

मैं सभी वेक्टरकृत कार्यों को हटाने के साथ ठीक हूं (जब map पर्याप्त तेज़ है), और देखें कि यह कैसा चल रहा है। मेरा मानना ​​​​है कि सुविधा सिंटैक्स प्रदान करने की रुचि उस बिंदु पर और भी अधिक दिखाई देगी, और यह अभी भी इसे जोड़ने का समय होगा यदि यह पता चलता है कि यह मामला है।

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

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

y = exp(x) और . की तुलना करना

for i = 1:length(x)
    y[i] = exp(x[i])
end

पूर्व स्पष्ट रूप से बाद वाले की तुलना में बहुत अधिक संक्षिप्त और पठनीय है। तथ्य यह है कि जूलिया लूप को कुशल बनाती है इसका मतलब यह नहीं है कि हमें हमेशा कोड को वेक्टर करना चाहिए, जो मेरे लिए काफी प्रतिकूल है।

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

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

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

यदि नक्शा तेज होता, तो यह निश्चित रूप से हमें वेक्टरकृत कार्यों के एक छोटे और सार्थक सेट पर ध्यान केंद्रित करने देता।

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

मुझे वेक्टरकृत फ़ंक्शन पसंद नहीं हैं। यह छुपाता है कि क्या हो रहा है। कार्यों के वेक्टरकृत संस्करण बनाने की यह आदत रहस्य कोड की ओर ले जाती है। मान लें कि आपके पास कुछ कोड है जहां एक पैकेज से एक फ़ंक्शन f वेक्टर पर कॉल किया जाता है। यहां तक ​​​​कि अगर आपको कुछ पता है कि फ़ंक्शन क्या करता है, तो आप कोड को पढ़ने से सुनिश्चित नहीं हो सकते हैं कि यह तत्व-वार करता है या वेक्टर पर पूरी तरह से काम करता है। यदि वैज्ञानिक कंप्यूटिंग भाषाओं में इन वेक्टरकृत कार्यों का इतिहास नहीं होता तो मुझे नहीं लगता कि हम अब उन्हें स्वीकार करने के करीब होंगे।

यह उस स्थिति की ओर भी ले जाता है जहां आपको फ़ंक्शन के वेक्टरकृत संस्करण लिखने के लिए प्रोत्साहित किया जाता है ताकि संक्षिप्त कोड को सक्षम किया जा सके जहां फ़ंक्शन का उपयोग किया जाता है।

जो कोड चल रहा है उसके बारे में सबसे स्पष्ट है, वह लूप है, लेकिन जैसा कि @lindahua कहते हैं कि यह बहुत ही वर्बोज़ होता है, जिसकी अपनी डाउनसाइड्स होती है, खासकर ऐसी भाषा में जो इंटरैक्टिव उपयोग के लिए भी होती है।

यह map समझौता की ओर ले जाता है, जो मुझे लगता है कि आदर्श के करीब है, लेकिन मैं अभी भी @lindahua से सहमत हूं कि यह पर्याप्त नहीं है।

जहां मैं @lindahua से असहमत हूं, वह यह है कि वेक्टरकृत कार्य सबसे अच्छे विकल्प हैं, जिन कारणों से मैंने पहले उल्लेख किया था। मेरा तर्क यह है कि जूलिया के पास map के लिए एक बहुत ही संक्षिप्त अंकन होना चाहिए।

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

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

यह सब, निश्चित रूप से, map पर सशर्त है और अनाम कार्य तेजी से हो रहे हैं। अभी जूलिया अजीब स्थिति में है। यह वैज्ञानिक कंप्यूटिंग भाषाओं में मामला हुआ करता था कि फ़ंक्शन वेक्टरकृत होते थे क्योंकि लूप धीमे होते हैं। ये कोई समस्या नहीं है। इसके बजाय, जूलिया में, आपने कार्यों को वेक्टर किया क्योंकि मानचित्र और अनाम कार्य धीमे हैं। इसलिए हम वहीं वापस आ गए हैं जहां से हमने शुरुआत की थी, लेकिन अलग-अलग कारणों से।

वेक्टरकृत पुस्तकालय कार्यों का एक नुकसान है - पुस्तकालय द्वारा स्पष्ट रूप से प्रदान किए गए केवल वे कार्य उपलब्ध हैं। यही है, उदाहरण के लिए sin(x) एक वेक्टर पर लागू होने पर तेज़ होता है, जबकि sin(2*x) अचानक बहुत धीमा होता है क्योंकि इसके लिए एक मध्यवर्ती सरणी की आवश्यकता होती है जिसे दो बार ट्रैवर्स करने की आवश्यकता होती है (पहले लेखन, फिर पढ़ना)।

एक समाधान वेक्टरिज़ेबल गणित कार्यों का पुस्तकालय होगा। ये sin , cos , आदि के कार्यान्वयन होंगे जो इनलाइनिंग के लिए LLVM के लिए उपलब्ध हैं। LLVM तब इस लूप को वेक्टराइज़ कर सकता है, और उम्मीद है कि बहुत ही कुशल कोड की ओर ले जाएगा। लगता है कि येप्प के पास सही लूप कर्नेल है, लेकिन ऐसा लगता है कि उन्हें इनलाइनिंग के लिए बेनकाब नहीं किया गया है।

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

इसे @eschnett के बिंदु के साथ मिलाएं और आपको यह मिलता है:

• वेक्टरकृत फ़ंक्शन केवल तभी काम करते हैं जब आप अपने आप को मानक पुस्तकालय में कार्यों तक सीमित रखते हैं
• वेक्टरकृत फ़ंक्शन केवल तभी काम करते हैं जब आप अपने आप को मानक पुस्तकालय में कंटेनर प्रकारों तक सीमित रखते हैं

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

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

यहाँ मेरे मन में है, जो @eschnett की टिप्पणियों से प्रेरित है:

# The <strong i="11">@vec</strong> macro tags the function that follows as vectorizable
<strong i="12">@vec</strong> abs2(x::Real) = x * x
<strong i="13">@vec</strong> function exp(x::Real) 
   # ... internal implementation ...
end

exp(2.0)  # simply calls the function

x = rand(100);
exp(x)    # maps exp to x, as exp is tagged as vectorizable

exp(abs2(x))  # maps v -> exp(abs2(v)), as this is applying a chain of vectorizable functions

सिमड का उपयोग करने के अवसर की पहचान करके संकलक गणना (निचले स्तर पर) को फिर से वेक्टर कर सकता है।

बेशक, @vec को अंतिम उपयोगकर्ता के लिए उपलब्ध कराया जाना चाहिए, ताकि लोग अपने स्वयं के कार्यों को वेक्टर करने योग्य घोषित कर सकें।

धन्यवाद, @ लिंडाहुआ : आपकी स्पष्टीकरण से बहुत मदद मिलती है।

क्या @vec फ़ंक्शन @pure घोषित करने से अलग होगा?

@vec इंगित करता है कि फ़ंक्शन को तत्व-वार तरीके से मैप किया जा सकता है।

सभी शुद्ध कार्य इस श्रेणी में नहीं आते हैं, उदाहरण के लिए sum एक शुद्ध कार्य है, और मुझे नहीं लगता कि इसे _vectorizable_ के रूप में घोषित करना उचित है।

pure से pure vec की sum की संपत्ति और + पर + associative टैग के साथ-साथ reduce के बारे में ज्ञान के साथ कोई पुनः प्राप्त नहीं कर सका foldl / foldr काम करते हैं जब pure और associative फ़ंक्शन दिए जाते हैं? जाहिर है कि यह सब काल्पनिक है, लेकिन क्या जूलिया सभी प्रकार के लक्षणों पर जाने के लिए थी, मैं कल्पना कर सकता था कि कार्यों के लिए सभी लक्षणों पर भी जाकर वैश्वीकरण के लिए कला की स्थिति में काफी सुधार हुआ है।

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

तो क्यों न एक संक्षिप्त इन्फिक्स map ऑपरेटर जोड़ें? यहां मैं मनमाने ढंग से $ चुनूंगा। इससे @lindahua के उदाहरण से जाना होगा

exp(0.5 * abs2(x - y))

प्रति

exp $ (0.5 * abs2 $ (x-y))

अब, यदि हमारे पास उपयोगकर्ता परिभाषित इनफिक्स ऑपरेटरों के लिए केवल हास्केल जैसा समर्थन है, तो यह केवल एक पंक्ति परिवर्तन ($) = map होगा। :)

आईएमओ, अन्य वाक्यविन्यास प्रस्ताव मौजूदा वाक्यविन्यास के बहुत करीब हैं, और कोड को देखते समय पार्स करने के लिए और मानसिक प्रयास की आवश्यकता होगी:

• foo.(x) -- दिखने में मानक प्रकार के सदस्य पहुंच के समान
• foo[x] -- क्या मैं foo सरणी के x-वें सदस्य तक पहुंच रहा हूं या यहां मानचित्र पर कॉल कर रहा हूं?
• .foo(x) -- में समस्या है जैसा कि @kmsquire ने बताया

और मुझे लगता है कि @vec समाधान @vectorize के बहुत करीब है जिसे हम पहले स्थान पर टालने की कोशिश कर रहे हैं। निश्चित रूप से, कुछ एनोटेशन ala #8297 के लिए अच्छा होगा और भविष्य में मदद कर सकता है, स्मार्ट कंपाइलर तब इन स्ट्रीम फ़्यूज़न अवसरों को पहचान सकता है और तदनुसार अनुकूलित कर सकता है। लेकिन मुझे जबरदस्ती करने का विचार पसंद नहीं है।

इंफिक्स मैप और तेजी से अनाम कार्य भी अस्थायी बनाने में मदद कर सकते हैं यदि यह आपको कुछ ऐसा करने की अनुमति देता है:

(x, y) -> exp(0.5 * abs2(x - y)) $ x, y

मुझे आश्चर्य है कि क्या किसी फ़ंक्शन को वेक्टर करने योग्य नामित करने के संदर्भ में शांत नए Trait.jl से विचार उधार लिया जा सकता है। बेशक, इस मामले में हम Function प्रकार के अलग-अलग _instances_ को देख रहे हैं जो एक विशिष्ट विशेषता वाले जूलिया प्रकार के बजाय वेक्टर करने योग्य है या नहीं।

अब, यदि हमारे पास उपयोगकर्ता परिभाषित इंफिक्स ऑपरेटरों के लिए केवल हास्केल जैसा समर्थन है

6582 #6929 पर्याप्त नहीं है?

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

y =  √π exp(-x^2) * sin(k*x) + im * log(x-1)

और इसे जादुई रूप से वेक्टराइज़ करें

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

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

दुर्भाग्य से, इस तरह के कार्यान्वयन हार्डवेयर पर निर्भर होंगे, यानी किसी को अलग-अलग एल्गोरिदम या अलग-अलग कार्यान्वयन चुनना पड़ सकता है, जो इस बात पर निर्भर करता है कि कौन से हार्डवेयर निर्देश कुशल हैं। मैंने इसे अतीत में (https://bitbucket.org/eschnett/vecmathlib/wiki/Home) C++ में किया है, और थोड़े अलग लक्षित दर्शकों के साथ (स्टैंसिल-आधारित संचालन जो ऑटो-वेक्टराइजिंग के बजाय मैन्युअल रूप से वेक्टरकृत होते हैं संकलक)।

यहां जूलिया में, चीजें आसान होंगी क्योंकि (ए) हम जानते हैं कि कंपाइलर एलएलवीएम होगा, और (बी) हम इसे सी ++ (मैक्रोज़ बनाम टेम्पलेट्स) के बजाय जूलिया में लागू कर सकते हैं।

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

मुझे जूलिया में एक वेक्टरिज़ेबल exp प्रोटोटाइप तैयार करने दें। फिर हम देख सकते हैं कि LLVM लूप को वेक्टराइज़ करने पर कैसे करता है, और हमें कौन सी गति प्राप्त होती है।

क्या फ़ंक्शन के तर्क के आसपास पूर्ण-चौड़ाई वाले कोष्ठक का उपयोग करना बहुत डरावना है~

क्षमा करें, मुझे एहसास नहीं हुआ कि मैं वही बात दोहरा रहा था @johnmyleswhite विशेषता के साथ फिर से कार्य के ऊपर बात कर रहा था। लगे रहो।

@eschnett मुझे नहीं लगता कि कार्यान्वयन विवरण (फ़ंक्शन कैसे संकलित किया जाता है) के लिए एपीआई (चाहे फ़ंक्शन वेक्टरिज़ेबल हैं या नहीं) को लिंक करना उचित है। यह समझने और समय और आर्किटेक्चर में स्थिर रखने के लिए काफी जटिल लगता है, और बाहरी पुस्तकालयों में फ़ंक्शन को कॉल करते समय यह काम नहीं करेगा, उदाहरण के लिए log को वेक्टरिज़ेबल के रूप में नहीं पहचाना जाएगा क्योंकि openlibm से फ़ंक्शन कॉल करता है।

OTOH @johnmyleswhite किसी फ़ंक्शन के गणितीय गुण क्या हैं, यह बताने के लिए लक्षणों का उपयोग करने का विचार एक बेहतरीन समाधान हो सकता है। ( @lindahua का प्रस्ताव एक विशेषता है जिसे मैंने कुछ समय पहले कहीं सुझाया था, लेकिन लक्षणों का उपयोग करने का समाधान और भी बेहतर हो सकता है।)

अब, यदि हमारे पास उपयोगकर्ता परिभाषित इंफिक्स ऑपरेटरों के लिए केवल हास्केल जैसा समर्थन है

6582 #6929 पर्याप्त नहीं है?

मुझे कहना चाहिए था: ... उपयोगकर्ता परिभाषित _गैर-यूनिकोड_ इंफिक्स ऑपरेटर, क्योंकि मुझे नहीं लगता कि हम उपयोगकर्ताओं को इस तरह की मुख्य कार्यक्षमता तक पहुंचने के लिए यूनिकोड वर्ण टाइप करना चाहते हैं। हालांकि मैं देख रहा हूं कि $ वास्तव में उनमें से एक जोड़ा गया है, इसलिए इसके लिए धन्यवाद! वाह, तो यह वास्तव में जूलिया _today_ में काम करता है (भले ही यह "तेज़" न हो ... अभी तक):

julia> ($) = map
julia> sin $ (0.5 * (abs2 $ (x-y)))

मुझे नहीं पता कि यह map के लिए सबसे अच्छा विकल्प है या नहीं, लेकिन $ के लिए xor का उपयोग करना वास्तव में बर्बादी जैसा लगता है। बिटवाइज़ xor का उपयोग अक्सर नहीं किया जाता है। map अधिक महत्वपूर्ण है।

ऊपर @jiahao का बिंदु एक बहुत अच्छा है: व्यक्तिगत वेक्टरकृत कार्य जैसे exp वास्तव में वेक्टरकृत _expressions_ प्राप्त करने के लिए एक हैक की तरह हैं exp(-x^2) । सिंटैक्स जो @devec जैसा कुछ करता है वह वास्तव में मूल्यवान होगा: आपको विचलित प्रदर्शन और वेक्टरकृत के रूप में व्यक्तिगत रूप से कार्यों की पहचान करने की आवश्यकता नहीं होने की व्यापकता मिल जाएगी।

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

मैं सहमत हूं कि यह फ़ंक्शन की संपत्ति नहीं है, यह फ़ंक्शन के उपयोग की संपत्ति है। लक्षण लागू करने की चर्चा गलत पेड़ के भौंकने के मामले की तरह लगती है।

ब्रेनस्टॉर्मिंग: आप उन तर्कों को कैसे चिह्नित करते हैं जिन्हें आप मैप करना चाहते हैं ताकि यह बहु-आर्ग मैपिंग का समर्थन करे:

a = split("the quick brown")
b = split("fox deer bear")
c = split("jumped over the lazy")
d = split("dog cat")
e = string(a, " ", b., " ", c, " ", d.) # -> 3x2 Vector{String} of the combinations   
# e[1,1]: """["the","quick", "brown"] fox ["jumped","over","the","lazy"] dog"""

मुझे यकीन नहीं है कि .b या b. यह दिखाने के लिए बेहतर है कि आप मैप करना चाहते हैं। मुझे इस मामले में एक बहु-आयामी 3x2 परिणाम वापस करना पसंद है क्योंकि यह map पिंग के आकार का प्रतिनिधित्व करता है।

कंदरा

यहाँ https://github.com/eschnett/Vecmathlib.jl एक नमूना के साथ एक रेपो है
exp का कार्यान्वयन, इस तरह से लिखा गया है जिसे LLVM द्वारा अनुकूलित किया जा सकता है।
यह कार्यान्वयन मानक exp . से लगभग दोगुना तेज़ है
मेरे सिस्टम पर कार्यान्वयन। यह (शायद) अभी तक येप्प की गति तक नहीं पहुँच पाया है,
शायद इसलिए कि LLVM संबंधित SIMD लूप को इस प्रकार अनियंत्रित नहीं करता है
आक्रामक रूप से Yeppp के रूप में। (मैंने अलग किए गए निर्देशों की तुलना की।)

एक वेक्टर करने योग्य exp फ़ंक्शन लिखना आसान नहीं है। इसका उपयोग इस तरह दिखता है:

function kernel_vexp2{T}(ni::Int, nj::Int, x::Array{T,1}, y::Array{T,1})
    for j in 1:nj
        <strong i="16">@simd</strong> for i in 1:ni
            <strong i="17">@inbounds</strong> y[i] += vexp2(x[i])
        end
    end
end

जहां j लूप और फ़ंक्शन तर्क केवल के लिए हैं
बेंचमार्किंग उद्देश्यों।

क्या जूलिया के लिए कोई @unroll मैक्रो है?

-एरिको

2 नवंबर, 2014 को रात 8:26 बजे, टिम होली नोटिफिकेशन @github.com ने लिखा:

मैं सहमत हूं कि यह फ़ंक्शन की संपत्ति नहीं है, यह की संपत्ति है
समारोह का उपयोग। लक्षण लागू करने के बारे में चर्चा एक की तरह लगती है
गलत पेड़ को काटने का मामला

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

एरिक श्नेटर [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

व्यक्तिगत वेक्टरकृत कार्य जैसे exp वास्तव में वेक्टरकृत _expressions_ प्राप्त करने के लिए एक हैक की तरह हैं exp(-x^2)

स्केलर डोमेन से संपूर्ण भावों को उठाने के लिए कोर सिंटैक्स बहुत दिलचस्प होगा। वैश्वीकरण एक उदाहरण है (जहां लक्ष्य डोमेन वैक्टर है); एक और दिलचस्प उपयोग का मामला मैट्रिक्स डोमेन (#5840) में उठाना होगा जहां शब्दार्थ काफी अलग हैं। मैट्रिक्स डोमेन में यह पता लगाना भी उपयोगी होगा कि विभिन्न अभिव्यक्तियों पर प्रेषण कैसे काम कर सकता है, क्योंकि सामान्य स्थिति में आप शूर-पैरलेट और अन्य विशिष्ट एल्गोरिदम चाहते हैं यदि आप sqrtm जैसे कुछ आसान चाहते हैं। (और चतुर वाक्य रचना के साथ आप पूरी तरह से *m कार्यों से छुटकारा पा सकते हैं - expm , logm , sqrtm , ...)

क्या जूलिया के लिए कोई @unroll मैक्रो है?

बेस.कार्टेशियन का उपयोग करना
@nexpr 4 d->(y[i+d] = exp(x[i+d])

(यदि आपके कोई प्रश्न हैं तो http://docs.julialang.org/en/latest/devdocs/cartesian/ देखें।)

@jiahao इसे मैट्रिक्स फ़ंक्शंस में सामान्यीकृत करना एक दिलचस्प चुनौती की तरह लगता है, लेकिन इसके बारे में मेरा ज्ञान शून्य के करीब है। क्या आपके पास कोई विचार है कि यह कैसे काम करेगा? इसे वैश्वीकरण के साथ कैसे जोड़ा जाएगा? सिंटैक्स वेक्टर/मैट्रिक्स पर exp तत्व-वार लागू करने और इसके मैट्रिक्स घातीय की गणना करने के बीच अंतर करने की अनुमति कैसे देगा?

@timholy : धन्यवाद! मैंने अनियंत्रित करने के लिए कार्टेशियन का उपयोग करने के बारे में नहीं सोचा था।

दुर्भाग्य से, @nexprs (या मैन्युअल अनोलिंग द्वारा) द्वारा निर्मित कोड अब वेक्टरकृत नहीं है। (यह एलएलवीएम 3.3 है, शायद एलएलवीएम 3.5 बेहतर होगा।)

पुन: अनियंत्रित, जूलिया-उपयोगकर्ताओं पर @toivoh की पोस्ट भी देखें। यह #6271 एक शॉट देने लायक भी हो सकता है।

@nalimilan मैंने अभी तक इसके बारे में नहीं सोचा है, लेकिन स्केलर-> मैट्रिक्स लिफ्टिंग एक matrixfunc फ़ंक्शन (कहें) के साथ कार्यान्वित करना काफी आसान होगा। एक काल्पनिक वाक्य रचना (पूरी तरह से कुछ बनाना) हो सकता है

X = randn(10,10)
c = 0.7
lift(x->exp(c*x^2)*sin(x), X)

जो तब होगा

1. X प्रकार Matrix{Float64} से लिफ्ट के स्रोत और लक्ष्य डोमेन की पहचान करें और तत्व (प्रकार पैरामीटर) Float64 (इस प्रकार एक Float64 => Matrix{Float64} लिफ्ट को स्पष्ट रूप से परिभाषित करें) , फिर
2. matrixfunc(x->exp(c*x^2)*sin(x), X) के बराबर की गणना करने के लिए expm(c*X^2)*sinm(X) पर कॉल करें, लेकिन मैट्रिक्स को गुणा करने से बचें।

कुछ अन्य कोड में X एक Vector{Int} हो सकता है और निहित भारोत्तोलन Int से Vector{Int} होगा, और फिर lift(x->exp(c*x^2)*sin(x), X) तब हो सकता है map(x->exp(c*x^2)*sin(x), X) पर कॉल करें।

कोई अन्य तरीकों की भी कल्पना कर सकता है जो स्पष्ट रूप से स्रोत और लक्ष्य डोमेन निर्दिष्ट करते हैं, उदाहरण के लिए lift(Number=>Matrix, x->exp(c*x^2)*sin(x), X) ।

@nalimilan वेक्टराइजेशन वास्तव में एपीआई की संपत्ति नहीं है। आज की कंपाइलर तकनीक के साथ, किसी फ़ंक्शन को केवल इनलाइन होने पर ही वेक्टरकृत किया जा सकता है। चीजें ज्यादातर फ़ंक्शन कार्यान्वयन पर निर्भर करती हैं - यदि इसे "सही तरीके से" लिखा गया है, तो संकलक इसे वेक्टर कर सकता है (इसे आसपास के लूप में रेखांकित करने के बाद)।

@eschnett : क्या आप दूसरों के समान वैश्वीकरण के समान अर्थ का उपयोग कर रहे हैं? ऐसा लगता है कि आप सिमड इत्यादि के बारे में हैं, जो कि मैं @nalimilan को समझने के लिए नहीं समझता हूं।

सही। यहाँ वैश्वीकरण की दो अलग-अलग धारणाएँ हैं। एक सौदा
तंग आंतरिक छोरों (प्रोसेसर वैश्वीकरण) के लिए SIMD प्राप्त करने के साथ। मुख्य
यहां जिस मुद्दे पर चर्चा की जा रही है वह किसी भी तरह "स्वचालित रूप से" वाक्यविन्यास/शब्दार्थ है
संग्रह पर एकल (या बहु) तर्क फ़ंक्शन को कॉल करने में सक्षम होने के नाते।

मंगलवार, 4 नवंबर, 2014 को शाम 7:04 बजे, जॉन माइल्स व्हाइट नोटिफिकेशन @github.com
लिखा था:

@eschnett https://github.com/eschnett : क्या आप एक ही अर्थ का उपयोग कर रहे हैं
दूसरों के रूप में वैश्वीकरण का? ऐसा लगता है कि आप SIMD वगैरह के बारे में हैं, जो
वह नहीं है जो मैं समझता हूं @nalimilan https://github.com/nalimilan to
अर्थ।

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

अन्य . ऑपरेटरों के समरूपता में, क्या f.(x) मूल्यों के संग्रह के लिए कार्यों के संग्रह को लागू नहीं करना चाहिए? (उदाहरण के लिए, कुछ nd इकाई समन्वय प्रणाली से भौतिक निर्देशांक में बदलने के लिए।)

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

यहाँ मुद्दों के दो स्तर हैं: (1) वाक्य रचना और शब्दार्थ, (2) कार्यान्वयन।

वाक्य रचना और शब्दार्थ का मुद्दा इस बारे में है कि उपयोगकर्ता दिए गए सरणियों के लिए तत्व-वार/प्रसारण तरीके से कुछ गणनाओं को मैप करने के इरादे को कैसे व्यक्त कर सकता है। वर्तमान में, जूलिया दो तरीकों का समर्थन करती है: वेक्टरकृत कार्यों का उपयोग करना और उपयोगकर्ताओं को स्पष्ट रूप से लूप लिखने की अनुमति देना (कभी-कभी मैक्रोज़ की सहायता से)। कोई भी रास्ता आदर्श नहीं है। जबकि वेक्टरकृत फ़ंक्शन किसी को exp(0.5 * (x - y).^2) जैसे बहुत संक्षिप्त अभिव्यक्ति लिखने की अनुमति देते हैं, उनके पास दो समस्याएं हैं: (1) यह एक रेखा खींचना मुश्किल है कि कौन से फ़ंक्शन वेक्टरकृत संस्करण प्रदान करें और कौन से नहीं, इस प्रकार अक्सर परिणामी डेवलपर पक्ष पर अंतहीन बहस और उपयोगकर्ता पक्ष पर भ्रम में (आपको अक्सर यह पता लगाने के लिए डॉक्टर को देखना होगा कि कुछ फ़ंक्शन वेक्टरकृत हैं या नहीं)। (2) यह कार्य सीमाओं के पार लूपों को फ्यूज करना मुश्किल बनाता है। इस बिंदु पर और शायद आने वाले कई महीनों/वर्षों में, संकलक शायद इस तरह के जटिल कार्यों को करने में सक्षम नहीं होगा जैसे कई कार्यों को एक साथ देखना, संयुक्त डेटा प्रवाह की पहचान करना, और फ़ंक्शन सीमाओं में अनुकूलित कोड पथ तैयार करना।

map फ़ंक्शन का उपयोग करने से समस्या (1) यहां हल हो जाती है। हालाँकि, यह अभी भी समस्या को हल करने में कोई मदद नहीं करता है (2) - फ़ंक्शंस का उपयोग करके, या तो एक विशिष्ट वेक्टरकृत फ़ंक्शन या एक सामान्य map , हमेशा एक फ़ंक्शन सीमा बनाता है जो लूप्स के फ़्यूज़िंग को बाधित करता है, जो उच्च प्रदर्शन गणना में महत्वपूर्ण है। मैप फ़ंक्शन का उपयोग करने से वर्बोसिटी भी हो जाती है, उदाहरण के लिए ऊपर दिया गया एक्सप्रेशन अब map(exp, 0.5 * map(abs2, x - y)) के रूप में एक लंबा स्टेटमेंट बन जाता है। आप तर्कसंगत रूप से कल्पना कर सकते हैं कि यह मुद्दा अधिक जटिल अभिव्यक्तियों के साथ बढ़ जाएगा।

इस सूत्र में उल्लिखित सभी प्रस्तावों में, मुझे व्यक्तिगत रूप से लगता है कि मैपिंग को इंगित करने के लिए विशेष नोटेशन का उपयोग करना आगे बढ़ने का सबसे आशाजनक तरीका है। सबसे पहले, यह अभिव्यक्ति की संक्षिप्तता बनाए रखता है। उदाहरण के लिए $-नोटेशन लें, ऊपर दिए गए भाव अब exp $(0.5 * abs2$(x - y)) के रूप में लिखे जा सकते हैं। यह मूल वेक्टरकृत अभिव्यक्ति की तुलना में थोड़ा लंबा है, लेकिन यह बहुत बुरा नहीं है - मैपिंग के प्रत्येक कॉल में $ डालने की आवश्यकता है। दूसरी ओर, यह संकेतन प्रदर्शन किए जा रहे मानचित्रण के एक स्पष्ट संकेतक के रूप में भी कार्य करता है, जिसका उपयोग संकलक फ़ंक्शन सीमा को तोड़ने और फ़्यूज्ड लूप का उत्पादन करने के लिए कर सकता है। इस पाठ्यक्रम में, कंपाइलर को फ़ंक्शन के आंतरिक कार्यान्वयन को देखने की आवश्यकता नहीं है - उसे केवल यह जानने की आवश्यकता है कि फ़ंक्शन को दिए गए सरणियों के प्रत्येक तत्व के लिए मैप किया जा रहा है।

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

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

@lindahua का सारांश एक अच्छा IMHO है।

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

• नेस्टेड फ़ंक्शन कॉल को एकल लूप में फ़्यूज़ करने का पैटर्न ऑपरेटरों पर भी लागू किया जाना चाहिए, ताकि A .* B .+ C दो अस्थायी के निर्माण की ओर न ले जाए, लेकिन परिणाम के लिए केवल एक।
• तत्व-वार कार्यों और कटौती के संयोजन को भी संभाला जाना चाहिए, ताकि प्रत्येक तत्व के मूल्य की गणना के बाद फ्लाई पर कमी को लागू किया जा सके। आम तौर पर, यह sumabs2(A) से छुटकारा पाने की अनुमति देगा, इसे sum(abs$(A)$^2) (या sum(abs.(A).^2) ) जैसे मानक नोटेशन के साथ बदल देगा।
• अंत में, गैर-मानक पुनरावृत्ति पैटर्न को गैर-मानक सरणियों के लिए समर्थित किया जाना चाहिए, ताकि विरल मैट्रिक्स के लिए A .* B को केवल गैर-शून्य प्रविष्टियों को संभालने की आवश्यकता हो, और एक विरल मैट्रिक्स देता है। यह तब भी उपयोगी होगा जब आप किसी तत्व-वार फ़ंक्शन को Set , a Dict , या यहां तक ​​कि Range पर लागू करना चाहते हैं।

दो अंतिम बिंदु तत्व-वार कार्यों को एक विशेष AbstractArray प्रकार बनाकर काम कर सकते हैं, मान लें कि LazyArray , जो मक्खी पर इसके तत्वों की गणना करेगा ( Transpose के समान) https://github.com/JuliaLang/julia/issues/4774#issuecomment-59422003) से टाइप करें। लेकिन 1 से length(A) तक रैखिक अनुक्रमणिका का उपयोग करके इसके तत्वों को भोलेपन से एक्सेस करने के बजाय, इटरेटर प्रोटोकॉल का उपयोग किया जा सकता है। किसी दिए गए प्रकार के लिए इटरेटर स्वचालित रूप से चुनता है कि प्रकार के भंडारण लेआउट के आधार पर पंक्ति-वार या स्तंभ-वार पुनरावृत्ति सबसे कुशल है या नहीं। और विरल मैट्रिक्स के लिए, यह शून्य प्रविष्टियों को छोड़ने की अनुमति देगा (मूल और परिणाम के लिए एक सामान्य संरचना की आवश्यकता होगी, cf। https://github.com/JuliaLang/julia/issues/7010, https://github। कॉम/जूलियालैंग/जूलिया/मुद्दों/7157)।

जब कोई कमी लागू नहीं की जाती है, तो मूल के समान प्रकार और आकार की एक वस्तु को केवल LazyArray ( collect के बराबर, लेकिन मूल सरणी के प्रकार का सम्मान करते हुए) पर पुनरावृति करके भर दिया जाएगा। ) इसके लिए केवल एक चीज की जरूरत है कि इटरेटर एक ऑब्जेक्ट देता है जिसका उपयोग getindex पर LazyArray और परिणाम पर setindex! पर कॉल करने के लिए किया जा सकता है (उदाहरण के लिए रैखिक या कार्टेशियन निर्देशांक)।

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

यह पूरी प्रणाली काफी सीधे तौर पर इन-प्लेस संचालन का भी समर्थन करेगी।

मैं सिंटैक्स को संबोधित करने पर थोड़ा सोच रहा था और सरणी में तत्व के संचालन को लागू करने के लिए .= के बारे में सोचा था।
तो @nalimilan का उदाहरण sum(abs.(A).^2)) दुर्भाग्य से दो चरणों में लिखा जाना होगा:

A = [1,2,3,4]
a .= abs(A)^2
result = sum(a)

यह पढ़ने में आसान होने का लाभ होगा और इसका मतलब यह होगा कि तत्व के कार्यों को केवल एक (या एकाधिक) इनपुट के लिए लिखा जाना चाहिए और सरणी विशिष्ट विधियों को लिखने के बजाय उस मामले के लिए अनुकूलित किया जाना चाहिए।

बेशक, प्रदर्शन और परिचित के अलावा और कुछ भी किसी को केवल map((x) -> abs(x)^2, A) लिखने से रोकता है जैसा कि कहा गया है।

वैकल्पिक रूप से, .() के साथ मैप की जाने वाली अभिव्यक्ति के आस-पास काम कर सकता है।
मुझे नहीं पता कि ऐसा करना कितना मुश्किल होगा लेकिन .sin(x) और .(x + sin(x)) फिर अभिव्यक्ति को कोष्ठक के अंदर या . का अनुसरण करने वाले फ़ंक्शन के अंदर मैप करेंगे।
यह तब @nalimilan के उदाहरण जैसे कटौती की अनुमति देगा जहां sum(.(abs(A)^2)) को एक पंक्ति में लिखा जा सकता है।

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

मैंने अपनी पिछली टिप्पणी में सामने आए LazyArray विचार के साथ प्रयोग किया है: https://gist.github.com/nalimilan/e737bc8b3b10288abdad

अवधारणा के इस प्रमाण में कोई वाक्यात्मक चीनी नहीं है, लेकिन (a ./ 2).^2 का अनुवाद सार में LazyArray(LazyArray(a, /, (2,)), ^, (2,)) के रूप में किया जाएगा। सिस्टम काफी अच्छी तरह से काम करता है, लेकिन प्रदर्शन के संबंध में लूप के साथ दूरस्थ रूप से प्रतिस्पर्धी होने के लिए इसे और अधिक अनुकूलन की आवश्यकता है। (अपेक्षित) समस्या यह प्रतीत होती है कि लाइन 12 पर फ़ंक्शन कॉल अनुकूलित नहीं है (लगभग सभी आवंटन वहां होते हैं), यहां तक ​​​​कि उस संस्करण में भी जहां अतिरिक्त तर्कों की अनुमति नहीं है। मुझे लगता है कि मुझे कॉल करने वाले फ़ंक्शन पर LazyArray को पैरामीट्रिज करने की आवश्यकता है, लेकिन मुझे नहीं पता कि मैं यह कैसे कर सकता हूं, अकेले तर्कों को भी संभालने दें। कोई विचार?

LazyArray के प्रदर्शन को बेहतर बनाने के बारे में कोई सुझाव?

@nalimilan मैंने एक साल पहले इसी तरह के दृष्टिकोण के साथ प्रयोग किया था, आलसी अभिव्यक्ति प्रकारों को पैरामीटर करने के लिए न्यूमेरिकफन में मज़ेदार प्रकारों का उपयोग करके। मैंने कई तरह के हथकंडे आजमाए, लेकिन प्रदर्शन के अंतर को पाटने का कोई सौभाग्य नहीं मिला।

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

@lindahua @inline समय पर कोई फर्क नहीं पड़ता है, जो मेरे लिए तार्किक है क्योंकि getindex(::LazyArray, ...) किसी दिए गए LazyArray हस्ताक्षर के लिए विशिष्ट है, जो निर्दिष्ट नहीं करता है कि कौन सा फ़ंक्शन होना चाहिए कहा जाना। मुझे LazyArray{T1, N, T2, F} की तरह कुछ चाहिए, F फ़ंक्शन के साथ जिसे कॉल किया जाना चाहिए, ताकि getindex को संकलित करते समय कॉल ज्ञात हो। क्या ऐसा करने का कोई तरीका है?

इनलाइनिंग अभी तक एक और बड़ा सुधार होगा, लेकिन इस समय समय एक गैर-इनलाइन कॉल से भी बहुत खराब है।

आप NumericFuns का उपयोग करने पर विचार कर सकते हैं और F एक मज़ेदार प्रकार हो सकता है।

Dahua

मुझे ऐसे कार्यों की आवश्यकता है जहां मैं वितरित के लिए रिटर्न प्रकार जानता हूं
कंप्यूटिंग, जहां मैं परिणाम से पहले परिणाम के संदर्भ बनाता हूं (और
इस प्रकार इसका प्रकार) जाना जाता है। मैंने खुद एक बहुत ही समान चीज़ लागू की है, और
जिसे आप "फ़ंक्टर्स" कहते हैं, उसका उपयोग करने के लिए शायद स्विच करना चाहिए। (मुझे पसंद नहीं है
नाम "मज़ेदार", क्योंकि वे आमतौर पर कुछ और होते हैं <
http://en.wikipedia.org/wiki/Functor>, लेकिन मुझे लगता है कि सी ++ ने पानी को गड़बड़ कर दिया
यहां।)

मुझे लगता है कि यह आपके फ़नक्टर भाग को से विभाजित करने के लिए समझ में आता है
गणितीय कार्य।

-एरिको

गुरु, 20 नवंबर, 2014 को सुबह 10:35 बजे, दहुआ लिन सूचनाएं @github.com
लिखा था:

आप न्यूमेरिकफन का उपयोग करने पर विचार कर सकते हैं और एफ एक मज़ेदार प्रकार हो सकता है।

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

एरिक श्नेटर [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

@ लिंडहुआ मैंने फ़ैक्टर का उपयोग करने की कोशिश की है, और वास्तव में प्रदर्शन अधिक उचित है:
https://gist.github.com/nalimilan/d345e1c080984ed4c89a

With functions:
# elapsed time: 3.235718017 seconds (1192272000 bytes allocated, 32.20% gc time)

With functors:
# elapsed time: 0.220926698 seconds (80406656 bytes allocated, 26.89% gc time)

Loop:
# elapsed time: 0.07613788 seconds (80187556 bytes allocated, 45.31% gc time) 

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

वास्तव में, ऊपर दिए गए परीक्षण में Pow उपयोग किया गया था, जो स्पष्ट रूप से इस बात पर निर्भर करता है कि आप एक स्पष्ट लूप लिखते हैं या LazyArray का उपयोग करते हैं। मुझे लगता है कि इसे निर्देशों के संलयन के साथ करना है जो केवल बाद के मामले में ही किया जाएगा। एक ही घटना जैसे जोड़ के साथ दिखाई दे रही है। लेकिन अन्य कार्यों के साथ अंतर बहुत छोटा है, या तो 100x100 या 1000x1000 मैट्रिक्स के साथ, संभवतः क्योंकि वे बाहरी हैं और इस प्रकार इनलाइनिंग से अधिक लाभ नहीं होता है:

# With sqrt()
julia> test_lazy!(newa, a);
julia> <strong i="8">@time</strong> for i in 1:1000 test_lazy!(newa, a) end
elapsed time: 0.151761874 seconds (232000 bytes allocated)

julia> test_loop_dense!(newa, a);
julia> <strong i="9">@time</strong> for i in 1:1000 test_loop_dense!(newa, a) end
elapsed time: 0.121304952 seconds (0 bytes allocated)

# With exp()
julia> test_lazy!(newa, a);
julia> <strong i="10">@time</strong> for i in 1:1000 test_lazy!(newa, a) end
elapsed time: 0.289050295 seconds (232000 bytes allocated)

julia> test_loop_dense!(newa, a);
julia> <strong i="11">@time</strong> for i in 1:1000 test_loop_dense!(newa, a) end
elapsed time: 0.191016958 seconds (0 bytes allocated)

इसलिए मैं यह जानना चाहता हूं कि LazyArray के साथ अनुकूलन क्यों नहीं होता है। सरल संचालन के लिए उत्पन्न असेंबली काफी लंबी है। उदाहरण के लिए, x/2 + 3 के लिए:

julia> a1 = LazyArray(a, Divide(), (2.0,));

julia> a2 = LazyArray(a1,  Add(), (3.0,));

julia> <strong i="17">@code_native</strong> a2[1]
    .text
Filename: none
Source line: 1
    push    RBP
    mov RBP, RSP
Source line: 1
    mov RAX, QWORD PTR [RDI + 8]
    mov RCX, QWORD PTR [RAX + 8]
    lea RDX, QWORD PTR [RSI - 1]
    cmp RDX, QWORD PTR [RCX + 16]
    jae L64
    mov RCX, QWORD PTR [RCX + 8]
    movsd   XMM0, QWORD PTR [RCX + 8*RSI - 8]
    mov RAX, QWORD PTR [RAX + 24]
    mov RAX, QWORD PTR [RAX + 16]
    divsd   XMM0, QWORD PTR [RAX + 8]
    mov RAX, QWORD PTR [RDI + 24]
    mov RAX, QWORD PTR [RAX + 16]
    addsd   XMM0, QWORD PTR [RAX + 8]
    pop RBP
    ret
L64:    movabs  RAX, jl_bounds_exception
    mov RDI, QWORD PTR [RAX]
    movabs  RAX, jl_throw_with_superfluous_argument
    mov ESI, 1
    call    RAX

समकक्ष के विपरीत:

julia> fun(x) = x/2.0 + 3.0
fun (generic function with 1 method)

julia> <strong i="21">@code_native</strong> fun(a1[1])
    .text
Filename: none
Source line: 1
    push    RBP
    mov RBP, RSP
    movabs  RAX, 139856006157040
Source line: 1
    mulsd   XMM0, QWORD PTR [RAX]
    movabs  RAX, 139856006157048
    addsd   XMM0, QWORD PTR [RAX]
    pop RBP
    ret

jae L64 तक का हिस्सा एक सरणी सीमा जांच है। @inbounds का उपयोग करने से मदद मिल सकती है (यदि उपयुक्त हो)।

नीचे का भाग, जहाँ दो क्रमागत पंक्तियाँ mov RAX, ... से शुरू होती हैं, एक दोहरा संकेत है, यानी एक पॉइंटर को एक पॉइंटर (या सरणियों की एक सरणी, या एक सरणी के लिए एक पॉइंटर, आदि) तक पहुँचना। इसे LazyArray के आंतरिक प्रतिनिधित्व के साथ करना पड़ सकता है - शायद अपरिवर्तनीय का उपयोग करना (या जूलिया द्वारा अलग-अलग अपरिवर्तनीय का प्रतिनिधित्व करना) यहां मदद कर सकता है।

किसी भी तरह से, कोड अभी भी काफी तेज है। इसे और तेज़ बनाने के लिए, इसे और अधिक अनुकूलन अवसरों को उजागर करते हुए, कॉलर में इनलाइन करने की आवश्यकता होगी। क्या होता है यदि आप इस अभिव्यक्ति को कहते हैं जैसे लूप से?

इसके अलावा: क्या होता है यदि आप इसे आरईपीएल से नहीं बल्कि किसी फ़ंक्शन के भीतर से अलग करते हैं?

यह भी मदद नहीं कर सकता है, लेकिन ध्यान दें कि पहला संस्करण वास्तविक प्रदर्शन करता है
विभाजन जबकि दूसरे ने x/2 को गुणा में बदल दिया है।

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

@eschnett LazyArray पहले से ही एक अपरिवर्तनीय है, और मैं लूप में @inbounds का उपयोग कर रहा हूं। https://gist.github.com/nalimilan/d345e1c080984ed4c89a पर सार चलाने के बाद, आप जांच सकते हैं कि यह इसके साथ लूप में क्या देता है:

function test_lazy!(newa, a)
    a1 = LazyArray(a, Divide(), (2.0,))
    a2 = LazyArray(a1, Add(), (3.0,))
    collect!(newa, a2)
    newa
end
<strong i="11">@code_native</strong> test_lazy!(newa, a); 

तो शायद मुझे इनलाइनिंग को मजबूर करने में सक्षम होना चाहिए? मेरे प्रयासों में, @inline को getindex में जोड़ने से समय नहीं बदलता है।

@toivoh क्या समझा सकता है कि बाद के मामले में विभाजन सरल नहीं है?

मैंने दो-तर्क संस्करण (जिसे LazyArray2 कहा जाता है) के साथ प्रयोग करना जारी रखा है। x .+ y जैसे सरल ऑपरेशन के लिए निकलता है, वर्तमान .+ $ की तुलना में LazyArray2 का उपयोग करना वास्तव में तेज़ है, और यह स्पष्ट लूप के बहुत करीब है (ये 1000 कॉल के लिए हैं) , देखें https://gist.github.com/nalimilan/d345e1c080984ed4c89a):

# With LazyArray2, filling existing array
elapsed time: 0.028212517 seconds (56000 bytes allocated)

# With explicit loop, filling existing array
elapsed time: 0.013500379 seconds (0 bytes allocated)

# With LazyArray2, allocating a new array before filling it
elapsed time: 0.098324278 seconds (80104000 bytes allocated, 74.16% gc time)

# Using .+ (thus allocating a new array)
elapsed time: 0.078337337 seconds (80712000 bytes allocated, 52.46% gc time)

तो ऐसा लगता है कि यह रणनीति .+ , .* , आदि ऑपरेटरों सहित सभी तत्व-वार संचालन को बदलने के लिए व्यवहार्य है।

यह सामान्य संचालन को प्राप्त करने के लिए वास्तव में प्रतिस्पर्धी दिखता है जैसे मैट्रिक्स के आयाम के साथ वर्ग अंतरों के योग की गणना करना, यानी sum((x .- y).^2, 1) (फिर से सार देखें):

# With LazyArray2 and LazyArray (no array allocated except the result)
elapsed time: 0.022895754 seconds (1272000 bytes allocated)

# With explicit loop (no array allocated except the result)
elapsed time: 0.020376307 seconds (896000 bytes allocated)

# With element-wise operators (temporary copies allocated)
elapsed time: 0.331359085 seconds (160872000 bytes allocated, 50.20% gc time)

@nalimilan
LazyArrays के साथ आपका दृष्टिकोण भाप संलयन हास्केल [1, 2] के काम करने के तरीके के समान प्रतीत होता है। हो सकता है कि हम उस क्षेत्र के विचारों को लागू कर सकें?

[1] http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7401
[2] http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.421.8551

@vchuravy धन्यवाद। यह वास्तव में समान है, लेकिन अधिक जटिल है क्योंकि जूलिया एक अनिवार्य मॉडल का उपयोग करती है। इसके विपरीत हास्केल में संकलक को बड़ी संख्या में मामलों को संभालने की जरूरत है, और यहां तक ​​​​कि सिम मुद्दों को भी संभालना है (जिन्हें जूलिया में बाद के बिंदु पर एलएलवीएम द्वारा नियंत्रित किया जाता है)। लेकिन ईमानदारी से कहूं तो मैं इन पेपर्स में सब कुछ पार्स नहीं कर पा रहा हूं।

@nalimilan मैं भावना जानता हूँ। मुझे दूसरा पेपर विशेष रूप से दिलचस्प लगा क्योंकि यह सामान्यीकृत स्ट्रीम फ़्यूज़न पर चर्चा करता है, जो स्पष्ट रूप से वैक्टर पर एक अच्छा गणना मॉडल की अनुमति देता है।

मुझे लगता है कि आलस्य के साथ संयोजन में map और reduce जैसे निर्माणों से हमें जो मुख्य बिंदु लेना चाहिए वह पर्याप्त तेज़ (या स्पष्ट लूप से भी तेज़) हो सकता है।

जहां तक ​​​​मैं कह सकता हूं, कॉल सिंटैक्स में घुंघराले ब्रैकेट अभी भी उपलब्ध हैं। क्या होगा अगर यह func{x} बन गया? शायद कुछ ज्यादा ही फालतू?

तेजी से वेक्टरिंग (सिम के अर्थ में) के विषय पर, क्या कोई तरीका है जिससे हम ईजिन के तरीके का अनुकरण कर सकते हैं?

यहां सभी मौजूदा तत्व-वार संचालन को सामान्यीकरण के साथ बदलने का प्रस्ताव है जिसे मैंने ऊपर LazyArray और LazyArray2 कहा है। यह निश्चित रूप से इस धारणा पर निर्भर करता है कि हम NumericFuns.jl के फंक्शंस पर भरोसा किए बिना सभी कार्यों के लिए इसे उपवास कर सकते हैं।

1) एक नया सिंटैक्स जोड़ें f.(x) या f$(x) या जो कुछ भी LazyArray कॉल करने वाला f() प्रत्येक तत्व पर x ।

2) इस सिंटैक्स को इस प्रकार सामान्यीकृत करें कि broadcast वर्तमान में कैसे काम करता है, ताकि उदाहरण के लिए f.(x, y, ...) या f$(x, y, ...) LazyArray #$ बनाता है, लेकिन x के सिंगलटन आयामों का विस्तार करता है y , ... ताकि उन्हें एक सामान्य आकार दिया जा सके। यह निश्चित रूप से सूचकांकों पर संगणना द्वारा मक्खी पर किया जाएगा ताकि विस्तारित सरणियों को वास्तव में आवंटित नहीं किया जा सके।

3) .+ , .- , .* , ./ , .^ , आदि बनाएं। LazyArray के बजाय broadcast #$18$#$ का उपयोग करें

4) एक नए असाइनमेंट ऑपरेटर का परिचय दें .= या $= जो (कॉलिंग collect ) एक LazyArray को एक वास्तविक सरणी में बदल देगा (इसके आधार पर एक प्रकार का) प्रचार नियमों के माध्यम से इनपुट, और तत्व प्रकार के इनपुट के तत्व प्रकार और कॉल किए गए फ़ंक्शन के आधार पर)।

5) शायद broadcast को LazyArray पर कॉल के साथ बदलें और परिणामों के तत्काल collect आयन को वास्तविक सरणी में बदलें।

प्वाइंट 4 एक महत्वपूर्ण है: तत्व-वार संचालन कभी भी वास्तविक सरणी नहीं लौटाएगा, हमेशा LazyArray s, ताकि कई परिचालनों को जोड़ते समय, कोई प्रतियां नहीं बनाई जाती हैं, और दक्षता के लिए लूप को जोड़ा जा सकता है। यह अस्थायी आवंटन के बिना परिणाम पर sum जैसी कॉलिंग कटौती की अनुमति देता है। तो घने सरणियों और विरल मैट्रिक्स दोनों के लिए इस प्रकार के भाव मुहावरेदार और कुशल होंगे:

y .= sqrt.(x .+ 2)
y .=  √π exp.(-x .^ 2) .* sin.(k .* x) .+ im * log.(x .- 1)
sum((x .- y).^2, 1)

मुझे लगता है कि इस तरह की हल्की वस्तु को वापस करना सरणी दृश्यों की नई तस्वीर और Transpose / CTranspose में पूरी तरह से फिट बैठता है। इसका मतलब है कि जूलिया में आप एक घने और पठनीय वाक्य रचना के साथ बहुत कुशलता से जटिल संचालन करने में सक्षम हैं, हालांकि कुछ मामलों में आपको स्पष्ट रूप से copy पर कॉल करना होगा जब आपको "छद्म-सरणी" से स्वतंत्र होने की आवश्यकता होती है वास्तविक सरणी जिस पर यह आधारित है।

यह वास्तव में एक महत्वपूर्ण विशेषता की तरह लगता है। तत्व-वार ऑपरेटरों का वर्तमान व्यवहार नए उपयोगकर्ताओं के लिए एक जाल है, क्योंकि वाक्यविन्यास अच्छा और छोटा है लेकिन प्रदर्शन आमतौर पर बहुत खराब है, जाहिरा तौर पर मैटलैब की तुलना में खराब है। पिछले हफ्ते ही, जूलिया-उपयोगकर्ताओं पर कई थ्रेड्स में प्रदर्शन के मुद्दे थे जो इस तरह के डिज़ाइन से दूर हो जाएंगे:
https://groups.google.com/d/msg/julia-users/t0KvvESb9fA/6_ZAp2ujLpMJ
https://groups.google.com/d/msg/julia-users/DL8ZsK6vLjw/w19Zf1lVmHMJ
https://groups.google.com/d/msg/julia-users/YGmDUZGOGgo/LmsorgEfXHgJ

इस मुद्दे के प्रयोजनों के लिए, मैं वाक्य रचना को आलस्य से अलग कर दूंगा। हालांकि आपका प्रस्ताव दिलचस्प है।

ऐसा लगता है कि एक बिंदु आ गया है जहां बस _इतने सारे बिंदु_ हैं। मध्य उदाहरण विशेष रूप से बेहतर लिखा जाएगा:

x .|> x->exp(-x ^ 2) * sin(k * x) + im * log(x - 1)

जिसके लिए केवल बुनियादी कार्यों और एक कुशल map ( .|> ) की आवश्यकता होती है।

यह एक दिलचस्प तुलना है:

y .=  √π exp.(-x .^ 2) .* sin.(k .* x) .+ im * log.(x .- 1)
y =  [√π exp(-x[i]^ 2) .* sin(k * x[i]) .+ im * log(x[i] - 1) for i = 1:length(x)]

यदि आप for ... भाग को छूट देते हैं, तो समझ केवल एक वर्ण लंबी होती है। मेरे पास उन सभी बिंदुओं की तुलना में लगभग एक संक्षिप्त समझ वाक्यविन्यास होगा।

एक 1d समझ आकार को संरक्षित नहीं करती है, लेकिन अब हमारे पास for i in eachindex(x) है जो बदल भी सकता है।

समझ के साथ एक समस्या यह है कि वे DataArrays का समर्थन नहीं करते हैं।

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

नेट पर वे इस विचार के साथ बहुत दूर चले गए: आप इन अभिव्यक्ति पेड़ों को कई सीपीयू (.AsParallel () जोड़कर) पर समानांतर में निष्पादित कर सकते हैं, या आप उन्हें ड्रायडलिनक्यू के साथ एक बड़े क्लस्टर पर चला सकते हैं, या यहां तक ​​​​कि http: / पर भी चला सकते हैं।

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

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

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

कोई भी कॉम्प्रिहेंशन सिंटैक्स को अपनाने की कल्पना कर सकता है, जैसे y = [sqrt(x + 2) over x] । लेकिन जैसा कि @johnmyleswhite ने नोट किया कि उन्हें DataArrays समर्थन करना चाहिए, लेकिन स्पैस मैट्रिस और किसी भी नए सरणी प्रकार का भी समर्थन करना चाहिए। तो यह फिर से वाक्य रचना और सुविधाओं के मिश्रण का मामला है।

अधिक मौलिक रूप से, मुझे लगता है कि मेरे प्रस्ताव में विकल्पों की तुलना में दो विशेषताएं हैं:
1) y[:] = sqrt.(x .+ 2) का उपयोग करके आवंटन-मुक्त इन-प्लेस असाइनमेंट के लिए समर्थन।
2) sum((x .- y).^2, 1) जैसी आवंटन-मुक्त कटौती के लिए समर्थन।

क्या इसे अन्य समाधानों के साथ प्रदान किया जा सकता है (वाक्यविन्यास मुद्दों की परवाह किए बिना)?

@davidanthoff धन्यवाद, इसे अभी देख रहे हैं (मुझे लगता है कि समानांतर कंप्यूटिंग का समर्थन करने के लिए LazyArray भी बनाया जा सकता है)।

शायद इसे जेनरेटर के साथ जोड़ा जा सकता है - वे भी एक प्रकार की आलसी सरणी हैं। मुझे कुछ हद तक [f(x) over x] कॉम्प्रिहेंशन सिंटैक्स पसंद है, हालांकि यह नवागंतुकों के लिए अवधारणात्मक रूप से कठिन हो सकता है (क्योंकि उसी नाम का प्रभावी रूप से तत्वों और सरणी दोनों के लिए उपयोग किया जा रहा है)। यदि कोष्ठक के बिना समझ एक जनरेटर का निर्माण करेगी (जैसा कि मैंने बहुत समय पहले खेला था ), तो इन नए ओवर-एक्स-शैली-समझ को ब्रैकेट के बिना उपयोग करना स्वाभाविक होगा, इसे तुरंत इकट्ठा करने के बजाय एक LazyArray वापस करने के लिए।

@mbauman हां, जेनरेटर और आलसी सरणी कई गुण साझा करते हैं। जेनरेटर/आलसी सरणी एकत्र करने के लिए ब्रैकेट का उपयोग करने का विचार, और आलसी वस्तु को शांत रखने के लिए उन्हें जोड़ने का विचार अच्छा नहीं लगता है। तो ऊपर दिए गए मेरे उदाहरणों के संबंध में, कोई 1 दोनों को लिखने में सक्षम होगा) y[:] = sqrt(x + 2) over x और sum((x - y)^2 over (x, y), 1) (हालांकि मुझे यह नवागंतुकों के लिए भी स्वाभाविक लगता है, आइए over के मुद्दे को छोड़ दें बाइकशेडिंग सत्र और पहले बुनियादी बातों पर ध्यान केंद्रित करें)।

मुझे f(x) over x विचार पसंद है। हम किसी नए कीवर्ड से बचने के लिए f(x) for x का भी उपयोग कर सकते हैं। वास्तव में [f(x) for x=x] पहले से ही काम करता है। इसके बाद हमें map के बराबर समझ बनाने की आवश्यकता होगी, ताकि वे गैर-सरणी के लिए काम कर सकें। Array बस डिफ़ॉल्ट होगा।

मुझे स्वीकार करना होगा कि मुझे भी over विचार पसंद आया है। मानचित्र के रूप में $# over for के बीच एक अंतर यह है कि एकाधिक पुनरावृत्तियों के मामले में क्या होता है: [f(x, y) for x=x, y=y] एक मैट्रिक्स में परिणाम। मानचित्र मामले के लिए आप आम तौर पर अभी भी एक वेक्टर चाहते हैं, यानी [f(x, y) over x, y] [f(x, y) for (x,y) = zip(x, y)]] के बराबर होगा। इस वजह से मुझे अब भी लगता है कि एक अतिरिक्त कीवर्ड over पेश करना इसके लायक है, क्योंकि, जैसा कि इस मुद्दे ने उठाया है, कई वैक्टरों पर map आईएनजी बहुत आम है और इसे संक्षिप्त करने की आवश्यकता है।

अरे, मैंने जेफ को वाक्य रचना के बारे में आश्वस्त किया! ;-)

यह #4470 के बगल में है, इसलिए अभी के लिए 0.4-परियोजनाओं को जोड़ा जा रहा है।

अगर मैं चर्चा के सार को समझता हूं तो मुख्य समस्या यह है कि हम मैपिंग-जैसे सिंटैक्स प्राप्त करना चाहते हैं:

• विभिन्न डेटा प्रकारों के साथ काम करता है, जैसे DataArrays, न केवल मूल सरणियाँ;
• मैन्युअल रूप से लिखित लूप जितना तेज़ है।

इनलाइनिंग का उपयोग करके ऐसा करना संभव हो सकता है, लेकिन इनलाइनिंग कार्यों को सुनिश्चित करने के लिए वास्तव में सावधान रहना।

भिन्न दृष्टिकोण के बारे में क्या: अनुमानित डेटा प्रकार के आधार पर मैक्रो का उपयोग करना। यदि हम अनुमान लगा सकते हैं कि डेटा संरचना DataArray है, तो हम DataArrays लाइब्रेरी द्वारा प्रदान किए गए मैप-मैक्रो का उपयोग करते हैं। यदि यह SomeKindOfStream है, तो हम प्रदान की गई स्ट्रीम लाइब्रेरी का उपयोग करते हैं। यदि हम प्रकार का अनुमान नहीं लगा सकते हैं, तो हम केवल गतिशील रूप से भेजे गए सामान्य कार्यान्वयन का उपयोग करते हैं।

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

अगर मैं जो लिख रहा हूं वह अस्पष्ट है, मेरा मतलब है कि [EXPR for i in collection if COND] का अनुवाद eval(collection_mapfilter_macro(:(i), :(EXPR), :(COND))) में किया जा सकता है, जहां अनुमानित संग्रह प्रकार के आधार पर collection_mapfilter_macro चुना जाता है।

नहीं, हम ऐसी चीजें नहीं करना चाहते। यदि DataArray map (या समकक्ष) को परिभाषित करता है, तो इसकी परिभाषा को हमेशा DataArrays के लिए बुलाया जाना चाहिए, चाहे जो भी अनुमान लगाया जा सके।

यह मुद्दा वास्तव में कार्यान्वयन के बारे में नहीं है, बल्कि वाक्यविन्यास है। यदि x एक सरणी है, तो अभी बहुत से लोग sin(x) परोक्ष रूप से मानचित्रण करने के आदी हैं, लेकिन उस दृष्टिकोण के साथ कई समस्याएं हैं। सवाल यह है कि वैकल्पिक वाक्यविन्यास क्या स्वीकार्य होगा।

1) y[:] = sqrt.(x .+ 2) . का उपयोग करके आवंटन-मुक्त इन-प्लेस असाइनमेंट के लिए समर्थन
2) sum((x .- y).^2, 1) जैसी आवंटन-मुक्त कटौती के लिए समर्थन

y = क्स्प(-x^2) * sin(k*x) + im * log(x-1)

दूसरों से इन तीन उदाहरणों को देखते हुए मुझे लगता है कि for सिंटैक्स के साथ यह कुछ इस तरह समाप्त होगा:
1) y[:] = [ sqrt(x + 2) for x ])
2) sum([ (x-y)^2 for x,y ], 1)
तथा
y = [ √π exp(-x^2) * sin(k*x) + im * log(x-1) for x,k ]

मुझे यह काफी पसंद है! तथ्य यह है कि यह एक अस्थायी सरणी बनाता है काफी स्पष्ट है और यह अभी भी पठनीय और संक्षिप्त है।

हालांकि मामूली सवाल, क्या x[:] = [ ... for x ] में अस्थायी आवंटित किए बिना सरणी को बदलने के लिए कुछ जादू हो सकता है?
मुझे यकीन नहीं है कि इससे बहुत लाभ होगा लेकिन मैं कल्पना कर सकता हूं कि यह बड़े सरणी के लिए मदद करेगा।
हालांकि मैं विश्वास कर सकता हूं कि यह मछली की एक पूरी तरह से अलग केतली हो सकती है जिस पर कहीं और चर्चा की जानी चाहिए।

@Mike43110 आपका x[:] = [ ... for x ] लिखा जा सकता है x[:] = (... for x) , RHS एक जनरेटर बना रहा है, जिसे एक प्रति आवंटित किए बिना x भरने के लिए तत्व द्वारा तत्व एकत्र किया जाएगा। ऊपर मेरे LazyArray प्रयोग के पीछे यही विचार था।

[f <- y] सिंटैक्स अच्छा होगा यदि मानचित्र के लिए Int[f <- y] सिंटैक्स के साथ जोड़ा जाए जो इसके आउटपुट प्रकार को जानता है और f(y[1]) से अन्य तत्वों को इंटरपोलेट करने की आवश्यकता नहीं है।

विशेष रूप से, चूंकि यह mapslices के लिए भी एक सहज ज्ञान युक्त इंटरफ़ेस देता है, [f <- rows(A)] जहां rows(A) (या columns(A) या slices(A, dims) ) एक Slice देता है

map(f, slice::Slice) = mapslices(f, slice.A, slice.dims)

जब आप अनुक्रमण जोड़ते हैं, तो यह थोड़ा कठिन हो जाता है। उदाहरण के लिए

f(x[:,j]) .* g(x[i,:])

इसकी संक्षिप्तता से मेल खाना मुश्किल है। समझ शैली से झटका बहुत खराब है:

[f(x[m,j])*g(x[i,n]) for m=1:size(x,1), n=1:size(x,2)]

जहां, मामलों को बदतर बनाने के लिए, यह जानने के लिए चतुराई की आवश्यकता थी कि यह नेस्टेड पुनरावृत्ति का मामला है, और इसे एक over के साथ नहीं किया जा सकता है। हालांकि अगर f और g थोड़े महंगे हैं, तो यह तेज़ हो सकता है:

[f(x[m,j]) for m=1:size(x,1)] .* [g(x[i,n]) for _=1, n=1:size(x,2)]

लेकिन इससे भी लंबा।

इस प्रकार का उदाहरण "डॉट्स" के लिए तर्क देता प्रतीत होता है, क्योंकि यह f.(x[:,j]) .* g.(x[i,:]) दे सकता है।

@JeffBezanson मुझे यकीन नहीं है कि आपकी टिप्पणी का इरादा क्या है। क्या किसी ने .* सिंटैक्स से छुटकारा पाने का सुझाव दिया है?

नहीं; मैं यहां f और g पर ध्यान केंद्रित कर रहा हूं। यह एक उदाहरण है जहां आप पंक्ति के अंत में केवल over x नहीं जोड़ सकते हैं।

ठीक है, मैं देख रहा हूँ, मैं टिप्पणी के अंत से चूक गया था। वास्तव में उस मामले में डॉट्स संस्करण अच्छा है।

हालांकि सरणी दृश्यों के साथ, एक उचित रूप से कुशल (AFAICT) होगा और इतना बदसूरत विकल्प नहीं होगा:
[ f(y) * g(z) for y in x[:,j], z in x[i,:] ]

क्या उपरोक्त उदाहरण को कीवर्ड पर नेस्ट करके हल किया जा सकता है?

f(x)*g(y) over x,y

के रूप में व्याख्या की जाती है

[f(x)*g(y) for (x,y) = zip(x,y)]

जबकि

f(x)*g(y) over x over y

हो जाता है

[f(x)*g(y) for x=x, y=y]

फिर, ऊपर दिया गया विशिष्ट उदाहरण कुछ इस तरह होगा

f(x[:,n])*g(x[m,:]) over x[:,n] over x[m,:]

संपादित करें: पूर्व-निरीक्षण में, यह लगभग उतना संक्षिप्त नहीं है जितना मैंने सोचा था कि यह होगा।

@JeffBezanson कैसा रहेगा?

f(x[:i,n]) * g(x[m,:i]) over i

f.(x[:,n] .* g.(x[m,:]) के बराबर देता है। नया सिंटैक्स x[:i,n] का अर्थ है कि i को कंटेनर के सूचकांकों पर एक पुनरावर्तक के रूप में स्थानीय रूप से पेश किया जा रहा है x[:,n] । मुझे नहीं पता कि इसे लागू करना संभव है या नहीं। लेकिन ऐसा लगता है (प्रथम दृष्टया) न तो बदसूरत और न ही बोझिल, और वाक्यविन्यास स्वयं पुनरावर्तक के लिए सीमा देता है, अर्थात् 1: लंबाई (x [:, n])। जहां तक ​​​​कीवर्ड का संबंध है, "ओवर" संकेत कर सकता है कि पूरी श्रेणी का उपयोग किया जाना है, जबकि "के लिए" का उपयोग किया जा सकता है यदि उपयोगकर्ता 1: लंबाई (x [:, एन]) की एक उपश्रेणी निर्दिष्ट करना चाहता है:

f(x[:i,n]) * g(x[m,:i]) for i in 1:length(x[:,n])-1 ।

@ डेविडगोल्ड , :i पहले से ही प्रतीक i का अर्थ है।

आह हाँ, अच्छा बिंदु। खैर, जब तक डॉट्स निष्पक्ष खेल हैं, तब तक क्या होगा

f(x[.i,n]) * g(x[m,.i]) over i

जहां डॉट इंगित करता है कि i को स्थानीय रूप से 1:length(x[:,n) से अधिक के पुनरावर्तक के रूप में पेश किया जा रहा है। मुझे लगता है कि संक्षेप में यह डॉट नोटेशन को कार्यों को संशोधित करने से सरणी को संशोधित करने, या बल्कि उनके सूचकांक को स्विच करता है। यह "डॉट क्रीप" से एक को बचाएगा जेफ ने नोट किया:

[ f(g(e^(x[m,.i]))) * p(e^(f(y[.i,n]))) over i ]

विरोध के रूप में

f.(g.(e.^(x[m,:]))) .* p.(e.^(f.(y[:,n])))

हालांकि मुझे लगता है कि बाद वाला थोड़ा छोटा है। [संपादित करें: इसके अलावा, यदि कोई अस्पष्टता नहीं होने पर over i को छोड़ना संभव है, तो वास्तव में थोड़ा छोटा वाक्यविन्यास होता है:

[ f(g(e^(x[m,.i]))) * p(e^(f(y[.i,n]))) ] ]

कॉम्प्रिहेंशन सिंटैक्स का एक संभावित लाभ यह है कि यह तत्व-वार संचालन के पैटर्न की एक विस्तृत श्रृंखला की अनुमति दे सकता है। उदाहरण के लिए, यदि पार्सर ने समझा कि i x[m, .i] #$ में अनुक्रमण निहित रूप से मॉड्यूलो लंबाई (x [m,:]) है, तो कोई लिख सकता है

[ f(x[.i]) * g(y[.j]) over i, j=-i ]

x के तत्वों को विपरीत क्रम में y के तत्वों से गुणा करने के लिए, अर्थात x y अंतिम तत्व के विरुद्ध, आदि कोई लिख सकता है

[ f(x[.i]) * g(y[.j]) over i, j=i+1 ]

i वें तत्व को x से गुणा करने के लिए i+1 वें तत्व से y (जहां x के अंतिम तत्व को गुणा किया जाएगा) इंडेक्सिंग को इस संदर्भ में मॉड्यूल लंबाई (x) के रूप में समझने के कारण y के पहले तत्व द्वारा)। और अगर p::Permutation परमिट (1, ..., लंबाई (x)) कोई लिख सकता है

[ f(x[.i]) * g(y[.j]) over i, j=p(i) ]

x के i वें तत्व को x y p(i) वें तत्व से गुणा करने के लिए।

वैसे भी, यह पूरी तरह से सट्टा मुद्दे पर किसी बाहरी व्यक्ति की एक विनम्र राय है। = पी मैं इस पर विचार करने में लगने वाले समय की सराहना करता हूं।

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

unvectorized_sum(a, b, c, d) = a + b + c + d
vectorized_sum = @super_vectorize(unvectorized_sum)

a = [1, 2, 3, 4]
b = [1, 2, 3]
c = [1, 2]
d = 1

A = [1, 2, 3, 4]
B = [1, 2, 3, 1]
C = [1, 2, 1, 2]
D = [1, 1, 1, 1]

vectorized_sum(a, b, c, d) = vectorized_sum(A, B, C, D) = [4, 7, 8, 8]

मुझे लगता है कि रीसाइक्लिंग सुविधा के लिए बहुत अधिक सुरक्षा को बंद कर देता है। रीसाइक्लिंग के साथ, बग्गी कोड लिखना बहुत आसान है जो बिना किसी त्रुटि के निष्पादित होता है।

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

@super_vectorize का उपयोग करना है या नहीं, यह उपयोगकर्ता के हाथ में होगा। विभिन्न मामलों के लिए चेतावनी देना भी संभव होगा। उदाहरण के लिए, आर में,

c(1, 2, 3) + c(1, 2)
[1] 2 4 4
Warning message:
In c(1, 2, 3) + c(1, 2) :
  longer object length is not a multiple of shorter object length

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

@vectorize_1arg और @vectorize_2arg दोनों पहले से ही बेस में शामिल हैं, और वे जो विकल्प उपयोगकर्ता को देते हैं वे कुछ हद तक सीमित लगते हैं।

लेकिन यह मुद्दा बेस से @vectorize_1arg और @vectorize_2arg को हटाने के लिए एक प्रणाली के डिजाइन पर केंद्रित है। हमारा लक्ष्य भाषा से वेक्टरकृत कार्यों को हटाना और उन्हें बेहतर अमूर्तता के साथ बदलना है।

उदाहरण के लिए, रीसाइक्लिंग को इस प्रकार लिखा जा सकता है:

[ A[i] + B[mod1(i,length(B))] for i in eachindex(A) ]

जो मेरे लिए इसे लिखने के आदर्श तरीके के काफी करीब है। किसी को भी इसे आपके लिए बनाने की जरूरत नहीं है। मुख्य प्रश्न हैं (1) क्या इसे और संक्षिप्त बनाया जा सकता है, (2) इसे अन्य कंटेनर प्रकारों तक कैसे बढ़ाया जाए।

@davidagold के प्रस्ताव को देखते हुए मैंने सोचा कि क्या var: का उपयोग उस तरह की चीज़ के लिए नहीं किया जा सकता है जहां चर कोलन से पहले नाम होगा। मैंने देखा कि इस सिंटैक्स का अर्थ A[var:end] होता है, इसलिए ऐसा लगता है कि यह उपलब्ध है।

f(x[:,j]) .* g(x[i,:]) तब f(x[a:,j]) * g(x[i,b:]) for a, b होगा जो बहुत ज्यादा खराब नहीं है।

हालांकि एकाधिक कोलन थोड़ा अजीब होगा।

f(x[:,:,j]) .* g(x[i,:,:]) -> f(x[a:,a:,j]) * g(x[i,b:,b:]) for a, b इस पर मेरा प्रारंभिक विचार था।

ठीक है, तो यहाँ रीसाइक्लिंग के लिए एक कार्यक्रम में एक संक्षिप्त स्टैब है। यह n-आयामी सरणियों को संभालने में सक्षम होना चाहिए। संभवतः वैक्टरों के अनुरूप टुपल्स को शामिल करना संभव होगा।

using DataFrames

a = [1, 2, 3]
b = 1
c = [1 2]
d = <strong i="6">@data</strong> [NA, 2, 3]

# coerce an array to a certain size using recycling
coerce_to_size = function(argument, dimension_extents...)

  # number of repmats needed, initialized to 1
  dimension_ratios = [dimension_extents...]

  for dimension in 1:ndims(argument)

    dimension_ratios[dimension] = 
      ceil(dimension_extents[dimension] / size(argument, dimension))
  end

  # repmat array to at least desired size
  if typeof(argument) <: AbstractArray
    rep_to_size = repmat(argument, dimension_ratios...)
  else
    rep_to_size = 
      fill(argument, dimension_ratios...)
  end

  # cut down array to exactly desired size
  dimension_ranges = [1:i for i in dimension_extents]
  dimension_ranges = tuple(dimension_ranges...)

  rep_to_size = getindex(rep_to_size, dimension_ranges...)  

end

recycle = function(argument_list...)

  # largest dimension in arguments
  max_dimension = maximum([ndims(i) for i in argument_list])
  # initialize dimension extents to 1
  dimension_extents = [1 for i in 1:max_dimension]

  # loop through argument and dimension
  for argument_index in 1:length(argument_list)
    for dimension in 1:ndims(argument_list[argument_index])
      # find the largest size for each dimension
      dimension_extents[dimension] = maximum([
        size(argument_list[argument_index], dimension),
        dimension_extents[dimension]
      ])
    end
  end

  expand_arguments = 
    [coerce_to_size(argument, dimension_extents...) 
     for argument in argument_list]
end

recycle(a, b, c, d)

mapply = function(FUN, argument_list...)
  argument_list = recycle(argument_list...)
  FUN(argument_list...)
end

mapply(+, a, b, c, d)

स्पष्ट रूप से, यह सबसे सुंदर या तेज़ कोड नहीं है (मैं हाल ही में एक आर आप्रवासी हूं)। मुझे यकीन नहीं है कि यहां से @vectorize मैक्रो तक कैसे पहुंचा जाए।

संपादित करें: संयुक्त निरर्थक लूप
संपादित करें 2: आकार के लिए अलग-अलग ज़बरदस्ती। वर्तमान में केवल 0-2 आयामों के लिए काम करता है।
संपादित करें 3: ऐसा करने का एक और अधिक सुरुचिपूर्ण तरीका मॉड इंडेक्सिंग के साथ एक विशेष प्रकार की सरणी को परिभाषित करना होगा। अर्थात्,

special_array = [1 2; 3 5]
special_array.dims = (10, 10, 10, 10)
special_array[4, 1, 9, 7] = 3

संपादित करें 4: जिन चीजों के बारे में मैं सोच रहा हूं वे मौजूद हैं क्योंकि यह लिखना मुश्किल था: एचसीएटी और वीकैट का एन-आयामी सामान्यीकरण? प्रत्येक विशेष स्थिति के सूचकांकों की सूचियों या टुपल्स के साथ एन-आयामी सरणी (किसी दिए गए सरणी के आकार से मेल खाने) को भरने का एक तरीका? रेपमैट का एक एन-आयामी सामान्यीकरण?

[पाओ: सिंटैक्स हाइलाइटिंग]

आप वास्तव में जूलिया में foo = function(x,y,z) ... end सिंटैक्स के साथ फ़ंक्शंस को परिभाषित नहीं करना चाहते हैं, हालांकि यह काम करता है। यह एक अनाम फ़ंक्शन के लिए नाम का एक गैर-निरंतर बंधन बनाता है। जूलिया में, सामान्य कार्यों का उपयोग करने का मानदंड है और कार्यों के लिए बाइंडिंग स्वचालित रूप से स्थिर है। अन्यथा आपको भयानक प्रदर्शन मिलने वाला है।

मैं नहीं देखता कि यहां रेपमैट क्यों जरूरी है। प्रत्येक स्थिति की अनुक्रमणिका से भरे हुए सरणी भी एक चेतावनी संकेत हैं: इतनी कम जानकारी का प्रतिनिधित्व करने के लिए स्मृति के बड़े हिस्से का उपयोग करना आवश्यक नहीं होना चाहिए। मेरा मानना ​​​​है कि ऐसी तकनीकें वास्तव में केवल उन भाषाओं में उपयोगी होती हैं जहां सब कुछ "सदिश" करने की आवश्यकता होती है। ऐसा लगता है कि सही तरीका सिर्फ एक लूप चलाने के लिए है जहां कुछ इंडेक्स बदल जाते हैं, जैसे https://github.com/JuliaLang/julia/issues/8450#issuecomment -111898906।

हाँ, यह समझ में आता है। यहां एक शुरुआत है, लेकिन मुझे यह पता लगाने में परेशानी हो रही है कि अंत में लूपिंग कैसे करें और फिर @vectorize मैक्रो बनाएं।

function non_zero_mod(big::Number, little::Number)
  result = big % little
  result == 0 ? little : result
end

function mod_select(array, index...)
  # just return singletons
  if !(typeof(array) <: AbstractArray) return array end
  # find a new index with moded values
  transformed_index = 
      [non_zero_mod( index[i], size(array, i) )
       for i in 1:ndims(array)]
  # return value at moded index
  array[transformed_index...]
end

function mod_value_list(argument_list, index...)
  [mod_select(argument, index...) for argument in argument_list]
end

mapply = function(FUN, argument_list...)

  # largest dimension in arguments
  max_dimension = maximum([ndims(i) for i in argument_list])
  # initialize dimension extents to 1
  dimension_extents = [1 for i in 1:max_dimension]

  # loop through argument and dimension
  for argument_index in 1:length(argument_list)
    for dimension in 1:ndims(argument_list[argument_index])
      # find the largest size for each dimension
      dimension_extents[dimension] = maximum([
        size(argument_list[argument_index], dimension),
        dimension_extents[dimension]
      ])
    end
  end

  # more needed here
  # apply function over arguments using mod_value_list on arguments at each position
end

बातचीत में, @JeffBezanson ने सिंटैक्स का उल्लेख किया sin(x) over x , कुछ और क्यों नहीं:
sin(over x) ? (या कीवर्ड के रूप में over रखने के बजाय कुछ वर्ण का उपयोग करें)

एक बार यह हल हो जाने पर हम #11872 . भी हल कर सकते हैं

मुझे आशा है कि मुझे पार्टी में देर नहीं हुई है, लेकिन मैं @davidagold के सिंटैक्स प्रस्ताव को +1 देना चाहूंगा। यह अवधारणात्मक रूप से स्पष्ट है, संक्षिप्त है, और लिखना वास्तव में स्वाभाविक लगता है। मुझे यकीन नहीं है कि . सबसे अच्छा पहचान वाला चरित्र होगा, या वास्तविक कार्यान्वयन कितना व्यवहार्य होगा, लेकिन कोई इसे आज़माने के लिए मैक्रो का उपयोग करके एक सबूत की अवधारणा बना सकता है (अनिवार्य रूप से @devec की तरह)

इसमें मौजूदा सरणी समझ सिंटैक्स के साथ "फिटिंग इन" का लाभ भी है:

result = [g(f(.i), h(.j)) over i, j]

बनाम

result = [g(f(_i), h(_j)) for _i in eachindex(i), _j in eachindex(j)]

दोनों के बीच महत्वपूर्ण अंतर यह है कि पूर्व में आकार-संरक्षण पर अधिक प्रतिबंध होंगे, क्योंकि इसका तात्पर्य एक मानचित्र से है।

over , range , और window OLAP अंतरिक्ष में पुनरावृत्ति के लिए संशोधक के रूप में कुछ पूर्व कला है, यह सुसंगत लगता है।

मैं . सिंटैक्स के लिए उत्सुक नहीं हूं क्योंकि यह लाइन शोर की ओर एक रेंगने जैसा लगता है।

$ शायद सुसंगत है, अभिव्यक्ति में i, j को पुनरावृत्त करने के मूल्यों को इंटर्न करें?

result = [g(f($i), h($j)) over i, j]

एक व्यंजक के स्वत: वैश्वीकरण के लिए क्या हम व्यंजक में taint एक सदिश नहीं कर सकते हैं और क्या टाइप सिस्टम व्यंजक को सदिश स्थान में उठा सकता है?

मैं समय श्रृंखला संचालन के समान ही करता हूं जहां जूलिया की अभिव्यक्ति मुझे पहले से ही लिखने की अनुमति देती है

ts_a = GetTS( ... )
ts_b = GetTS( ... ) 
factors = [ 1,  2, 3 ]

ts_x = ts_a * 2 + sin( ts_a * factors ) + ts_b 

जो जब देखा जाता है तो वैक्टर की एक समय श्रृंखला का उत्पादन करता है।

लापता मुख्य भाग अंतरिक्ष में मौजूदा कार्यों को स्वचालित रूप से उठाने की क्षमता है। यह हाथ से करना होगा

अनिवार्य रूप से मैं निम्नलिखित की तरह कुछ परिभाषित करने में सक्षम होना चाहता हूं ...

abstract TS{K}
function {F}{K}( x::TS{K}, y::TS{K} ) = tsjoin( F, x, y ) 
# tsjoin is a time series iteration operator

और फिर विशिष्ट कार्यों के लिए विशेषज्ञता प्राप्त करने में सक्षम हो

function mean{K}(x::TS{K}) = ... # my hand rolled form

हाय @JeffBezanson ,

अगर मैं सही ढंग से समझता हूं, तो मैं ऊपर की गई टिप्पणी के संबंध में आपकी जूलियाकॉन 2015 टिप्पणी का समाधान प्रस्तावित करना चाहता हूं:
"[...] और पुस्तकालय लेखकों को सभी उपयुक्त कार्यों पर @vectorize डालने के लिए कहना मूर्खतापूर्ण है; आपको केवल एक फ़ंक्शन लिखने में सक्षम होना चाहिए, और यदि कोई इसे प्रत्येक तत्व के लिए गणना करना चाहता है तो वे मानचित्र का उपयोग करते हैं।"
(लेकिन मैं अन्य मौलिक मुद्दे को संबोधित नहीं करूंगा "[..] वास्तव में कोई ठोस कारण नहीं है कि पाप, क्स्प आदि को सरणियों पर निहित रूप से मैप किया जाना चाहिए।")

जूलिया v0.40 में, मैं @vectrorize की तुलना में कुछ हद तक अच्छा (मेरी राय में) समाधान प्राप्त करने में सक्षम हूं:

abstract Vectorizable{Fn}
#Could easily have added extra argument to Vectorizable, but want to show inheritance case:
abstract Vectorizable2Arg{Fn} <: Vectorizable{Fn}

call{F}(::Type{Vectorizable2Arg{F}}, x1, x2) = eval(:($F($x1,$x2)))
function call{F,T1,T2}(fn::Type{Vectorizable2Arg{F}}, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

#Function in need of vectorizing:
function _myadd(x::Number, y::Number)
    return x+y+1
end

#"Register" the function as a Vectorizable 2-argument (alternative to @vectorize):
typealias myadd Vectorizable2Arg{:_myadd}

<strong i="13">@show</strong> myadd(5,6)
<strong i="14">@show</strong> myadd(collect(1:10),collect(21:30.0)) #Type stable!

यह कमोबेश उचित है, लेकिन कुछ हद तक @vectorize समाधान के समान है। वैश्वीकरण के सुरुचिपूर्ण होने के लिए, मेरा सुझाव है कि जूलिया निम्नलिखित का समर्थन करें:

abstract Vectorizable <: Function
abstract Vectorizable2Arg <: Vectorizable

function call{T1,T2}(fn::Vectorizable2Arg, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

#Note: by default, functions would normally be <: Function:
function myadd(x::Number, y::Number) <: Vectorizable2Arg
    return x+y+1
end

इतना ही! एक वेक्टरिज़ेबल फ़ंक्शन से एक फ़ंक्शन इनहेरिट होने से इसे वेक्टर करने योग्य बना दिया जाएगा।

मुझे आशा है कि आप जो खोज रहे थे उसकी तर्ज पर यह।

सादर,

एमए

एकाधिक विरासत की अनुपस्थिति में, फ़ंक्शन Vectorizable से और किसी अन्य चीज़ से कैसे प्राप्त होता है? और आप एक सामान्य कार्य के लिए विरासत की जानकारी के लिए विशिष्ट तरीकों के लिए विरासत की जानकारी कैसे संबंधित करते हैं?

@ ma-laforge आप पहले से ही ऐसा कर सकते हैं --- एक प्रकार myadd <: Vectorizable2Arg परिभाषित करें, फिर call के लिए myadd पर Number पर लागू करें।

इसके लिए धन्यवाद @JeffBezanson!

दरअसल, मैं लगभग अपना समाधान लगभग उतना ही अच्छा दिख सकता हूं जितना मैं चाहता हूं:

abstract Vectorizable
#Could easily have parameterized Vectorizable, but want to show inheritance case:
abstract Vectorizable2Arg <: Vectorizable

function call{T1,T2}(fn::Vectorizable2Arg, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

#SECTION F: Function in need of vectorizing:
immutable MyAddType <: Vectorizable2Arg; end
const myadd = MyAddType()
function call(::MyAddType, x::Number, y::Number)
    return x+y+1
end

<strong i="7">@show</strong> myadd(5,6)
<strong i="8">@show</strong> myadd(collect(1:10),collect(21:30.0)) #Type stable

अब, केवल एक चीज गायब है जो किसी भी फ़ंक्शन को "सबटाइप" करने का एक तरीका होगा, ताकि पूरे खंड F को अधिक सुरुचिपूर्ण सिंटैक्स से बदला जा सके:

function myadd(x::Number, y::Number) <: Vectorizable2Arg
    return x+y+1
end

नोट: मैंने "MyAddType" टाइप किया है, और फ़ंक्शन नाम को सिंगलटन ऑब्जेक्ट "myadd" में बनाया है क्योंकि मुझे परिणामी सिंटैक्स अच्छा लगता है अगर कोई कॉल हस्ताक्षर में Type{Vectorizable2Arg} का उपयोग कर रहा था:

function call{T1,T2}(fn::Type{Vectorizable2Arg}, v1::Vector{T1}, v2::Vector{T2})

अफसोस की बात है, आपकी प्रतिक्रिया से, ऐसा लगता है कि यह _not_ @vectorize मैक्रो की "मूर्खता" का पर्याप्त समाधान होगा।

सादर,

एमए

@johnmyleswhite :

मैं आपकी टिप्पणी का जवाब देना चाहता हूं, लेकिन मुझे नहीं लगता कि मैं समझता हूं। क्या आप स्पष्ट कर सकते हो?

एक बात मैं _can_ कह सकता हूं:
"Vectorizable" के बारे में कुछ खास नहीं है। विचार यह है कि कोई भी अपने स्वयं के कार्य "वर्ग" को परिभाषित कर सकता है (उदा: MyFunctionGroupA<:Function )। फिर वे अपने स्वयं के "कॉल" हस्ताक्षर (जैसा कि ऊपर दिखाया गया है) को परिभाषित करके उस प्रकार के कार्यों के लिए कॉल पकड़ सकते हैं।

ऐसा कहने के बाद: मेरा सुझाव यह है कि बेस के भीतर परिभाषित कार्यों को स्वचालित रूप से वेक्टरकृत एल्गोरिदम स्वचालित रूप से उत्पन्न करने के लिए Base.Vectorizable <: Function (या कुछ समान) का उपयोग करना चाहिए।

फिर मैं सुझाव दूंगा कि मॉड्यूल डेवलपर्स कुछ हद तक एक पैटर्न का उपयोग करके अपने स्वयं के कार्यों को लागू करें:

myfunction(x::MyType, y::MyType) <: Base.Vectorizable

बेशक, उन्हें promote_type(::Type{MyType},::Type{MyType}) का अपना स्वयं का संस्करण प्रदान करना होगा - यदि डिफ़ॉल्ट पहले से MyType वापस नहीं करना है।

यदि डिफ़ॉल्ट वैश्वीकरण एल्गोरिथ्म अपर्याप्त है, तो उपयोगकर्ता को अपने स्वयं के पदानुक्रम को लागू करने से कोई रोक नहीं सकता है:

MyVectorizable{nargs} <: Function
call(fn::MyVectorizable{2}, x, y) = ...

myfunction(x::MyType, y:MyType) <: MyVectorizable{2}

एमए

@ मा-लाफोर्ज, अस्पष्ट होने के लिए खेद है। मेरी चिंता यह है कि किसी भी पदानुक्रम में हमेशा महत्वपूर्ण जानकारी की कमी होगी क्योंकि जूलिया के पास एकल विरासत है, जिसके लिए आपको प्रत्येक फ़ंक्शन के लिए एक ही मूल प्रकार के लिए प्रतिबद्ध होना होगा। यदि आप myfunction(x::MyType, y::MyType) <: Base.Vectorizable जैसी किसी चीज़ का उपयोग करते हैं तो आपके फ़ंक्शन को किसी अन्य व्यक्ति से Base.NullableLiftable जैसी अवधारणा को परिभाषित करने से कोई लाभ नहीं होगा जो नलबल के कार्यों को स्वतः उत्पन्न करता है।

ऐसा लगता है कि यह लक्षणों के साथ कोई समस्या नहीं होगी (cf. https://github.com/JuliaLang/julia/pull/13222)। विधियों को शुद्ध घोषित करने की नई संभावना भी संबंधित है (https://github.com/JuliaLang/julia/pull/13555), जो स्वचालित रूप से यह संकेत दे सकता है कि ऐसी विधि वेक्टर करने योग्य है (कम से कम एकल-तर्क विधियों के लिए)।

@johnmyleswhite ,

अगर मैं सही ढंग से समझता हूं: मुझे नहीं लगता कि यह विशेष रूप से _this_ मामले के लिए कोई समस्या है। ऐसा इसलिए है क्योंकि मैं एक डिजाइन पैटर्न का प्रस्ताव कर रहा हूं। आपके फ़ंक्शन Base.Vectorizable से इनहेरिट करने के लिए _have_ नहीं हैं ... आप अपना खुद का उपयोग कर सकते हैं।

मैं वास्तव में NullableLiftables के बारे में बहुत कुछ नहीं जानता (मुझे लगता है कि मेरे जूलिया के संस्करण में ऐसा नहीं है)। हालांकि, यह मानते हुए कि यह Base.Function से विरासत में मिला है (जो जूलिया के मेरे संस्करण में भी संभव नहीं है):

NullableLiftable <: Function

आपका मॉड्यूल तब (केवल एक बार) एक _new_ वेक्टरिज़ेबल उप-प्रकार लागू कर सकता है:

abstract VectorizableNullableLiftable <: NullableLiftable

function call{T1,T2}(fn::VectorizableNullableLiftable, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

तो, अब से, कोई भी जो <: VectorizableNullableLiftable फ़ंक्शन को परिभाषित करता है, उसे आपका वेक्टराइज़ेशन कोड स्वचालित रूप से लागू हो जाएगा!

function mycooladdon(scalar1, scalar2) <: VectorizableNullableLiftable
...

मैं समझता हूं, कि एक से अधिक वेक्टरिज़ेबल-प्रकार अभी भी कुछ हद तक दर्द (और थोड़ा सुरुचिपूर्ण) है ... लेकिन कम से कम यह जूलिया में कष्टप्रद दोहराव (1) को हटा देगा (पंजीकरण करने के लिए _each_ नया जोड़ा @vectorize_Xarg पर कॉल के साथ कार्य करें)।

(1) ऐसा माना जा रहा है कि जूलिया कार्यों पर विरासत का समर्थन करता है (उदा: myfunction(...)<: Vectorizable ) - जो इसे v0.4.0 पर प्रकट नहीं होता है। जूलिया 0.4.0 में मुझे जो समाधान मिला वह सिर्फ एक हैक है ... आपको अभी भी अपना कार्य पंजीकृत करना है ... @vectorize_Xarg को कॉल करने से कहीं ज्यादा बेहतर नहीं है

एमए

मुझे अभी भी लगता है कि यह गलत अमूर्तता है। एक फ़ंक्शन जो "सदिश" हो सकता है या होना चाहिए, वह एक विशेष प्रकार का फ़ंक्शन नहीं है। _every_ फ़ंक्शन को map पर पास किया जा सकता है, इसे यह व्यवहार दे रहा है।

बीटीडब्लू, जिस बदलाव पर मैं जेबी/फ़ंक्शंस शाखा में काम कर रहा हूं, आप function f(x) <: T (हालांकि, स्पष्ट रूप से, केवल f की पहली परिभाषा के लिए) करने में सक्षम होंगे।

ठीक है, मुझे लगता है कि मैं बेहतर समझता हूं कि आप क्या खोज रहे हैं ... और यह वह नहीं है जो मैंने सुझाया था। मुझे लगता है कि मेरे सुझावों के साथ @johnmyleswhite के मुद्दों का भी हिस्सा हो सकता है ...

... लेकिन अगर मैं अब समझ गया कि समस्या क्या है, तो समाधान मुझे और भी आसान लगता है:

function call{T1,T2}(fn::Function, v1::Vector{T1}, v2::Vector{T2})
    RT = promote_type(T1,T2) #For type stability!
    return RT[fn(v1[i],v2[i]) for i in 1:length(v1)]
end

myadd(x::Number, y::Number) = x+y+1

चूंकि myadd प्रकार का है Function , इसे call फ़ंक्शन द्वारा फंस जाना चाहिए ... जो यह करता है:

call(myadd,collect(1:10),collect(21:30.0)) #No problem

लेकिन call किसी कारण से कार्यों पर स्वत: प्रेषण नहीं करता है (निश्चित नहीं क्यों):

myadd(collect(1:10),collect(21:30.0)) #Hmm... Julia v0.4.0 does not dispatch this to call...

लेकिन मुझे लगता है कि इस व्यवहार को बदलना बहुत मुश्किल नहीं होना चाहिए । व्यक्तिगत रूप से, मुझे नहीं पता कि मैं इस तरह के सर्वव्यापी कैच-ऑल फंक्शन बनाने के बारे में कैसा महसूस करता हूं, लेकिन ऐसा लगता है कि आप यही चाहते हैं।

कुछ अजीब मैंने देखा: जूलिया पहले से ही ऑटो-वेक्टराइज़ करता है यदि वे टाइप नहीं किए गए हैं:

myadd(x,y) = x+y+1 #This gets vectorized automatically, for some reason

आरई: बीटीडब्ल्यू ...:
ठंडा! मुझे आश्चर्य है कि कार्यों को घटाकर मैं कौन सी साफ-सुथरी चीजें कर पाऊंगा :)।

यदि वे टाइप नहीं किए गए हैं तो जूलिया पहले से ही ऑटो-वेक्टराइज़ करता है

ऐसा प्रतीत होता है क्योंकि फ़ंक्शन के अंदर प्रयुक्त + ऑपरेटर वेक्टरकृत है।

लेकिन मुझे लगता है कि इस व्यवहार को बदलना बहुत मुश्किल नहीं होना चाहिए। व्यक्तिगत रूप से, मुझे नहीं पता कि मैं इस तरह के सर्वव्यापी कैच-ऑल फंक्शन बनाने के बारे में कैसा महसूस करता हूं, लेकिन ऐसा लगता है कि आप यही चाहते हैं।

मैं आपके आरक्षण साझा करता हूं। आपके पास समझदारी से एक परिभाषा नहीं हो सकती है जो कहती है कि "यहां किसी भी फ़ंक्शन को कैसे कॉल करें", क्योंकि प्रत्येक फ़ंक्शन स्वयं कहता है कि इसे क्या करना है --- यह एक फ़ंक्शन है!

मुझे कहना चाहिए था: ... उपयोगकर्ता ने गैर-यूनिकोड इंफिक्स ऑपरेटरों को परिभाषित किया, क्योंकि मुझे नहीं लगता कि हम उपयोगकर्ताओं को इस तरह की मुख्य कार्यक्षमता तक पहुंचने के लिए यूनिकोड वर्णों को टाइप करने की आवश्यकता चाहते हैं। हालांकि मैं देख रहा हूं कि $ वास्तव में जोड़े गए लोगों में से एक है, इसलिए इसके लिए धन्यवाद! वाह, तो यह वास्तव में आज जूलिया में काम करता है (भले ही यह "तेज" न हो ... अभी तक):

जूलिया> ($) = नक्शा
जूलिया> पाप $ (0.5 * (abs2 $ (xy)))

@binarybana ↦ / \mapsto के बारे में कैसे?

julia> x, y = rand(3), rand(3);

julia> ↦ = map    # \mapsto<TAB>
map (generic function with 39 methods)

julia> sin ↦ (0.5 * (abs2 ↦ (x-y)))
3-element Array{Float64,1}:
 0.271196
 0.0927406
 0.0632608

वे भी हैं:

• ⤇ / \Mapsto
• ⟼ / \longmapsto
• ⟾ / \Longmapsto
• ⤅ / \twoheadmapsto
• ⊸ / \multimap (समानांतर नक्शा?)
• http://julia.readthedocs.org/hi/latest/manual/unicode-input

एफडब्ल्यूआईडब्ल्यू, मैं कम से कम शुरुआत में यह मानूंगा कि \mapsto लैम्ब्डा के लिए एक वैकल्पिक वाक्यविन्यास था, क्योंकि यह आमतौर पर गणित में प्रयोग किया जाता है और अनिवार्य रूप से (इसके ASCII अवतार में, -> ) जूलिया में भी . मुझे लगता है कि यह बल्कि भ्रमित करने वाला होगा।

गणित की बात करें ... मॉडल सिद्धांत में मैंने map को बिना कोष्ठक के टुपल में एक फ़ंक्शन लागू करके व्यक्त किया है। अर्थात्, यदि \bar{a}=(a_1, \dots, a_n) , तो f(\bar{a}) f(a_1, \dots, a_n) (अर्थात, अनिवार्य रूप से, apply ) है और f\bar{a} (f(a_1), \dots, f(a_n)) है map )। समरूपता, आदि को परिभाषित करने के लिए उपयोगी वाक्य रचना, लेकिन वह सब नहीं जो आसानी से एक प्रोग्रामिंग भाषा में स्थानांतरित किया जा सकता है: -}

\Mapsto जैसे किसी अन्य विकल्प के बारे में क्या आप इसे => (जोड़ी) के साथ भ्रमित करेंगे? मुझे लगता है कि दोनों प्रतीक यहां एक साथ अलग-अलग हैं:

• ->
• ↦

ऐसे बहुत से प्रतीक हैं जो एक जैसे दिखते हैं, उनमें से इतने सारे होने का क्या कारण होगा यदि हम केवल उन्हीं का उपयोग करें जो बहुत अलग दिखते हैं या शुद्ध ASCII हैं?

मुझे लगता है कि यह बल्कि भ्रमित करने वाला होगा।

मुझे लगता है कि दस्तावेज़ीकरण और अनुभव इसे हल करते हैं, क्या आप सहमत हैं?

प्रतीकों की तरह कई अन्य तीर भी हैं, मैं ईमानदारी से नहीं जानता कि गणित में उनका क्या उपयोग किया जाता है या नहीं, मैंने केवल इसे प्रस्तावित किया क्योंकि उनके नाम पर map है! :मुस्कुराओ:

मुझे लगता है कि मेरी बात यह है कि -> जूलिया का ASCII में ↦ का प्रतिनिधित्व करने का प्रयास है। तो ↦ का उपयोग करने का मतलब कुछ और है, यह सलाह नहीं दी जाती है। ऐसा नहीं है कि मैं उन्हें नेत्रहीन रूप से अलग नहीं बता सकता :-)

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

@ इस्माइल-वीसी आपके सुझाव के साथ समस्या यह है कि आपको map दो बार कॉल करने की आवश्यकता है, जबकि आदर्श समाधान में कोई अस्थायी सरणी शामिल नहीं होगी और map((a, b) -> sin(0.5 * abs2(a-b)), x, y) तक कम हो जाएगी। इसके अलावा, ↦ को दो बार दोहराना नेत्रहीन और टाइपिंग दोनों के लिए बहुत अच्छा नहीं है (जिसके लिए ASCII समकक्ष होना अच्छा होगा)।

आर उपयोगकर्ता इस विचार को नापसंद कर सकते हैं, लेकिन अगर हम ~ के मौजूदा इंफिक्स-मैक्रो स्पेशल केस पार्सिंग की ओर बढ़ते हैं (जीएलएम और डेटाफ्रेम जैसे पैकेजों को अपने फॉर्मूला डीएसएल को मैक्रो-पार्सिंग में बदलने की आवश्यकता होगी, रेफरी https: / /github.com/JuliaStats/GLM.jl/issues/116), जो एक इंफिक्स ascii ऑपरेटर की दुर्लभ वस्तु को मुक्त कर देगा।

a ~ b को आधार में map(a, b) के रूप में परिभाषित किया जा सकता है, और शायद a .~ b को broadcast(a, b) के रूप में परिभाषित किया जा सकता है? यदि यह एक पारंपरिक इंफिक्स ऑपरेटर के रूप में पार्स करता है तो मैक्रो डीएसएल आर फॉर्मूला इंटरफेस के अनुकरण की तरह मैक्रोज़ के अंदर ऑपरेटर की अपनी व्याख्या को लागू करने के लिए स्वतंत्र होगा, जैसा कि JuMP <= और == के साथ करता है। .

यह शायद सबसे सुंदर सुझाव नहीं है, लेकिन यदि आप उनका अत्यधिक उपयोग करते हैं तो गणित में शॉर्टहैंड भी नहीं हैं ... मेरा पसंदीदा .#&/@ है

:+1: कम विशेष आवरण और अधिक व्यापकता और स्थिरता के लिए, आप ~ और .~ के लिए जो अर्थ प्रस्तावित करते हैं, वह मुझे बहुत अच्छा लगता है।

+1 टोनी।

@tkelman स्पष्ट होने के लिए, आप कैसे लिखेंगे उदाहरण के लिए sin(0.5 * abs2(a-b)) पूरी तरह से वेक्टरकृत तरीके से?

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

तो यह वास्तव में इस मुद्दे को ठीक नहीं करेगा। :-/

अब तक sin(0.5 * abs2(a-b)) over (a, b) सिंटैक्स (या एक प्रकार, संभवतः एक इंफिक्स ऑपरेटर का उपयोग करके) सबसे आकर्षक है।

इस अंक का शीर्षक " map(func, x) के लिए वैकल्पिक वाक्यविन्यास" है। एक इंफिक्स ऑपरेटर का उपयोग अस्थायी को खत्म करने के लिए मानचित्र/लूप फ्यूजन को हल नहीं करता है, लेकिन मुझे लगता है कि यह सिंटैक्स की तुलना में एक व्यापक, संबंधित लेकिन तकनीकी रूप से अलग मुद्दा हो सकता है।

हां, मैं @tkelman से सहमत हूं, बिंदु map के लिए वैकल्पिक वाक्यविन्यास होना है, इसलिए मैंने \mapsto , ↦ का उपयोग करने का सुझाव दिया है। क्या @nalimilan का उल्लेख व्यापक और किसी अन्य मुद्दे IMHO, How to fully vecotrize expressions के लिए उपयुक्त है?

<rambling>
यह मुद्दा अब एक साल से अधिक समय से चल रहा है (और अनिश्चित काल तक जारी रह सकता है क्योंकि कई अन्य मुद्दे अभी हैं)! लेकिन अब हमारे पास Alternative syntax for map(func, x) हो सकता है । ± 450 जूलियन योगदानकर्ताओं में से केवल 41 ही इस मुद्दे को ढूंढने में सक्षम हैं और/या एक राय साझा करने के इच्छुक हैं (यह एक जीथब मुद्दे के लिए बहुत कुछ है लेकिन इस मामले में स्पष्ट रूप से पर्याप्त नहीं है), सभी में इतने अलग सुझाव नहीं हैं (जो एक ही अवधारणा के केवल मामूली बदलाव नहीं हैं)।

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

@ इस्माइल-वीसी: यदि आप वास्तव में एक मतदान करना चाहते हैं, तो आपको सबसे पहले जो करना चाहिए वह उस प्रश्न पर ध्यान से विचार करना है जिसे आप पूछना चाहते हैं। आप यह उम्मीद नहीं कर सकते हैं कि हर कोई पूरे धागे को पढ़ेगा और उन विकल्पों को संक्षेप में प्रस्तुत करेगा जो व्यक्तिगत रूप से चर्चा के लिए तैयार हैं।

map(func, x) में map(v -> sin(0.5 * abs2(v)), x) जैसी चीजें भी शामिल हैं, और इस धागे पर चर्चा की गई है। आइए इसे किसी अन्य सूत्र पर न ले जाएँ, क्योंकि इससे ऊपर चर्चा किए गए सभी प्रस्तावों को ध्यान में रखना कठिन हो जाएगा।

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

@ इस्माइल-वीसी पोल यहां IMHO की मदद करने की संभावना नहीं है। हम यह पता लगाने की कोशिश नहीं कर रहे हैं कि कई समाधानों में से कौन सा सबसे अच्छा है, बल्कि एक ऐसा समाधान खोजने की कोशिश कर रहे हैं जो वास्तव में पहले से किसी ने नहीं पाया है। यह चर्चा पहले से ही लंबी है और इसमें बहुत से लोग शामिल हैं, मुझे नहीं लगता कि और जोड़ने से मदद मिलेगी।

@ इस्माइल-वीसी यह ठीक है, बेझिझक मतदान करें। वास्तव में मैंने अतीत में मुद्दों पर कुछ डूडल पोल किए हैं (जैसे http://doodle.com/poll/s8734pcue8yxv6t4)। मेरे अनुभव में, मुद्दों पर चर्चा करने की तुलना में समान या कम लोग मतदान में मतदान करते हैं। यह बहुत विशिष्ट, अक्सर सतही/वाक्यविन्यास मुद्दों के लिए समझ में आता है। लेकिन जब आप मौजूदा विकल्पों में से केवल चुनाव कर सकते हैं तो एक सर्वेक्षण नए विचारों को कैसे उत्पन्न करेगा?

बेशक इस मुद्दे का वास्तविक लक्ष्य निहित रूप से वेक्टरकृत कार्यों को खत्म करना है। सिद्धांत रूप में, map के लिए सिंटैक्स उसके लिए पर्याप्त है, क्योंकि ये सभी कार्य हर मामले में केवल map कर रहे हैं।

मैंने इसके लिए मौजूदा गणित अंकन की तलाश करने की कोशिश की है, लेकिन आप इस आशय की टिप्पणियां देखते हैं कि अंकन के लिए ऑपरेशन बहुत महत्वहीन है! गणितीय संदर्भ में मनमानी कार्यों के मामले में मैं लगभग इस पर विश्वास कर सकता हूं। हालाँकि सबसे नज़दीकी चीज़ हैडमर्ड उत्पाद संकेतन प्रतीत होती है, जिसमें कुछ सामान्यीकरण हैं: https://en.wikipedia.org/wiki/Hadamard_product_ (मैट्रिसेस)#Analogous_Operations

यह हमें sin∘x के साथ छोड़ देता है जैसा कि @rfourquet ने सुझाव दिया था। बहुत उपयोगी नहीं लगता, क्योंकि इसके लिए यूनिकोड की आवश्यकता होती है और वैसे भी व्यापक रूप से ज्ञात नहीं है।

@nalimilan , मुझे लगता है कि आप बस sin(0.5 * abs2(a-b)) ~ (a,b) करेंगे जो map((a,b)->sin(0.5 * abs2(a-b)), (a,b)) में अनुवाद करेगा। सुनिश्चित नहीं है कि यह काफी सही है, लेकिन मुझे लगता है कि यह काम करेगा।

मैं लेट-मी-दे-यू-ए-विशाल-जटिल-अभिव्यक्ति-और-आप-पूरी तरह से ऑटो-वेक्टराइज़-इट-फॉर-मी समस्या में बहुत अधिक तल्लीन करने से सावधान हूं। मुझे लगता है कि उस संबंध में अंतिम समाधान अभिव्यक्तियों/कार्यों + क्वेरी योजना आदि के डीएजी पर पूर्ण निर्माण कर रहा है। लेकिन मुझे लगता है कि यह map के लिए सुविधाजनक वाक्यविन्यास होने की तुलना में तलना करने के लिए एक बहुत बड़ी मछली है।

@quinnj हाँ, यह अनिवार्य रूप से ऊपर प्रस्तावित over सिंटैक्स है, सिवाय एक इंफिक्स ऑपरेटर के।

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

@johnmyleswhite सहमत हैं, एक डीएसएल उर्फ ​​​​लिंक की तरह दिखने लगते हैं

पोस्ट किए गए विषय पर, आप |> 'पाइप' ऑपरेटर को विशेषज्ञ बना सकते हैं और मानचित्र शैली की कार्यक्षमता प्राप्त कर सकते हैं। आप इसे फ़ंक्शन को डेटा में पाइप के रूप में पढ़ सकते हैं। एक अतिरिक्त बोनस के रूप में आप इसका उपयोग फंक्शन कंपोजिशन करने के लिए कर सकते हैं।

julia> (|>)(x::Function, y...) = map(x, y... )
|> (generic function with 8 methods)

julia> (|>)(x::Function, y::Function) = (z...)->x(y(z...))
|> (generic function with 8 methods)

julia> sin |> cos |> [ 1,2,3 ]
3-element Array{Float64,1}:
  0.514395
 -0.404239
 -0.836022

julia> x,y = rand(3), rand(3)
([0.8883630054185454,0.32542923024720194,0.6022157767415313],    [0.35274912207468145,0.2331784754319688,0.9262490059844113])

julia> sin |> ( 0.5 *( abs( x - y ) ) )
3-element Array{Float64,1}:
 0.264617
 0.046109
 0.161309

@johnmyleswhite यह सच है, लेकिन सार्थक मध्यवर्ती लक्ष्य हैं जो काफी मामूली हैं। मेरी शाखा पर, मल्टी-ऑपरेशन वेक्टरकृत अभिव्यक्तियों का map संस्करण पहले से ही हमारे पास अब की तुलना में तेज़ है। तो यह पता लगाना कि इसे आसानी से कैसे स्थानांतरित किया जाए, कुछ हद तक जरूरी है।

@johnmyleswhite यकीन नहीं है। बहुत सी SQL पंक्तियों को चुनने, क्रम देने और मर्ज करने के बारे में है। यहां हम केवल तत्व-वार फ़ंक्शन को लागू करने के बारे में बात कर रहे हैं। इसके अलावा, SQL तत्व-वार संचालन (जैसे > , LN ) से कटौती (जैसे SUM ) को अलग करने के लिए कोई सिंटैक्स प्रदान नहीं करता है। उत्तरार्द्ध वर्तमान में जूलिया की तरह ही स्वचालित रूप से वेक्टरकृत हैं।

@JeffBezanson \circ के उपयोग की सुंदरता यह है कि यदि आप अनुक्रमित परिवार को इंडेक्स सेट (जो मानक गणितीय "कार्यान्वयन" है) से एक फ़ंक्शन के रूप में व्याख्या करते हैं, तो _is_ बस संरचना का मानचित्रण करें। तो (sin ∘ x)(i)=sin(x(i)) , या, बल्कि sin(x[i]) ।

पाइप का उपयोग, जैसा कि @mdcfrancis उल्लेख करता है, अनिवार्य रूप से केवल "आरेख क्रम" संरचना होगी, जो अक्सर गणित में (संभवतः वसा) अर्धविराम (या विशेष रूप से श्रेणी सिद्धांत के सीएस अनुप्रयोगों) के साथ किया जाता है - लेकिन हमारे पास पहले से ही पाइप है ऑपरेटर, बिल्कुल।

यदि इनमें से कोई भी कंपोजिशन ऑपरेटर ठीक नहीं है, तो कोई अन्य का उपयोग कर सकता है। उदाहरण के लिए, कम से कम कुछ लेखक अमूर्त तीर/आकृतिवाद संरचना के लिए निम्न \cdot का उपयोग करते हैं, क्योंकि यह अनिवार्य रूप से तीरों के समूह (अधिक या कम) का "गुणा" है।

और अगर कोई ASCII एनालॉग चाहता था: ऐसे लेखक भी हैं जो वास्तव में गुणन को इंगित करने के लिए एक अवधि का उपयोग करते हैं। (मैंने देखा होगा कि कुछ लोग इसे रचना के लिए भी इस्तेमाल करते हैं; याद नहीं कर सकते।)

तो किसी के पास sin . x हो सकता है ... लेकिन मुझे लगता है कि यह भ्रमित करने वाला होगा :-}

फिर भी ... वह अंतिम सादृश्य वास्तव में शुरुआती प्रस्तावों में से एक के लिए एक तर्क हो सकता है, अर्थात sin.(x) । (या शायद यह दूर की कौड़ी है।)

आइए इसे एक अलग कोण से देखें, मुझे गोली मत मारो।

यदि हम .. को collect(..(A,B)) == ((a[1],..., a[n]), (b[1], ...,b[n])) == zip(A,B) से परिभाषित करते हैं, तो औपचारिक रूप से T[x,y,z] = [T(x), T(y), T(z)] का उपयोग करके यह माना जाता है कि

map(f,A,B) = [f(a[1],b[1]), ..., f(a[n],b[n])] = f[zip(A,B)...] = f[..(A,B)]

यह मानचित्र के लिए कम से कम एक सिंटैक्स को प्रेरित करता है जो सरणी निर्माण के लिए सिंटैक्स में हस्तक्षेप नहीं करता है। :: या table के साथ एक्सटेंशन f[::(A,B)] = [f(a[i], b[j]) for i in 1:n, j in 1:n] कम से कम एक दूसरे दिलचस्प उपयोग के मामले की ओर जाता है।

आप जो प्रश्न पूछना चाहते हैं, उस पर ध्यान से विचार करें।

@toivoh धन्यवाद, मैं करूँगा। मैं वर्तमान में कई मतदान/सर्वेक्षण सॉफ्टवेयर का मूल्यांकन कर रहा हूं। इसके अलावा, मैं केवल पसंदीदा सिंटैक्स के बारे में मतदान करूंगा, जो पूरे धागे को पढ़ना चाहते हैं, वे इसे करेंगे, यह न मानें कि किसी और को ऐसा करने में दिलचस्पी नहीं होगी।

एक समाधान खोजें जो वास्तव में पहले से ही किसी ने नहीं पाया है

@nalimilan हमारे बीच कोई नहीं, यानी। :मुस्कुराओ:

जब आप केवल मौजूदा विकल्पों में से चुनाव कर सकते हैं तो एक सर्वेक्षण नए विचारों को कैसे उत्पन्न करेगा?
मुद्दे के सूत्र में चर्चा की तुलना में समान या कम लोग मतदान में मतदान करते हैं।

@JeffBezanson मुझे यह जानकर खुशी हुई कि आप पहले ही चुनाव कर चुके हैं, इसे जारी रखें!

• आप अपने चुनावों का प्रचार कैसे कर रहे हैं?
• पोल/सर्वेक्षण सॉफ़्टवेयर से मैंने अब तक kwiksurveys.com का मूल्यांकन किया है, उपयोगकर्ताओं को _none is me for me_ विकल्प के बजाय अपनी राय जोड़ने दें।

sin∘x बहुत उपयोगी नहीं लगता, क्योंकि इसके लिए यूनिकोड की आवश्यकता होती है और वैसे भी व्यापक रूप से ज्ञात नहीं है।

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

∘ की मिसाल है, तो समस्या यह है कि यह यूनिकोड है? क्यों? तब हम बाकी व्यापक रूप से ज्ञात यूनिकोड का उपयोग कब शुरू करने जा रहे हैं? कभी नहीँ?

उस तर्क से, जूलिया वैसे भी व्यापक रूप से ज्ञात नहीं है, हालांकि जो लोग सीखना चाहते हैं, वे करेंगे। मेरी बहुत विनम्र राय में, यह मेरे लिए कोई मतलब नहीं रखता है।

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

क्या ASCII विकल्प के रूप में * का उपयोग/ओवरलोड करना पूरी तरह से पागल होगा? मैं कहूंगा कि यह तर्क दिया जा सकता है कि यह गणितीय रूप से कुछ समझ में आता है, लेकिन मुझे लगता है कि कभी-कभी इसका अर्थ समझना मुश्किल हो सकता है ... (फिर फिर, यदि यह map कार्यक्षमता तक सीमित है, तो map पहले से ही एक ASCII विकल्प है, नहीं?)

\circ के उपयोग की सुंदरता यह है कि यदि आप एक अनुक्रमित परिवार को इंडेक्स सेट (जो मानक गणितीय "कार्यान्वयन" है) से एक फ़ंक्शन के रूप में व्याख्या करते हैं, तो मैपिंग _is_ बस संरचना।

मुझे यकीन नहीं है कि मैं इसे खरीदता हूं।

@hayd इसका कौन सा हिस्सा? कि एक अनुक्रमित परिवार (उदाहरण के लिए, एक अनुक्रम) को इंडेक्स सेट से एक फ़ंक्शन के रूप में देखा जा सकता है, या उस पर मैपिंग रचना बन जाती है? या कि यह इस मामले में एक उपयोगी परिप्रेक्ष्य है?

मुझे लगता है कि पहले दो (गणितीय) अंक बहुत ही विवादास्पद हैं। लेकिन, हाँ, मैं यहाँ इसका उपयोग करने के लिए दृढ़ता से वकालत नहीं करने जा रहा हूँ - यह ज्यादातर "आह, वह थोड़े फिट बैठता है!" प्रतिक्रिया।

@mlhetland |> -> के काफी करीब है और आज भी काम करता है - इसमें सही सहयोगी होने का 'लाभ' भी है।

x = parse( "sin |> cos |> [1,2]" )
:((sin |> cos) |> [1,2])

@mdcfrancis ज़रूर। लेकिन यह उस रचना व्याख्या को बदल देता है जिसे मैंने उसके सिर पर रेखांकित किया था। यानी, sin∘x बराबर होगा x |> sin , नहीं?

पीएस: हो सकता है कि यह "बीजगणित" में खो गया हो, लेकिन टाइप किए गए सरणी निर्माण T[x,y,z] में कार्यों की इजाजत देता है जैसे कि f[x,y,z] [f(x),f(y),f(z)] सीधे देता है

map(f,A) == f[A...]

जो काफी पठनीय है और इसे सिंटैक्स के रूप में माना जा सकता है।

यह चालाकी है। लेकिन मुझे संदेह है कि अगर हम इसे काम कर सकते हैं, तो sin[x...] वास्तव में वर्बोसिटी पर sin(x) या sin~x आदि पर हार जाता है।

सिंटैक्स [sin xs] के बारे में क्या?

यह सिंटैक्स में सरणी समझ के समान है [sin(x) for x in xs] ।

@mlhetland sin |> x === नक्शा (पाप, x)

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

@mdcfrancis हाँ, मुझे लगता है कि आप यही लक्ष्य कर रहे हैं। जो चीजों को उलट देता है (जैसे @tkelman दोहराता है) wrt। मैंने जिस रचना व्याख्या को रेखांकित किया है।

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

[1, 2] mapall
  +([2, 3]) map
  ^(2, _) chain
  { a = _ + 1
    b = _ - 1
    [a..., b...] } chain
  sum chain
  [ _, 2, 3] chain
  reduce(+, _)

प्रदर्शन में सुधार के लिए एक पंक्ति में कई मानचित्रों को स्वचालित रूप से एक मानचित्र में जोड़ा जा सकता है। यह भी ध्यान दें कि मुझे लगता है कि मानचित्र में किसी प्रकार की ऑटो-प्रसारण सुविधा होगी। शुरुआत में [1, 2] को _ से बदलने से इसके बजाय एक अनाम फ़ंक्शन बन सकता है। नोट मैं चेनिंग के लिए आर के मैग्रिटर नियमों का उपयोग कर रहा हूं (चेनिंग थ्रेड में मेरी पोस्ट देखें)।

हो सकता है कि यह एक डीएसएल की तरह दिखने लगे।

मैं लंबे समय से इस मुद्दे का अनुसरण कर रहा हूं, और अब तक कोई टिप्पणी नहीं की है, लेकिन यह आईएमएचओ के हाथ से निकलने लगा है।

मैं मानचित्र के लिए स्वच्छ वाक्यविन्यास के विचार का पुरजोर समर्थन करता हूं। मुझे @tkelman का ~ का सुझाव सबसे ज्यादा पसंद है क्योंकि यह इस तरह की बुनियादी कार्यक्षमता के लिए ASCII के भीतर रहता है, और मुझे sin~x बहुत पसंद है। जैसा कि ऊपर चर्चा की गई है, यह बहुत परिष्कृत एक-लाइनर शैली मानचित्रण की अनुमति देगा। sin∘x का उपयोग भी ठीक रहेगा। कुछ और जटिल के लिए मुझे लगता है कि एक उचित लूप बहुत स्पष्ट है (और आमतौर पर सबसे अच्छा प्रदर्शन)। मुझे वास्तव में बहुत अधिक 'जादुई' प्रसारण पसंद नहीं है, इससे कोड का पालन करना बहुत कठिन हो जाता है। एक स्पष्ट लूप आमतौर पर स्पष्ट होता है।

इसका मतलब यह नहीं है कि इस तरह की कार्यक्षमता को नहीं जोड़ा जाना चाहिए, लेकिन आइए पहले एक अच्छा संक्षिप्त map सिंटैक्स लें, खासकर जब यह सुपर फास्ट होने वाला है ( jb/functions शाखा के मेरे परीक्षणों से) .

ध्यान दें कि jb/functions के प्रभावों में से एक यह है कि broadcast(op, x, y) में अनुकूलित संस्करण x .op y के समान ही अच्छा प्रदर्शन है जो मैन्युअल रूप से op पर प्रसारण को विशेषीकृत करता है।

कुछ और जटिल के लिए मुझे लगता है कि एक उचित लूप बहुत स्पष्ट है (और आमतौर पर सबसे अच्छा प्रदर्शन)। मुझे वास्तव में बहुत अधिक 'जादुई' प्रसारण पसंद नहीं है, इससे कोड का पालन करना बहुत कठिन हो जाता है। एक स्पष्ट लूप आमतौर पर स्पष्ट होता है।

मैं सहमत नहीं हूं। exp(2 * x.^2) पूरी तरह से पठनीय है, और [exp(2 * v^2) for v in x] से कम वर्बोज़ है। आईएमएचओ यहां चुनौती है कि लोगों को पूर्व का उपयोग करने की अनुमति देकर उन्हें फंसाने से बचें (जो प्रतियां आवंटित करता है और संचालन को फ्यूज नहीं करता है): इसके लिए, हमें एक वाक्यविन्यास खोजने की जरूरत है जो काफी छोटा होगा ताकि धीमे फॉर्म को बहिष्कृत किया जा सके।

अधिक विचार। फ़ंक्शन को कॉल करते समय आप कई संभावित चीजें करना चाहेंगे:

बिना किसी तर्क के लूप (श्रृंखला)
केवल जंजीर तर्क के माध्यम से लूप (मानचित्र)
सभी तर्कों के माध्यम से लूप (मैपल)

उपरोक्त में से प्रत्येक को इसके द्वारा संशोधित किया जा सकता है:
किसी आइटम को लूप में चिह्नित करना (~)
किसी आइटम को लूप न करने के लिए चिह्नित करना ( [] का एक अतिरिक्त सेट)

वाक्य रचना की अवहेलना करते हुए, इकाई योग्य वस्तुओं को स्वचालित रूप से नियंत्रित किया जाना चाहिए।
सिंगलटन आयामों का विस्तार स्वचालित रूप से होना चाहिए यदि कम से कम दो तर्क हैं जिन्हें लूप किया जा रहा है

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

sin[x...] वास्तव में sin(x) या sin~x आदि के लिए शब्दशः खो देता है।

साथ ही, विचार जारी रखते हुए, मानचित्र sin[x...] [f(x...)] पर एक कम उत्सुक संस्करण है।
वाक्य रचना

[exp(2 * (...x)^2)]

या [exp(2 * (x..)^2)] जैसा कुछ उपलब्ध होगा और यदि कभी वास्तविक टैसिट फ़ंक्शन चेनिंग पेश की जाती है तो स्वयं को समझाएगा।

@nalimilan हाँ, लेकिन यह मेरी 'वन-लाइनर' श्रेणी में फिट बैठता है जो मैंने कहा था कि बिना लूप के ठीक था।

जबकि हम अपनी सभी इच्छाओं को सूचीबद्ध कर रहे हैं: मेरे लिए बहुत अधिक महत्वपूर्ण यह होगा कि map के परिणाम आवंटन या प्रतिलिपि के बिना असाइन किए जाने योग्य हों। यह एक और कारण है कि मैं अभी भी प्रदर्शन महत्वपूर्ण कोड के लिए लूप पसंद करूंगा, लेकिन अगर इसे कम किया जा सकता है (# 249 वर्तमान में आशावादी एटीएम नहीं दिख रहा है) तो यह सब और अधिक आकर्षक हो जाता है।

मानचित्र के परिणाम आवंटन या प्रतिलिपि के बिना असाइन किए जाने योग्य हैं

क्या आप इस पर थोड़ा विस्तार कर सकते हैं? आप निश्चित रूप से map के परिणाम को बदल सकते हैं।

मुझे लगता है कि उसका मतलब है map के आउटपुट को प्रीआलोकेटेड सरणी में संग्रहित करना।

हाँ बिल्कुल। क्षमा करें यदि यह पहले से ही संभव है।

आह, बिल्कुल। हमारे पास map! है, लेकिन जैसा कि आप देखते हैं #249 ऐसा करने के लिए कुछ अच्छे तरीके से पूछ रहा है।

@jtravs मैंने ऊपर LazyArray (https://github.com/JuliaLang/julia/issues/8450#issuecomment-65106563) के साथ एक समाधान प्रस्तावित किया, लेकिन अभी तक प्रदर्शन आदर्श नहीं था।

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

हाँ map! बिल्कुल सही है। यह अच्छा होगा यदि यहां काम करने वाली कोई अच्छी वाक्यविन्यास चीनी भी उस मामले को कवर करे। क्या हमारे पास वह x := ... नहीं हो सकता है जो RHS को x पर परोक्ष रूप से मैप करता है।

मैंने चेनमैप नामक एक पैकेज रखा जो मैपिंग और चेनिंग को एकीकृत करता है।

यहाँ एक संक्षिप्त उदाहरण है:

<strong i="7">@chain</strong> begin
  [1, 2]
  -(1)
  (_, _)
  map_all(+)
  <strong i="8">@chain_map</strong> begin
    -(1)
    ^(2. , _)
  end
  begin
    a = _ - 1
    b = _ + 1
    [a, b]
  end
  sum
end

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

1. f[a...] से शुरू जो वास्तव में @Jutho , सम्मेलन द्वारा प्रस्तावित किया गया था
   कि एक सदिश a, b . के लिए

f[a...] == map(f, a[:])
f[a..., b...] == map(f, a[:], b[:])
etc

जो नए प्रतीकों का परिचय नहीं देता है।

2.) इसके शीर्ष पर, मैं एक अतिरिक्त ऑपरेटर की शुरूआत का प्रस्ताव रखूंगा: एक _shape संरक्षित_ स्प्लैटिंग ऑपरेटर .. (कहते हैं)। ऐसा इसलिए है क्योंकि ... एक _flat_ स्पैटिंग ऑपरेटर है, इसलिए f[a...] को एक वेक्टर लौटाना चाहिए और एक सरणी नहीं, भले ही a n -आयामी हो। यदि .. चुना जाता है, तो इस संदर्भ में,

f[a.., ] == map(f, a)
f[a.., b..] == map(f, a, b)

और परिणाम तर्कों के आकार को प्राप्त करता है। प्रसारण की अनुमति

f[a.., b..] == broadcast(f, a, b)

लिखने की अनुमति देगा जैसे सोचता है

sum(*[v.., v'..]) == dot(v,v)

ह्यूरेका?

यह मैपिंग अभिव्यक्तियों में मदद नहीं करता है, है ना? over सिंटैक्स के फायदों में से एक यह है कि यह अभिव्यक्तियों के साथ कैसे काम करता है:

sin(x * (y - 2)) over x, y  == map((x, y) -> sin(x * (y - 2)), x, y) 

ठीक है, संभवतः [sin(x.. * y..)] या sin[x.. * y..] ऊपर के माध्यम से यदि आप इसकी अनुमति देना चाहते हैं। मुझे यह ओवर सिंटैक्स से थोड़ा अधिक पसंद है क्योंकि यह एक दृश्य संकेत देता है कि फ़ंक्शन ऑपरेटर तत्वों पर है न कि कंटेनरों पर।

लेकिन क्या आप इसे इतना आसान नहीं बना सकते हैं कि x.. बस x से अधिक मैप करें? तो @johansigfrids उदाहरण होगा:

sin(x.. * (y.. - 2))  == map((x, y) -> sin(x * (y - 2)), x, y)

@jtravs स्कोपिंग ( [println(g(x..))] बनाम println([g(x..)]) ) और स्थिरता [x..] = x के कारण।

एक और संभावना यह है कि x.. = x[:, 1], x[:, 2], etc. को प्रमुख उपसरणियों (स्तंभों) के आंशिक विभाजन के रूप में और ..y को अनुगामी उपसरणियों के आंशिक विभाजन के रूप में लिया जाए ..y = y[1,:], y[2,:] । यदि दोनों अलग-अलग सूचकांकों पर चलते हैं तो इसमें कई दिलचस्प मामले शामिल हैं

[f(v..)] == [f(v[i]) for i in 1:m ]
[v.. * v..] == [v[i] * v[i] for 1:m]
[v.. * ..v] == [v[i] * v[j] for i in 1:m, j in 1:n]
[f(..A)] == [f(A[:, j]) for j in 1:n]
[f(A..)] == [f(A[i, :]) for i in 1:m]
[dot(A.., ..A)] == [dot(A[:,i], A[j,:]) for i in 1:m, j in 1:n] == A*A
[f(..A..)] == [f(A[i,j]) for i in 1:m, j in 1:n]
[v..] == [..v] = v
[..A..] == A

( v एक वेक्टर, A एक मैट्रिक्स)

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

आप अव्यवस्था के बारे में सही हैं, मुझे लगता है और मैंने अपने प्रस्ताव को अनुकूलित और व्यवस्थित करने का प्रयास किया। हर किसी के धैर्य को और अधिक न करने के लिए मैंने मानचित्रों और सूचकांकों आदि के बारे में अपने विचार एक सार https://gist.github.com/mschauer/b04e000e9d0963e40058 में लिखे।

इस धागे के माध्यम से पढ़ने के बाद, मेरी प्राथमिकता अब तक _both_ f.(x) साधारण चीजों के लिए और लोगों को वेक्टरकृत कार्यों के लिए इस्तेमाल किया जाएगा (" . = वेक्टरकृत" मुहावरा बहुत आम है), और f(x^2)-x over x अधिक जटिल अभिव्यक्तियों के लिए।

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

over सिंटैक्स वास्तव में मुझे गलत तरीके से परेशान करता है। यह सिर्फ मेरे साथ हुआ क्यों: यह मानता है कि अभिव्यक्ति में प्रत्येक चर के सभी उपयोग वेक्टरकृत या गैर-वेक्टर हैं, जो कि मामला नहीं हो सकता है। उदाहरण के लिए, log(A) .- sum(A,1) - मान लें कि हमने log के वैश्वीकरण को हटा दिया है। आप अभिव्यक्तियों पर फ़ंक्शंस को वेक्टराइज़ नहीं कर सकते हैं, जो कि काफी बड़ी कमी की तरह लगता है अगर मैं exp(log(A) .- sum(A,1)) लिखना चाहता हूं और exp और log वेक्टरकृत और sum नहीं?

@StefanKarpinski , तो आपको या तो exp.(log.(A) .- sum(A,1)) करना चाहिए और अतिरिक्त अस्थायी स्वीकार करना चाहिए (उदाहरण के लिए इंटरैक्टिव उपयोग में जहां प्रदर्शन महत्वपूर्ण नहीं है), या s = sum(A, 1); exp(log(A) - s) over A (हालांकि यह बिल्कुल सही नहीं है यदि sum(A,1) एक वेक्टर है और आप प्रसारण चाहते थे); आपको बस एक समझ का उपयोग करना पड़ सकता है। कोई फर्क नहीं पड़ता कि हम किस सिंटैक्स के साथ आते हैं, हम सभी संभावित मामलों को कवर नहीं करने जा रहे हैं, और आपका उदाहरण विशेष रूप से समस्याग्रस्त है क्योंकि किसी भी "स्वचालित" सिंटैक्स को यह जानना होगा कि sum शुद्ध है और यह हो सकता है लूप/मानचित्र से बाहर फहराया गया।

मेरे लिए, पहली प्राथमिकता broadcast(f, x...) या map(f, x...) के लिए $ f.(x...) सिंटैक्स है ताकि हम @vectorize से छुटकारा पा सकें। उसके बाद, हम map और समझ के अधिक सामान्य उपयोगों को संक्षिप्त करने के लिए over (या जो भी) जैसे सिंटैक्स पर काम करना जारी रख सकते हैं।

@stevengj मुझे नहीं लगता कि दूसरा उदाहरण काम करता है, क्योंकि - प्रसारित नहीं होगा। मान लें कि A एक मैट्रिक्स है, आउटपुट सिंगल-पंक्ति मैट्रिक्स का एक मैट्रिक्स होगा, जिनमें से प्रत्येक A के तत्व का लॉग है जो पहले आयाम के साथ रकम के वेक्टर को घटाता है। आपको broadcast((x, y)->exp(log(x)-y), A, sum(A, 1)) की आवश्यकता होगी। लेकिन मुझे लगता है कि map के लिए एक संक्षिप्त सिंटैक्स होना उपयोगी है और broadcast के लिए भी एक संक्षिप्त सिंटैक्स होने की आवश्यकता नहीं है।

क्या फ़ंक्शन जो ऐतिहासिक रूप से sin जैसे ऑटो-वेक्टराइज़ किए गए हैं, नए सिंटैक्स के साथ ऐसा ही जारी रहेगा, या क्या यह पदावनत हो जाएगा? मुझे चिंता है कि f. सिंटैक्स भी वैज्ञानिक प्रोग्रामर के एक बड़े दल के लिए 'गॉचा' की तरह महसूस करेगा जो वैचारिक लालित्य तर्कों से प्रेरित नहीं हैं।

मेरी भावना यह है कि ऐतिहासिक रूप से वेक्टरकृत कार्यों जैसे sin को sin. के पक्ष में बहिष्कृत किया जाना चाहिए, लेकिन उन्हें अर्ध-स्थायी रूप से बहिष्कृत किया जाना चाहिए (जैसा कि बाद के रिलीज में पूरी तरह से हटा दिया गया है) अन्य वैज्ञानिक भाषाओं के उपयोगकर्ताओं का लाभ।

f.(args...) के साथ एक मामूली (?) समस्या: हालांकि object.(field) सिंटैक्स का उपयोग अधिकांश भाग के लिए शायद ही कभी किया जाता है और संभवतः getfield(object, field) के साथ बहुत अधिक दर्द के बिना प्रतिस्थापित किया जा सकता है, फिर भी एक है Base.(:+)(....) = .... फ़ॉर्म की विधि परिभाषाओं/संदर्भों के _lot_, और इन्हें getfield में बदलना दर्दनाक होगा।

एक कामकाज होगा:

• अन्य सभी f.(args...) $ की तरह Base.(:+) को map(Base, :+) में बदल दें, लेकिन पश्चगामी संगतता के लिए एक पदावनत विधि map(m::Module, s::Symbol) = getfield(m, s) को परिभाषित करें
• सिंटैक्स Base.:+ (जो वर्तमान में विफल रहता है) का समर्थन करें और Base.(:+) के लिए बहिष्करण चेतावनी में इसकी अनुशंसा करें

मैं फिर से पूछना चाहता हूं - अगर ऐसा कुछ है जो हम 0.5.0 में कर सकते हैं? मुझे लगता है कि कई वेक्टरकृत रचनाकारों के बहिष्करण के कारण यह महत्वपूर्ण है। मैंने सोचा कि मैं इसके साथ ठीक हो जाऊंगा, लेकिन मुझे map(Int32, a) के बजाय int32(a) थोड़ा थकाऊ लगता है।

क्या यह मूल रूप से इस बिंदु पर सिंटैक्स चुनने का मामला है?

क्या यह मूल रूप से इस बिंदु पर सिंटैक्स चुनने का मामला है?

मुझे लगता है कि @stevengj ने अपने पीआर https://github.com/JuliaLang/julia/pull/15032 में .sin(x) $ के बजाय sin.(x) लिखने के पक्ष में अच्छे तर्क दिए। तो मैं कहूंगा कि रास्ता साफ हो गया है।

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

@JeffBezanson मैं इस पर मील का पत्थर 0.5.0 पर वापस ला रहा हूं ताकि इसे ट्राइएज चर्चा के दौरान लाया जा सके - मुख्य रूप से यह सुनिश्चित करने के लिए कि मैं नहीं भूलूं।

क्या #15032 call के लिए भी काम करता है - जैसे Int32.(x) ?

@ViralBShah , हाँ। किसी भी f.(x...) को सिंटैक्स स्तर पर map(f, broadcast, x...) में बदल दिया जाता है, चाहे वह किसी भी प्रकार का हो f ।

यह . का मुख्य लाभ है जैसे f[x...] , जो अन्यथा आकर्षक है (और इसके लिए कोई पार्सर परिवर्तन की आवश्यकता नहीं होगी) लेकिन केवल f::Function के लिए काम करेगा। f[x...] भी T[...] सरणी समझ के साथ वैचारिक रूप से थोड़ा टकराता है। हालांकि मुझे लगता है कि @StefanKarpinski को ब्रैकेट सिंटैक्स पसंद है?

(एक और उदाहरण लेने के लिए, PyCall में o::PyObject ऑब्जेक्ट्स कॉल करने योग्य हैं, पायथन ऑब्जेक्ट o की __call__ विधि का आह्वान करते हुए, लेकिन वही ऑब्जेक्ट्स o[...] भी समर्थन कर सकते हैं f[x...] प्रसारण के साथ थोड़ा संघर्ष करेगा, लेकिन o.(x...) प्रसारण के साथ ठीक काम करेगा।)

call अब और मौजूद नहीं है।

(मुझे @nalimilan का यह तर्क भी पसंद है कि f.(x...) .( को .+ आदि का एनालॉग बनाता है।)

हां बिंदुवार सादृश्य वह है जो मुझे सबसे अच्छा भी लगता है। क्या हम आगे बढ़ सकते हैं और विलय कर सकते हैं?

क्या मॉड्यूल के साथ गेटफील्ड वास्तविक बहिष्करण होना चाहिए?

@tkelman , किसके विपरीत? हालांकि, Base.(:+) (यानी शाब्दिक प्रतीक तर्क) के लिए बहिष्करण चेतावनी $# Base.:+ का सुझाव देना चाहिए, न कि getfield । (_Update_: विधि परिभाषाओं को संभालने के लिए सिंटैक्स बहिष्करण की आवश्यकता है।)

@ViralBShah , क्या गुरुवार की ट्राइएज चर्चा में इस पर कोई फैसला हुआ? #15032 विलय के लिए बहुत अच्छी स्थिति में है, मुझे लगता है।

मुझे लगता है कि वायरल ने कॉल का वह हिस्सा मिस कर दिया। मेरी धारणा यह है कि कई लोगों के पास अभी भी f.(x) के सौंदर्यशास्त्र के बारे में आरक्षण है और वे या तो पसंद कर सकते हैं

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

हां, मेरे पास कुछ आरक्षण हैं लेकिन मुझे अभी f.(x) से बेहतर विकल्प नहीं दिख रहा है। यह ~ जैसे मनमाने प्रतीक को चुनने से बेहतर लगता है, और मैं शर्त लगाता हूं कि .* (आदि) के आदी कई लोग इसका अर्थ तुरंत अनुमान लगा सकते हैं।

एक बात जो मैं बेहतर तरीके से जानना चाहता हूं, वह यह है कि क्या लोग _replaceing_ मौजूदा वेक्टरकृत परिभाषाओं के साथ .( के साथ ठीक हैं। अगर लोग इसे प्रतिस्थापन करने के लिए पर्याप्त पसंद नहीं करते हैं, तो मैं और अधिक संकोच करूंगा।

एक उपयोगकर्ता के रूप में इस चर्चा में गुप्त रूप से मैं अपने मौजूदा वेक्टरकृत कोड को बदलने के लिए इसका उपयोग करना चाहता हूं।

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

सभी कहने के लिए, नियमित उपयोगकर्ता के रूप में, मैं वास्तव में, वास्तव में आशा करता हूं कि यह विलय हो जाएगा!

मुझे $ fun.(vec) की तुलना में प्रस्तावित fun[vec] सिंटैक्स अधिक पसंद है।
आप [fun vec] के बारे में क्या सोचते हैं? यह एक सूची समझ की तरह है लेकिन एक अंतर्निहित चर के साथ है। यह T[fun vec] . करने की अनुमति दे सकता है

लंबाई> 1 वाले वैक्टर के लिए यह सिंटैक्स जूलिया 0.4 में मुफ़्त है:

julia> [sin rand(1)]
1x2 Array{Any,2}:
 sin  0.0976151

julia> [sin rand(10)]
ERROR: DimensionMismatch("mismatch in dimension 1 (expected 1 got 10)")
 in cat_t at abstractarray.jl:850
 in hcat at abstractarray.jl:875

[fun over vec] जैसा कुछ सिंटैक्स स्तर पर बदला जा सकता है और शायद यह [fun(x) for x in vec] को सरल बनाने के लायक है लेकिन map(fun,vec) से आसान नहीं है।

[fun vec] के समान सिंटैक्स: सिंटैक्स (fun vec) मुफ़्त है और {fun vec} को बहिष्कृत कर दिया गया था।

julia> (fun vec)
ERROR: syntax: missing separator in tuple

julia> {fun vec}

WARNING: deprecated syntax "{a b ...}".
Use "Any[a b ...]" instead.
1x2 Array{Any,2}:
 fun  [0.3231600663395422,0.10208482721149204,0.7964663210635679,0.5064134055014935,0.7606900072242995,0.29583012284224064,0.5501131920491444,0.35466150455688483,0.6117729165962635,0.7138111929010424]

@diegozea , fun[vec] को खारिज कर दिया गया क्योंकि यह T[vec] के साथ विरोध करता है। (fun vec) मूल रूप से स्कीम सिंटैक्स है, जिसमें बहु-तर्क का मामला संभवतः (fun vec1 vec2 ...) है ... यह किसी भी अन्य जूलिया सिंटैक्स के विपरीत है। या आपका इरादा (fun vec1, vec2, ...) था, जो टपल सिंटैक्स के साथ विरोध करता है? न ही यह स्पष्ट है कि fun.(vecs...) से अधिक लाभ क्या होगा।

इसके अलावा, याद रखें कि एक मुख्य लक्ष्य अंततः @vectorized फ़ंक्शंस को बदलने के लिए एक सिंटैक्स है (ताकि हमारे पास "वैक्टर पर काम करने वाले" कार्यों का "धन्य" सबसेट न हो), और इसका मतलब है कि मैटलैब, नम्पी, वगैरह में वेक्टरकृत कार्यों के लिए उपयोग किए जाने वाले लोगों के लिए सिंटैक्स को स्वादिष्ट/सहज/सुविधाजनक होना चाहिए। इसे sin(A .+ cos(B[:,1])) जैसे भावों के लिए भी आसानी से लिखने योग्य होना चाहिए। ये आवश्यकताएं बहुत अधिक "रचनात्मक" प्रस्तावों को खारिज करती हैं।

sin.(A .+ cos.(B[:,1])) आखिर इतना बुरा नहीं लगता। इसके लिए एक अच्छे दस्तावेज की जरूरत होगी। क्या f.(x) को .( के रूप में $#$3 .+ .( के समान प्रलेखित किया जा रहा है?
क्या .+ को +. के पक्ष में बहिष्कृत किया जा सकता है?

# Since 
sin.(A .+ cos.(B[:,1]))
# could be written as
sin.(.+(A, cos.(B[:,1])))
# +.
sin.(+.(A, cos.(B[:,1]))) #  will be more coherent.

@diegozea , #15032 में पहले से ही दस्तावेज़ीकरण शामिल है, लेकिन किसी भी अतिरिक्त सुझाव का स्वागत है।

.+ की वर्तनी .+ बनी रहेगी। सबसे पहले, बिंदु का यह स्थान बहुत अधिक उलझा हुआ है, और यहाँ वर्तनी को बदलने से लाभ प्राप्त करने के लिए पर्याप्त नहीं है। दूसरा, जैसा कि @nalimilan ने बताया, आप .( को "वेक्टराइज्ड फंक्शन-कॉल ऑपरेटर" के रूप में सोच सकते हैं, और इस दृष्टिकोण से सिंटैक्स पहले से ही सुसंगत है।

( broadcast (#4883) में टाइप-गणना के साथ कठिनाइयों को दूर करने के बाद, मेरी आशा एक और पीआर बनाने की है ताकि किसी भी ऑपरेटर के लिए a .⧆ b ⧆ सिर्फ चीनी हो broadcast(⧆, a, b) पर कॉल करने के लिए। इस तरह, हमें अब .+ वगैरह को स्पष्ट रूप से लागू करने की आवश्यकता नहीं होगी - आपको केवल + आदि को परिभाषित करके प्रसारण ऑपरेटर स्वचालित रूप से मिल जाएगा। हम करेंगे अभी भी विशेष ऑपरेटरों के लिए broadcast ओवरलोड करके, विशेष तरीकों को लागू करने में सक्षम हो, उदाहरण के लिए बीएलएएस को कॉल।)

इसे sin(A .+ cos(B[:,1])) जैसे भावों के लिए भी आसानी से लिखने योग्य होना चाहिए।

क्या f1.(x, f2.(y .+ z)) को broadcast((a, b, c)->(f1(a, f2(b + c))), x, y, z) $ के रूप में पार्स करना संभव है?

संपादित करें: मुझे लगता है कि यह पहले से ही ऊपर उल्लिखित है ... डिफ़ॉल्ट रूप से @ जीथब द्वारा छिपी हुई टिप्पणी में ..

@yuyichao , लूप फ्यूजन ऐसा लगता है कि यह संभव होना चाहिए यदि कार्यों को @pure के रूप में चिह्नित किया गया हो (कम से कम यदि eltypes अपरिवर्तनीय हैं), जैसा कि मैंने # 15032 में टिप्पणी की थी, लेकिन यह संकलक के लिए एक कार्य है, नहीं पार्सर। (लेकिन इस तरह वेक्टरकृत वाक्यविन्यास महत्वपूर्ण आंतरिक लूप से अंतिम चक्र को निचोड़ने की तुलना में सुविधा के लिए अधिक है।)

याद रखें कि यहां मुख्य लक्ष्य @vectorized फ़ंक्शन की आवश्यकता को समाप्त करना है; इसके लिए कम से कम सामान्य, लगभग सुविधाजनक और कम से कम तेज़ गति से एक वाक्य रचना की आवश्यकता होती है। इसे स्वचालित लूप फ़्यूज़न की आवश्यकता नहीं है, हालांकि भविष्य की किसी तारीख में लूप फ़्यूज़न की संभावना को खोलने के लिए कंपाइलर के लिए उपयोगकर्ता के broadcast इरादे को उजागर करना अच्छा है।

अगर यह लूप फ्यूजन भी करता है तो क्या इसमें कोई कमी है?

@yuyichao , लूप फ्यूजन एक बहुत कठिन समस्या है, और गैर-शुद्ध कार्यों को अलग रखना भी हमेशा संभव नहीं होता है (उदाहरण के लिए @StefanKarpinski का exp(log(A) .- sum(A,1)) उदाहरण ऊपर देखें)। इसे लागू करने के लिए रुकने का परिणाम शायद _never_ लागू किया जा रहा है, मेरी राय में - हमें यह वृद्धिशील रूप से करना होगा। उपयोगकर्ता के इरादे को उजागर करके प्रारंभ करें। अगर हम भविष्य में और अनुकूलन कर सकते हैं, तो बढ़िया। यदि नहीं, तो हमारे पास अभी भी उपलब्ध मुट्ठी भर "वेक्टराइज्ड" कार्यों के लिए एक सामान्यीकृत प्रतिस्थापन है।

एक और बाधा यह है कि .+ आदि वर्तमान में broadcast ऑपरेशन के रूप में पार्सर के संपर्क में नहीं है; .+ सिर्फ एक और कार्य है। मेरी योजना इसे बदलने की है ( .+ चीनी के लिए broadcast(+, ...) ), जैसा कि ऊपर उल्लेख किया गया है। लेकिन फिर, यदि परिवर्तन वृद्धिशील हैं तो प्रगति करना बहुत आसान है।

मेरा मतलब यह है कि ऐसा करने से लूप फ्यूजन करना वैध है, इसलिए हम पार्सर को स्कीमेटिक्स के हिस्से के रूप में परिवर्तन करने दे सकते हैं। उपरोक्त उदाहरण में, इसे इस प्रकार लिखा जा सकता है। exp.(log.(A) .- sum(A,1)) और broadcast((x, y)->exp(log(x) - y), A, sum(A, 1)) के रूप में पार्स किया जाए।

यह भी ठीक है अगर .+ अभी तक एक ही श्रेणी से संबंधित नहीं है (जैसे किसी गैर बोर्डकास्ट फ़ंक्शन कॉल को तर्क में रखा जाएगा) और यह तब भी ठीक है जब हम इसे (लूप फ़्यूज़न) केवल एक में करेंगे बाद का संस्करण। मैं मुख्य रूप से पूछ रहा हूं कि पार्सर में इस तरह की योजनाबद्धता संभव है (यानी गैर-अस्पष्ट) और यदि लिखित वेक्टरकृत और फ़्यूज़ लूप को इस तरह से अनुमति देकर कोई ड्रॉ बैक है ..

लूप फ्यूजन को साबित करके ऐसा करना वैध है कठिन है

मेरा मतलब है कि कंपाइलर में ऐसा करना कठिन है (शायद असंभव नहीं), खासकर जब से कंपाइलर को broadcast के जटिल कार्यान्वयन को देखने की जरूरत है, जब तक कि हम कंपाइलर में विशेष मामला broadcast नहीं करते हैं, जो कि है शायद एक बुरा विचार है और यदि संभव हो तो हमें इससे बचना चाहिए ...

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

मैं "गैर-फ़्यूज़िंग" पीआर के बाद ऐसा करने के इच्छुक हूं।

पूरी तरह से सहमत हैं, खासकर जब से .+ को वैसे भी संभाला नहीं जाता है।

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

@StefanKarpinski , जब आप f.(args...) या broadcast(f, args...) पर कॉल करते हैं, तो यह तर्कों को _all_ पर सदिश बना देता है। (इस उद्देश्य के लिए, याद रखें कि स्केलर को 0-आयामी सरणियों के रूप में माना जाता है।) @yuyichao के सुझाव में f.(args...) = _fused प्रसारण वाक्यविन्यास_ (जिसे मैं अधिक से अधिक पसंद कर रहा हूं), मुझे लगता है कि फ्यूजन होगा " स्टॉप" किसी भी अभिव्यक्ति पर जो func.(args...) नहीं है (भविष्य में .+ आदि को शामिल करने के लिए)।

इसलिए, उदाहरण के लिए, sin.(x .+ cos.(x .^ sum(x.^2))) ( julia-syntax.scm में) broadcast((x, _s_) -> sin(x + cos(x^_s_)), x, sum(broacast(^, x, 2))) में बदल जाएगा। ध्यान दें कि sum फ़ंक्शन "फ़्यूज़न सीमा" होगा। कॉलर उन मामलों में f.(args...) का उपयोग नहीं करने के लिए जिम्मेदार होगा जहां फ्यूजन साइड इफेक्ट को खराब कर देगा।

क्या आपके मन में कोई उदाहरण है जहां यह पर्याप्त नहीं होगा?

जो मुझे ज्यादा पसंद आ रहा है

मैं खुश हूँ कि आपको यह पसंद है। =)

अभी तक एक और एक्सटेंशन जो शायद एक ही दौर से संबंधित नहीं है, .= , .*= या समान असाइनमेंट समस्या को हल करने के लिए उपयोग करना संभव हो सकता है (इसे अलग बनाकर सामान्य असाइनमेंट)

हां, अन्य कार्यों के लिए फ्यूजन की कमी #7052 में .+= वगैरह के लिए मेरी मुख्य आपत्ति थी, लेकिन मुझे लगता है कि अन्य func.(args...) कॉल के साथ .= फ्यूज होने से इसका समाधान हो जाएगा . या बस x[:] = ... फ्यूज करें।

:अंगूठे: इस चर्चा में दो अवधारणाएं एक साथ जुड़ी हुई हैं जो वास्तव में काफी ऑर्थोगोनल हैं:
matlab'y "फ्यूज्ड ब्रॉडकास्टिंग ऑपरेशंस" या x .* y .+ z और apl'y "उत्पादों और ज़िपों पर मैप्स" जैसे f[product(I,J)...] और f[zip(I,J)...] । एक-दूसरे के साथ बात करने का भी इससे लेना-देना हो सकता है।

@mschauer , f.(I, J) पहले से ही (#15032 में) map(x -> f(x...), zip(I, J) के बराबर है यदि I और J का आकार समान है। और अगर I एक पंक्ति वेक्टर है और J एक कॉलम वेक्टर है या इसके विपरीत, तो broadcast वास्तव में उत्पाद सेट पर मैप करता है (या आप f.(I, J') कर सकते हैं

ऑर्थोगोनल सही शब्द नहीं था, वे सह-अस्तित्व के लिए काफी अलग हैं।

हालाँकि, मुद्दा यह है कि हमें दो मामलों के लिए अलग-अलग सिंटैक्स की आवश्यकता नहीं है। func.(args...) दोनों का समर्थन कर सकता है।

एक बार जब त्रयी का सदस्य (स्टीफन, जेफ, वायरल) #15032 (जो मुझे लगता है कि मर्ज-रेडी है) में विलय हो जाता है, तो मैं इसे बंद कर दूंगा और शेष प्रस्तावित परिवर्तनों को रेखांकित करने के लिए एक रोडमैप समस्या दर्ज करूंगा: प्रसारण प्रकार-गणना को ठीक करें, बहिष्कृत करें @vectorize , .op को ब्रॉडकास्ट शुगर में बदलें, सिंटैक्स-लेवल "ब्रॉडकास्ट-फ़्यूज़न" जोड़ें, और अंत में इन-प्लेस असाइनमेंट के साथ फ़्यूज़ करें। अंतिम दो शायद इसे 0.5 में नहीं बनाएंगे।

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

मुझे लगता है कि इसे अब #16285 के पक्ष में बंद किया जा सकता है।