संदर्भ। # 9930, # 20053, # 23552। श्रेष्ठ!

संदर्भ के लिए धन्यवाद। मुझे लगता है कि इस मुद्दे को एपीआई रिवाम्प की तुलना में gemm -स्टाइल विधियों के साथ जोड़ने के लिए अधिक है, लेकिन इसे बंद किया जा सकता है अगर हमें लगता है कि यह अभी भी # 9930 के समान है।

एक प्रारंभिक बिंदु के रूप में, क्या _generic_matmatmul! gemm API होने का समर्थन होगा? यह काफी सरल परिवर्तन है, और विशुद्ध रूप से additive / nonbreaking है, क्योंकि वर्तमान पद्धति को केवल α=1 और β=0 होने से लागू किया जाएगा। मैं पीआर बना सकता हूं। मैं शायद इस संस्करण के समान ही जाऊंगा (उस संस्करण में मैंने सभी पारगमन सामग्री को काट दिया क्योंकि मुझे इसकी आवश्यकता नहीं थी, मैं यहां ऐसा नहीं करूंगा)।

हाँ। वह एक अच्छी शुरुआत होगी। हमें तर्कों के आदेश पर विचार करने की आवश्यकता है। मूल रूप से, मैंने सोचा कि बीएलएएस आदेश का पालन करना अधिक स्वाभाविक था लेकिन हम पहले आउटपुट तर्कों के बारे में काफी सुसंगत थे जो वर्तमान तीन-तर्क A_mul_B! । इसके अलावा और जैसा कि आप पहले ही बता चुके हैं, तीन-तर्क संस्करण α=1 और β=0 साथ पाँच-तर्क संस्करण के अनुरूप होगा और डिफ़ॉल्ट मान तर्क अंतिम हैं। बेशक, हमें इसके लिए डिफ़ॉल्ट मान सिंटैक्स का उपयोग करने की आवश्यकता नहीं है, लेकिन यह यहाँ उपयोग करने के लिए समझ में आता है।

सिर्फ एक सामान्य gemm फ़ंक्शन का परिचय क्यों नहीं?

हाँ। वह एक अच्छी शुरुआत होगी। हमें तर्कों के आदेश पर विचार करने की आवश्यकता है। मूल रूप से, मुझे लगा कि BLAS आदेश का पालन करना अधिक स्वाभाविक है, लेकिन हम आउटपुट तर्कों के बारे में काफी सुसंगत हैं, जो वर्तमान तीन-तर्क A_mul_B के लिए भी है। इसके अलावा और जैसा कि आप पहले ही बता चुके हैं, तीन-तर्क संस्करण α = 1 और default = 0 के साथ पांच-तर्क संस्करण के अनुरूप होगा और डिफ़ॉल्ट मान तर्क अंतिम हैं। बेशक, हमें इसके लिए डिफ़ॉल्ट मान सिंटैक्स का उपयोग करने की आवश्यकता नहीं है, लेकिन यह यहाँ उपयोग करने के लिए समझ में आता है।

बढ़िया है। हम # 9930 में वास्तविक तर्क क्रम और नाम बदलने के बारे में चर्चा जारी रख सकते हैं। यह केवल पाँच-तर्क संस्करण उपलब्ध होने के बारे में अधिक है, इसलिए मैं वर्तमान Ax_mul_Bx!(α,A,B,β,C) इंटरफ़ेस रखूँगा।

क्यों न केवल एक जेनेरिक जेमम फ़ंक्शन का परिचय दिया जाए?

क्या आप उपरोक्त परिवर्तनों के अलावा _generic_matmatmul! से gemm! का नाम बदलने का सुझाव दे रहे हैं?

स्पष्ट होने के लिए, मुझे लगता है कि हमें एक एकल विधि mul(C,A,B,α=1,β=0) होनी चाहिए, साथ ही साथ प्रेषण करने के लिए आलसी स्थानांतरण / आसन्न प्रकार के साथ, लेकिन वह एक अन्य पीआर होगा।

क्यों न केवल एक जेनेरिक जेमम फ़ंक्शन का परिचय दिया जाए?

मुझे लगता है कि जूलिया में gemm एक मिथ्या नाम है। BLAS में, ge हिस्सा इंगित करता है कि मैट्रिसेस सामान्य हैं , अर्थात कोई विशेष संरचना नहीं है, पहले m गुणा है और सूची m मैट्रिक्स है । जूलिया में, ge (सामान्य) भाग हस्ताक्षर में एन्कोडेड है जैसा कि अंतिम m (मैट्रिक्स) है इसलिए मुझे लगता है कि हमें इसे mul! कहना चाहिए।

SparseArrays.jl से नोटेशन mul!(α, A, B, β, C) है

https://github.com/JuliaLang/julia/blob/160a46704fd1b349b5425f104a4ac8b323ea85af/stdlib/SparseArrays/src/linalg.jl#L32

आधिकारिक वाक्यविन्यास के रूप में "अंतिम रूप"? और यह mul!(C, A, B) , lmul!(A, B) , और rmul!(A,B) ?

मैं अलग-अलग ऑर्डर में A , B , और C होने का बहुत बड़ा प्रशंसक नहीं हूं।

क्या नोटेशन mul!(α, A, B, β, C) SparseArrays.jl से "अंतिम" आधिकारिक वाक्यविन्यास के रूप में है?

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

तो बस स्पष्ट करने के लिए, आप अर्थ में वैकल्पिक तर्क चाहेंगे

function mul!(C, A, B, α=1, β=0)
 ...
end

अन्य विकल्प वैकल्पिक खोजशब्द तर्क होंगे

function mul!(C, A, B; α=1, β=0)
...
end

लेकिन मुझे यकीन नहीं है कि लोग यूनिकोड से बहुत खुश हैं।

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

मेरी राय में, एक अधिक तार्किक नामकरण कई BLAS रूटीनों के लिए muladd!(A, B, C, α=1, β=1) मैप होगा जो गुणा और जोड़ करते हैं । ( gemm ऊपर के रूप में, लेकिन यह भी axpy जब A एक अदिश राशि है।)

mul! फ़ंक्शन तब तक एक इंटरफ़ेस हो सकता है जैसे mul!(Y, A, B, ...) एक मनमाना संख्या में तर्क ले रहा है (जैसे * करता है) जब तक सभी मध्यवर्ती परिणाम वाई में संग्रहीत किए जा सकते हैं ( एक वैकल्पिक kwarg एक उचित डिफ़ॉल्ट के साथ गुणन के क्रम को निर्दिष्ट कर सकता है)

mul!(Y, A::AbstractVecOrMat, B:AbstractVecOrMat, α::Number) डिफ़ॉल्ट कार्यान्वयन muladd!(A, B, Y, α=α, β=0) होगा, जैसा कि दो मैट्रिक्स / वैक्टर और एक अदिश के अन्य क्रमपरिवर्तन होगा।

एक और वोट के लिए घने मैट्रीस के लिए mul!(C, A, B, α, β) परिभाषित किया गया है। यह घने और विरल मैट्रिस के लिए सामान्य कोड लिखने की अनुमति देगा। मैं अपने गैर रैखिक कम से कम वर्गों में इस तरह के एक समारोह को परिभाषित करना चाहता था, लेकिन मुझे लगता है कि यह टाइप पाइरेसी है।

मुझे MixedModels पैकेज के लिए mul!(C, A, B, α, β) विधियाँ लिखने और कुछ प्रकार की पायरेसी में लिप्त होने का भी प्रलोभन दिया गया है, लेकिन यह बेहतर होगा यदि ऐसे तरीके LinearAlgebra पैकेज। इस ऑपरेशन के लिए muladd! जेनेरिक के तरीके होना मेरे साथ भी ठीक होगा।

मैं इसके पक्ष में हूं, हालांकि मुझे लगता है कि इसे शायद mul! तुलना में एक अलग नाम होना चाहिए। muladd! उचित लगता है, लेकिन निश्चित रूप से सुझावों के लिए खुला हूं।

शायद mulinc! गुणा-वृद्धि के लिए?

शायद हमारे पास addmul!(C, A, B, α=1, β=1) जैसा कुछ हो सकता है?

क्या यह muladd! ? या क्या इसे addmul! कहने के पीछे विचार यह है कि यह बहु तर्क के बजाय जोड़ तर्क को बदल देता है? क्या कोई कभी बहु तर्क वितर्क करेगा?

ध्यान दें कि हम कुछ मामलों में गैर-प्रथम तत्वों को म्यूट करते हैं, जैसे lmul! और ldiv! , इसलिए हम उन्हें सामान्य रूप से "muladd" क्रम में कर सकते हैं (अर्थात muladd!(A,B,C) )। सवाल यह है कि α और β जाने का क्या आदेश होना चाहिए? कीवर्ड तर्क बनाने के लिए एक विकल्प होगा?

क्या अच्छा नहीं होगा यदि आप स्केलर्स α और β के प्रकारों पर प्रेषण के लिए कार्यान्वयनकर्ताओं के लिए एक विकल्प छोड़ दें? अंत उपयोगकर्ताओं के लिए शक्कर जोड़ना आसान है।

मैंने सोचा था कि हम पहले से ही α , β लिए डिफ़ॉल्ट मानों के साथ mul!(C, A, B, α, β) पर बस गए। हम इस संस्करण का उपयोग https://github.com/JuliaLang/julia/blob/b8ca1a499ff4044b9cb1ba3881d8c6fb1f3c0bb/stdlib/SparseArrays/src/linalg.jl#L32#5032/L32b पर कर रहे हैं। मुझे लगता है कि कुछ पैकेज भी इस फॉर्म का उपयोग कर रहे हैं, लेकिन मुझे याद नहीं है कि मेरे सिर के ऊपर कौन सा है।

धन्यवाद! यह अच्छा होगा यदि इसे प्रलेखित किया जाए।

मैंने सोचा था कि हम पहले से ही α , β लिए डिफ़ॉल्ट मानों के साथ mul!(C, A, B, α, β) पर बस गए।

SparseArrays इसका उपयोग करता है, लेकिन मुझे याद नहीं है कि यह कहीं भी चर्चा की जा रही है।

कुछ मायनों में muladd! नाम अधिक स्वाभाविक है क्योंकि यह एक गुणा है इसके बाद जोड़ है। हालाँकि, α और β के डिफ़ॉल्ट मान, muladd!(C, A, B, α=1, β=0) (ध्यान दें कि β के लिए डिफ़ॉल्ट शून्य है, एक नहीं), इसे mul!(C, A, B) ।

ऐसा लगता है कि यह mul! या muladd! कॉल करने के लिए वंशानुक्रम बनाम संगतता का मामला है और मुझे लगता है कि SparseArrays में मौजूदा पद्धति का मामला mul! लिए बहस करेगा। मैं खुद को अपने पसंदीदा ऑस्कर वाइल्ड उद्धरण के बावजूद संगति के लिए बहस करने के उत्सुक मामले में पाता हूं, "संगति अकल्पनीय का अंतिम आश्रय है।"

कुछ मायनों में muladd! नाम अधिक स्वाभाविक है क्योंकि यह एक गुणा है इसके बाद जोड़ है। हालाँकि, α और β के डिफ़ॉल्ट मान, muladd!(C, A, B, α=1, β=0) (ध्यान दें कि β के लिए डिफ़ॉल्ट शून्य है, एक नहीं), इसे mul!(C, A, B) ।

इसके लिए एक दिलचस्प अपवाद है जब C में Inf या NaN होते हैं: सैद्धांतिक रूप से, यदि β==0 , परिणाम अभी भी NaN होना चाहिए। व्यवहार में ऐसा नहीं होता है क्योंकि BLAS और हमारे विरल मैट्रिक्स कोड स्पष्ट रूप से β==0 लिए जाँच करते हैं और फिर इसे शून्य से बदलें।

आप इस बात पर विचार कर सकते हैं कि α=true, β=false true और false क्रमशः "मजबूत" 1 और 0 हैं, इस अर्थ में कि true*x हमेशा x और false*x हमेशा zero(x) ।

lmul! भी वह असाधारण व्यवहार होना चाहिए: https://github.com/JuliaLang/julia/issues/28972

true और false क्रमशः "मजबूत" 1 और 0 हैं, इस अर्थ में कि true*x हमेशा x और false*x हमेशा zero(x) ।

मुझे यह नहीं पता था !:

julia> false*NaN
0.0

FWIW, मैं इस ऑपरेशन के लिए LazyArrays.jl सिंटैक्स की पठनीयता से बहुत खुश हूँ:

y .= α .* Mul(A,x) .+ β .* y

दृश्यों के पीछे यह BLAS- संगत सरणियों के लिए mul!(y, A, x, α, β) , (बैंडेड और स्ट्रेटेड)।

मुझे नहीं पता था कि!

यह im = Complex(false, true) काम करने का हिस्सा है।

SparseArrays इसका उपयोग करता है, लेकिन मुझे याद नहीं है कि यह कहीं भी चर्चा की जा रही है।

ऊपर https://github.com/JuliaLang/julia/issues/23919#issuecomment -365463941 में चर्चा की गई और https://github.com/JuliaLang/julia/pull/26117 में बिना किसी आपत्ति के लागू किया गया। घने मामले में हमारे पास α,β संस्करण नहीं हैं, SparseArrays ।

LinearAlgebra.BLAS.gemm! बारे में क्या? क्या इसे 5-एरी mul! रूप में भी लपेटा नहीं जाना चाहिए?

यह होना चाहिए लेकिन किसी ने अभी तक नहीं किया है। matmul.jl में कई विधियाँ हैं।

यह # 23919 (टिप्पणी) में ऊपर चर्चा की गई और बिना किसी आपत्ति के # 26117 में लागू किया गया।

खैर, इसे मेरी आपत्ति मानिए। मैं एक अलग नाम पसंद करूंगा।

यह एक अलग नाम क्यों होगा? घने और विरल मामले में, बुनियादी एल्गोरिथ्म गुणा और जोड़ दोनों करता है।

यदि हम उन कार्यों को अलग-अलग नाम देते हैं, तो हमारे पास mul!(C,A,B) = dgemm(C,A,B,1,0) और muladd!(C,A,B,α, β) = dgemm(C,A,B,α, β) ।

एकमात्र लाभ जो मुझे दिखाई देता है, अगर हम वास्तव में विधियों को विभाजित करते हैं और C = A*B केस में if β==0 कॉल बचाते हैं।

FYI करें, मैंने # 29634 में matmul.jl इंटरफ़ेस जोड़ने के लिए इस पर काम करना शुरू किया। मैं नाम और हस्ताक्षर तय होने तक इसे खत्म करने की उम्मीद कर रहा हूं :)

muladd! का एक फायदा यह होगा कि हम टर्नरी muladd!(A, B, C) (या muladd!(C, A, B) ?) डिफ़ॉल्ट α = β = true (मूल सुझाव में उल्लिखित के रूप में कर सकते हैं) //github.com/JuliaLang/julia/issues/23919#issuecomment-402953987)। विधि muladd!(A, B, C) muladd Number s के समान है, इसलिए मुझे लगता है कि यह अधिक प्राकृतिक नाम है खासकर यदि आप पहले से ही muladd जानते हैं।

@andreasnoack ऐसा लगता है कि आपकी पूर्व चर्चा विधि हस्ताक्षर के बारे में है और कीवर्ड के तर्क पर muladd! नाम के लिए आपत्ति है? (5-एरी mul! SparseArrays का अस्तित्व एक हो सकता है, लेकिन पिछड़े-संगत आवरण को परिभाषित करना कठिन नहीं है।)

दोनों mul! और muladd! तब बेमानी लगते हैं जब पूर्व सिर्फ α और β लिए डिफ़ॉल्ट मानों के साथ होता है। इसके अलावा, add भाग को BLAS द्वारा विहित किया गया है। अगर हम muladd! लिए एक विश्वसनीय जेनेरिक रैखिक बीजगणित आवेदन के साथ आ सकते हैं, तो मैं इसके बारे में सुनना चाहूंगा, लेकिन अन्यथा मैं अतिरेक से बचना पसंद करूंगा।

इसके अलावा, मैं दृढ़ता से पसंद करते हैं कि हम की मजबूत शून्य संपत्ति रखने के false की चर्चा से अलग mul! । IMO IM का कोई भी शून्य मान मजबूत होना चाहिए क्योंकि यह BLAS में है और जैसा कि वर्तमान पांच तर्क mul! विधियों में है। यानी यह व्यवहार mul! का परिणाम होना चाहिए न कि β । विकल्प के साथ काम करने के लिए अलग होगा। जैसे mul!(Matrix{Float64}, Matrix{Float64}, Matrix{Float64}, 1.0, 0.0) ~ ~ BLAS का उपयोग नहीं कर सकते थे।

हम यह नहीं बदल सकते हैं कि BLAS क्या करता है, लेकिन _requiring_ मजबूत शून्य व्यवहार का मतलब यह है कि प्रत्येक कार्यान्वयन को शून्य की जांच करने के लिए एक शाखा की आवश्यकता होगी।

अगर हम muladd! लिए एक विश्वसनीय जेनेरिक रैखिक बीजगणित एप्लिकेशन के साथ आ सकते हैं

@andreasnoack इसके द्वारा, मुझे लगता है कि आप का मतलब है "_three-argument_ muladd! " के लिए आवेदन क्योंकि आप पांच-तर्क mul! शामिल करने के लिए सहमत नहीं होंगे?

लेकिन मैं अभी भी एक उदाहरण के साथ आ सकता हूं जहां muladd!(A, B, C) उपयोगी है। उदाहरण के लिए, यदि आप "छोटे-विश्व" नेटवर्क का निर्माण करना चाहते हैं, तो बैंडेड मैट्रिक्स और स्पार्स मैट्रिक्स का "आलसी" योग होना उपयोगी है। फिर आप कुछ इस तरह लिख सकते हैं:

A :: SparseMatrixCSC
B :: BandedMatrix
x :: Vector  # input
y :: Vector  # output

# Compute `y .= (A .+ B) * x` efficiently:
fill!(y, 0)
muladd!(x, A, y)  # y .+= A * x
muladd!(x, B, y)  # y .+= B * x

लेकिन मुझे कोई आपत्ति नहीं है कि मैं मैन्युअल रूप से true s लिख रहा हूं क्योंकि मैं इसे केवल अपने उपयोग के लिए लपेट सकता हूं। एक स्थिर दस्तावेज एपीआई के रूप में पांच-तर्क कार्य करना यहां सबसे महत्वपूर्ण लक्ष्य है।

इस बिंदु पर वापस जा रहे हैं:

दोनों mul! और muladd! बेमानी लगते हैं, जब पूर्व केवल α और β लिए डिफ़ॉल्ट मानों के साथ उत्तरार्द्ध है।

लेकिन हमारे पास कुछ * mul! संदर्भ में कार्यान्वित किया गया है जो कि आउटपुट सरणी के "डिफ़ॉल्ट मान" के साथ उचित रूप से शुरू किया गया है। मुझे लगता है कि Base और मानक पुस्तकालयों में ऐसे "शॉर्टकट" उदाहरण हो सकते हैं? मुझे लगता है कि यह समझ में आता है दोनों mul! और muladd! भले ही mul! muladd! का एक शॉर्टकट हो।

मैं दृढ़ता से पसंद करते हैं कि हम मजबूत शून्य की संपत्ति रखने के false की चर्चा से अलग mul!

मैं मानता हूँ कि यह बहु-प्रथम के पाँच-तर्क संस्करण के नाम पर चर्चा करने के लिए रचनात्मक होगा (पहले mul! बनाम muladd! )।

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

आपका उदाहरण केवल लिखा जा सकता है

mul!(y, A, x, 1, 1)
mul!(y, B, x, 1, 1)

इसलिए मुझे अभी भी muladd! की आवश्यकता नहीं दिख रही है। क्या यह सिर्फ इतना है कि आपको लगता है कि यह मामला इतना सामान्य है कि 1, 1 लिखना बहुत क्रियात्मक है?

लेकिन हमारे पास $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ * mul! +3 +3 के साथ अप्वाइंट किए गए आउटपुट एरे के "डिफॉल्ट वैल्यू" के साथ भी लागू कर देता है। मुझे लगता है कि Base और मानक पुस्तकालयों में ऐसे "शॉर्टकट" उदाहरण हो सकते हैं?

मुझे यह नहीं मिलता है। क्या आप विस्तृत करने की कोशिश कर सकते हैं? आप यहाँ किस शॉर्टकट की बात कर रहे हैं?

इसलिए मुझे अभी भी muladd! । क्या यह सिर्फ इतना है कि आपको लगता है कि यह मामला इतना सामान्य है कि 1, 1 लिखना बहुत क्रियात्मक है?

मुझे लगता है कि muladd! भी अधिक वर्णनात्मक है जैसा कि यह वास्तव में करता है (हालांकि शायद यह addmul! होना चाहिए)।

मुझे muladd! नाम से कोई समस्या नहीं है। जाहिर है, मैं तो बस नहीं लगता कि हम इस के लिए कार्य करने के लिए होना चाहिए और दूसरी प्राथमिकता मुझे नहीं लगता कि बहिष्कार करते mul! के पक्ष में muladd! / addmul! इसके लायक है।

क्या यह सिर्फ इतना है कि आपको लगता है कि यह मामला इतना सामान्य है कि 1, 1 लिखना बहुत अधिक है?

नहीं, जब तक यह एक सार्वजनिक एपीआई है, तब तक मैं पांच तर्क फ़ंक्शन को कॉल करने के साथ पूरी तरह से ठीक हूं। मैंने सिर्फ एक उदाहरण देने की कोशिश की, जहां मुझे केवल तीन तर्क संस्करण की आवश्यकता है (जैसा कि मैंने सोचा था कि आपका अनुरोध था)।

आप यहाँ किस शॉर्टकट की बात कर रहे हैं?

https://github.com/JuliaLang/julia/blob/f068f21d6099632bd5543ad065d5de96943c9181/stdlib/LinearAngebra/src/matmul.jl#L140 -L1433

मुझे लगता है कि यहां परिभाषित * को mul! का शॉर्टकट माना जा सकता है। यह डिफ़ॉल्ट मान के साथ " mul! " mul! को muladd! / addmul! डिफ़ॉल्ट मानों के साथ क्यों न होने दें?

rmul! और lmul! समान "शॉर्टकट" के रूप में परिभाषित किए गए हैं:

https://github.com/JuliaLang/julia/blob/f068f21d6099632bd5543ad065d5de96943c9181/stdlib/LinearAngebra/src/triangular.jl#L478 -L479 -L479

mul! घट रहा है

मुझे लगा कि चर्चा एक नया इंटरफ़ेस जोड़ने के बारे में है या नहीं। अगर हमें एक नया API जोड़ने के लिए mul! है, तो मुझे नहीं लगता कि यह इसके लायक है।

मुख्य तर्क मैं सोच सकता हूं:

• वैचारिक रूप से 5-तर्क रूप केवल "गुणा" से अधिक करता है, और इसे अधिक स्पष्ट रूप से बताता है।
• फिर आप mul!(C,A,B,1,1) या mul!(C,A,B,true,true) बजाय addmul!(C, A, B) लिख सकते हैं।

मुझे लगता है कि यहां परिभाषित * को mul! का शॉर्टकट माना जा सकता है। यह डिफ़ॉल्ट मान के साथ " mul! " muladd! / addmul! हो?

क्योंकि * मैट्रिस को गुणा करने का डिफ़ॉल्ट तरीका है और अधिकांश उपयोगकर्ता इसे कैसे करेंगे। तुलना में, muladd! उपयोग में कहीं भी * करीब नहीं होंगे। इसके अलावा, यह एक मौजूदा ऑपरेटर भी है जबकि muladd! / addmul! एक नया फ़ंक्शन होगा।

ऐसा मत सोचो कि rmul! और lmul! इस पैटर्न में फिट होते हैं क्योंकि वे आम तौर पर mul! तरीकों के डिफ़ॉल्ट मूल्य संस्करण नहीं हैं।

साइमन ऊपर दिए गए पोस्ट में अच्छी तरह से लाभ का सारांश देता है। सवाल यह है कि क्या लाभ बड़े हैं या तो नाम बदलने के एक अतिरिक्त कार्य को सही ठहराने के लिए (जिसका अर्थ है mul! )। यह वह जगह है जहाँ हम असहमत हैं। मुझे नहीं लगता कि यह इसके लायक है।

जब आप कहते हैं कि नाम बदलने लायक नहीं है, तो क्या आपने इसे ध्यान में रखा है कि एपीआई पूरी तरह से सार्वजनिक नहीं है? इसके द्वारा, मेरा मतलब है कि यह जूलिया के दस्तावेज में नहीं है।

मुझे पता है कि LazyArrays.jl (और अन्य पैकेज?) पहले से ही इसका उपयोग करता है इसलिए आँख बंद करके सेमेस्टर अच्छा नहीं होगा। लेकिन फिर भी, यह अन्य कार्यों की तरह सार्वजनिक नहीं है।

mul! LinearAlgebra से निर्यात किया जाता है और मोटे तौर पर उपयोग किया जाता है इसलिए हमें निश्चित रूप से इस बिंदु पर इसे हटाना होगा। यह शर्म की बात है जब हमने A_mul_B! mul! या कम से कम 0.7 से पहले यह चर्चा नहीं की क्योंकि यह फ़ंक्शन का नाम बदलने के लिए बहुत बेहतर समय होता।

कैसे के बारे में का उपयोग कर mul! के लिए अब के लिए और नाम को बदल LinearAlgebra v2.0 जब हम stdlibs अलग से अद्यतन कर सकते हैं?

LazyArrays.jl mul! उपयोग नहीं करता है क्योंकि यह कई प्रकार के मेट्रिसेस के लिए लचीला नहीं है (और जब आप StridedArray s के साथ ओवरराइड करते हैं तो कंपाइलर स्लोनेस बग को ट्रिगर करता है)। यह फॉर्म का एक वैकल्पिक निर्माण देता है

y .= Mul(A, x)

जो मुझे लगता है कि अधिक वर्णनात्मक है। 5 तर्क एनालॉग है

y .= a .* Mul(A, x) .+ b .* y

मैं mul! निकालने और LinearArgeays.jl में LinearAlgebra.jl के लिए आगे बढ़ने के पक्ष में तर्क दूंगा, लेकिन इसे बनाने के लिए एक कठिन मामला होने जा रहा है।

LowRankApprox.jl mul! उपयोग करता है, लेकिन मैं इसे बदलकर LazyArrays.jl दृष्टिकोण का उपयोग कर सकता हूं और इस तरह संकलक बग से बच सकता हूं।

ठीक। मुझे लगा कि केवल दो प्रस्ताव हैं। लेकिन जाहिर है कि मोटे तौर पर तीन प्रस्ताव हैं ?:

1. तीन- और पांच-तर्क mul!
2. तीन- और पांच-तर्क muladd!
3. तीन-तर्क mul! और पाँच-तर्क muladd!

( muladd! addmul! कहा जा सकता है)

मैं सोच रहा था कि हम 1 और 3 की तुलना कर रहे हैं। मेरी समझ अब यह है कि @andreasnoack 1 और 2 की तुलना कर रहा है।

मैं कहूंगा कि 2 एक विकल्प नहीं है क्योंकि तीन-तर्क mul! एक सार्वजनिक एपीआई है और व्यापक रूप से उपयोग किया जाता है। "एपीआई पूरी तरह से सार्वजनिक नहीं है" से मेरा मतलब था कि पांच-तर्क mul! का दस्तावेजीकरण नहीं किया गया है ।

हां, मेरी योजना mul! (एक 3 arg और संभवतः 4 arg फॉर्म के रूप में) रखने की थी। मुझे लगता है कि यह 3 arg mul! और addmul! का अलग व्यवहार होगा, अर्थात addmul!(C, A, B, α, β) , हमारे पास होगा:

mul!(C, A, B) = addmul!(C, A, B, 1, 0)
mul!(C, A, B, α) = addmul!(C, A, B, α, 0)
addmul!(C, A, B) = addmul!(C, A, B, 1, 1)
addmul!(C, A, B, α) = addmul!(C, A, B, α, 1)

हालाँकि आप वास्तव में उन्हें इस तरह से व्यवहार में लागू नहीं करना चाह सकते हैं, उदाहरण के लिए, यह केवल 4-arg mul! और addmul! अलग-अलग हो सकता है, और 5-arg addmul! परिभाषित हो सकता है

addmul!(C, A, B, α, β) = addmul!(C .= β .* C, A, B, α)

टक्कर!

हालाँकि आप वास्तव में उन्हें व्यवहार में इस तरह से लागू नहीं करना चाह सकते हैं, जैसे कि यह केवल 4-arg mul के लिए सरल हो सकता है! और addmul! अलग से, और 5-arg addmul को परिभाषित करें! जैसा:
addmul!(C, A, B, α, β) = addmul!(C .= β .* C, A, B, α)

इसे अभी से ही क्यों न कर लें? इसे ऐसा न करने की बात यह है कि आपको केवल C एक बार तत्वों का दौरा करने की आवश्यकता है, जो निश्चित रूप से बड़े मैट्रिस के लिए अधिक कुशल है। इसके अलावा, मैं शायद ही विश्वास कर सकता हूं कि कोड केवल 5-arg addmul! बनाम दोनों 4-arg mul! और addmul! अलग से परिभाषित करके होगा।

FYI करें मैंने LearArrays में 5-दलील लेने के लिए LinearAlgebra के _generic_matmatmul! के कार्यान्वयन को संशोधित किया है: https://github.com/JuliaArrays/LazyArrays.jl-blob/8a50250fc6cf340275808822777cf2c2=2

यहाँ यह कहा जाता है:

materialize!(MulAdd(α, A, b, β, c)) 

लेकिन वास्तविक कोड ( tiled_blasmul! ) LinearAlgebra में वापस अनुवाद करना आसान होगा।

इस प्रक्रिया को तेज करने के लिए क्या किया जा सकता है? जिन चीजों पर मैं काम कर रहा हूं, वे एक एकीकृत मैट्रिक्स गुणन एपीआई से इन-प्लेस मॉल + ऐड के साथ वास्तव में लाभान्वित होंगे

Strered.jl का नवीनतम संस्करण अब 5 तर्क mul!(C,A,B,α,β) का समर्थन करता है, जब संभव हो तो BLAS को

@ जूथो बढ़िया पैकेज! आगे के लिए क्या कोई रोडमैप है? क्या योजना को अंततः LinAAlgebra के साथ विलय किया जा सकता है?

यह मेरा उद्देश्य कभी नहीं था लेकिन अगर मैं किसी बिंदु पर अनुरोध करता हूं तो मैं इसका विरोध नहीं करता। हालाँकि, मुझे लगता है कि सामान्य mapreduce कार्यक्षमता में @generated फ़ंक्शंस (हालांकि अभी एक है) का मेरा उदार उपयोग आधार के लिए अच्छी तरह से अनुकूल नहीं हो सकता है।

मेरा व्यक्तिगत रोडमैप: यह उच्च-स्तर के पैकेज, अर्थात टेनसोरपरेशंस के नए संस्करण, और कुछ अन्य पैकेजों पर काम कर रहा है, जो कि मैं काम कर रहा हूं। हालांकि, बुनियादी रेखीय बीजगणित के लिए कुछ और समर्थन अच्छा होगा (जैसे norm को StridedView लागू करना वर्तमान में norm जूलिया बेस में धीमी गति से कार्यान्वयन के लिए वापस आता है)। और अगर मेरे पास समय है और जीपीयू के साथ काम करना सीखो, तो समान रूप से सामान्य mapreducekernel GPUArray s को लागू करने का प्रयास करें।

मुझे लगता है कि अब तक की आम सहमति है:

1. हमें mul!(C, A, B) रखना चाहिए
2. हमें inplace के लिए _some_ 5-तर्क फ़ंक्शन की आवश्यकता है, C = αAB + βC

मैं पहले सुझाव देता हूं कि 5-तर्क फ़ंक्शन का नाम क्या होना चाहिए और अतिरिक्त API पर बाद में चर्चा करना चाहिए (जैसे 3- और 4-तर्क addmul! )। लेकिन यह "फीचर" है जो हमें _not_ से मिलता है mul! का उपयोग करते हुए ताकि मिश्रण न करना कठिन हो।

@andreasnoack क्या आपकी चिंता के बारे में चिंता / नाम बदलने का समाधान @simonbyrne की टिप्पणी से ऊपर है https://github.com/JuliaLang/julia/issues/23919#issuecomment -431046516? मुझे लगता है कि पदावनति की कोई आवश्यकता नहीं है।

FYI करें, मैंने अभी # 29634 कार्यान्वयन समाप्त किया है। यदि कोई LinearAlgebra परिचित है तो मैं इसकी समीक्षा कर सकता हूं।

मुझे लगता है कि mul! सब कुछ नाम देना सरल और बेहतर है। यह डिप्रैशन से भी बचता है। अगर हम वास्तव में एक अलग नाम चाहते हैं, तो muladd बेहतर है।

mul! API पर चर्चा करते समय शायद कुछ और बातें ध्यान में रखें:

जब scale! चले गए और 0.6 -> 0.7 संक्रमण में अवशोषित हो गए, तो मुझे थोड़ा दुख हुआ, क्योंकि स्केलर गुणा (वेक्टर रिक्त स्थान की एक संपत्ति) बहुत अलग थी, फिर वस्तुओं को गुणा करना (बीजगणित की संपत्ति) )। फिर भी, मैंने पूरी तरह से mul! दृष्टिकोण को गले लगा लिया है, और बहुत अधिक rmul!(vector,scalar) और lmul!(scalar,vector) की क्षमता की सराहना करते हैं जब स्केलर गुणन सराहनीय नहीं होता है। लेकिन अब मैं हर रोज संयुक्त राष्ट्र के जूलियन नाम से दो और परेशान हूं जैसे कि वेक्टर अंतरिक्ष संचालन: axpy! और इसका सामान्यीकरण axpby! । क्या इन्हें भी mul! / muladd! / addmul! में अवशोषित किया जा सकता है। यद्यपि यह थोड़ा अजीब है, अगर A*B में दो कारकों में से एक पहले से ही एक स्केलर है, तो अतिरिक्त स्केलर कारक α की कोई आवश्यकता नहीं है।
लेकिन हो सकता है कि तब, सादृश्य में

mul!(C, A, B, α, β)

वहाँ भी एक हो सकता है

add!(Y, X, α, β)

axpby! को बदलने के लिए।

@andreasnoack क्या आपकी चिंता # 23919 (टिप्पणी) के ऊपर @simonbyrne की टिप्पणी द्वारा हल / नामकरण के बारे में है? मुझे लगता है कि पदावनति की कोई आवश्यकता नहीं है।

Https://github.com/JuliaLang/julia/issues/23919#issuecomment -430952179 का अंतिम पैराग्राफ देखें। मुझे अभी भी लगता है कि एक नया समारोह शुरू करना इसके लायक नहीं है। यदि हम इसे वैसे भी करते हैं, तो मुझे लगता है कि हमें वर्तमान 5-तर्क mul! घटाना चाहिए।

@ जूथो मुझे लगता है कि acp(b)y! से add! का नाम लेना एक अच्छा विचार होगा।

# 23919 (टिप्पणी) के अंतिम पैराग्राफ को देखें। मुझे अभी भी लगता है कि एक नया समारोह शुरू करना इसके लायक नहीं है।

हां, मैंने इसे पढ़ा है और उत्तर दिया है कि पांच-तर्क mul! का दस्तावेजीकरण नहीं किया गया था और यह सार्वजनिक एपीआई का हिस्सा नहीं था। तो, _technically_ को पदावनति की कोई आवश्यकता नहीं है। Https://github.com/JuliaLang/julia/issues/23919#issuecomment -430975159 का अंतिम पैराग्राफ देखें (निश्चित रूप से, यह वैसे भी एक डिप्रेसेशन होगा, इसलिए इसे पहले ही # 29634 में लागू किया जा सकता है।)

यहाँ, मैं यह मान रहा हूँ कि एक हस्ताक्षर के प्रलेखन के कारण सार्वजनिक एपीआई की घोषणा (जैसे, mul!(C, A, B) ) अन्य हस्ताक्षर (जैसे, mul!(C, A, B, α, β) ) पर लागू नहीं होती है। यदि यह _not_ मामला है, तो मुझे लगता है कि जूलिया और इसकी स्टडीलिब बहुत अधिक इंटर्नल को उजागर कर रही हैं। उदाहरण के लिए, यहाँ Pkg.add का प्रलेखित हस्ताक्षर है

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/Prc/Pkg.jl#L76 -L79

जबकि वास्तविक परिभाषा है

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/APrc/API.jl#L69 -L70

https://github.com/JuliaLang/julia/blob/0d713926f85dfa3e4e0962215b909b8e47e94f48/stdlib/Pkg/APrc/API.jl#L27 -L33

यदि Pkg.add कम से कम एक हस्ताक्षर के अस्तित्व का अर्थ है कि अन्य हस्ताक्षर सार्वजनिक API हैं, तो Pkg.jl प्रमुख संस्करण के बिना कार्यान्वयन विवरण के कारण व्यवहार को दूर नहीं कर सकता, उदाहरण के लिए: Pkg.add(...; mode = :develop) रन Pkg.develop(...) ; Context! लिए सभी कीवर्ड तर्क समर्थित हैं (जो वास्तव में इरादा हो सकते हैं)।

लेकिन यह सिर्फ मेरी छाप है। क्या आप mul!(C, A, B, α, β) को mul!(C, A, B) रूप में सार्वजनिक मानते हैं?

मुझे लगता है कि हम एक-दूसरे से बात कर रहे हैं। मैं जो कह रहा हूं वह यह है कि मैं (अभी भी) यह नहीं सोचता कि यह एक और कार्य है। इसलिए मेरी पिछली टिप्पणी का संदर्भ। यह पाँच-तर्क mul! के अपव्यय की चर्चा से अलग है।

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

यह पाँच-तर्क mul! के अपव्यय की चर्चा से अलग है।

अपनी टिप्पणी के अंतिम पैरा मेरी व्याख्या https://github.com/JuliaLang/julia/issues/23919#issuecomment -+४३,०९,५२,१७९ है कि आप स्वीकार लाभ सूचीबद्ध @simonbyrne था https://github.com/JuliaLang/julia/issues / 23919 # एक नया पांच-तर्क समारोह के लिए -430809383 # _public API_ (जैसा कि आपने "नामकरण" और "पदयात्रा" का उल्लेख किया है) रखने की तुलना में वे कम मूल्यवान थे। इसलिए मैंने विचार किया कि क्या पांच-तर्क mul! सार्वजनिक हुआ है या महत्वपूर्ण नहीं है।

लेकिन आपने "अतिरिक्त कार्य" करने के औचित्य का भी उल्लेख किया है, जो मुझे लगता है कि आप अभी उल्लेख कर रहे हैं। क्या आप यह तर्क दे रहे हैं कि गणना _C = AB_ और _C = αAB + _C_ समान हैं ताकि एक ही नाम दोनों का वर्णन कर सके? मैं वास्तव में असहमत हूं क्योंकि तीन-तर्क mul! को सामान्य करने के अन्य तरीके हो सकते हैं: उदाहरण के लिए, क्यों mul!(y, A₁, A₂, ..., Aₙ, x) _y = A₁ A₂ ₂ Aₙ Aₙ x_ https://github.com/JuniaLang/julia / मुद्दे / २३ ९ १

क्यों नहीं इसे तोड़ने के बजाय इसे हटा देना चाहिए?

जैसा कि मैंने पिछली टिप्पणियों में कहा था, मैं पाँच-तर्क mul! सहमत करने के लिए सहमत हूँ _if_ हमें एक और फ़ंक्शन शुरू करना था। यह कोड मेरे PR # 29634 में पहले से मौजूद है।

क्या आप तर्क दे रहे हैं कि संगणना C = AB और C = αAB + βC समान हैं ताकि एक ही नाम दोनों का वर्णन कर सके?

हां, चूंकि पूर्व केवल β=0 साथ उत्तरार्द्ध है। यह निष्पक्ष बहस करने कि muladd! / addmul! के लिए एक और अधिक सटीक नाम है C = αAB + βC लेकिन हो रही वहाँ या तो एक और आव्यूह गुणन समारोह (शुरू करने की आवश्यकता होती है जाएगा muladd! / addmul! ) या mul! और मुझे नहीं लगता कि अब यह इसके लायक है। यदि यह वसंत में आया होता तो बदलाव पर विचार करना आसान होता।

मैं वास्तव में असहमत हूं क्योंकि तीन-तर्क वाले मुल को सामान्य बनाने के अन्य तरीके हो सकते हैं! "

जूलिया α और β तर्कों के बिना इन-प्लेस मैट्रिक्स गुणा विधियों को परिभाषित करने के लिए हुआ, लेकिन मैट्रिक्स गुणा परंपरा वास्तव में BLAS-3 पर आधारित है और वहाँ सामान्य मैट्रिक्स गुणन फ़ंक्शन C = αAB + βC ।

mul! नामकरण

क्या आप इसका मतलब stdlib में या डाउनस्ट्रीम उपयोगकर्ता मॉड्यूल / कोड में बदल रहे हैं? यदि आप पूर्व का मतलब है, यह पहले से ही किया है (LinearAlgebra और SparseArrays के लिए) # 29634 में तो मुझे नहीं लगता कि आपको इसके बारे में चिंता करने की आवश्यकता है। यदि आपका मतलब बाद में है, तो मुझे लगता है कि यह सार्वजनिक रूप से चर्चा के लिए फिर से उबलता है।

मैट्रिक्स गुणा परंपरा वास्तव में BLAS-3 पर आधारित है

लेकिन जूलिया पहले ही BLAS के नामकरण सम्मेलन से विदा हो गई। इसलिए अधिक वर्णनात्मक नाम रखना अच्छा नहीं होगा?

क्या आप इसका मतलब stdlib में या डाउनस्ट्रीम उपयोगकर्ता मॉड्यूल / कोड में बदल रहे हैं?

29634 mul! फ़ंक्शन का नाम नहीं बदलता है। यह नया फ़ंक्शन addmul! जोड़ता है।

लेकिन जूलिया पहले ही BLAS के नामकरण सम्मेलन से विदा हो गई।

मैं नामकरण की बात नहीं कर रहा हूं। कम से कम बिल्कुल नहीं, क्योंकि फोरट्रान 77 की कुछ सीमाएं हैं जो हमारे पास फ़ंक्शन नाम और प्रेषण दोनों के संदर्भ में नहीं हैं। मैं बात कर रहा हूं कि क्या गणना की जा रही है। BLAS-3 में सामान्य मैट्रिक्स गुणन फ़ंक्शन C = αAB + βC गणना करता है और जूलिया में, यह mul! (fka A_mul_B! ) हो गया है।

इसलिए अधिक वर्णनात्मक नाम रखना अच्छा नहीं होगा?

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

29634 mul! फ़ंक्शन का नाम नहीं बदलता है। यह नया फ़ंक्शन addmul! जोड़ता है।

मेरे कहने का मतलब यह था कि पांच-तर्क mul! का नाम बदलकर addmul! कर दिया गया था।

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

मुझे लगता है कि वे मूल रूप से एक ही हैं या नहीं कुछ व्यक्तिपरक है। मुझे लगता है कि दोनों _C = αAB + bothC_ और _Y = A₂ A⋯ ⋯ Aₙ X_ _C = AB_ के गणितीय रूप से मान्य सामान्यीकरण हैं। जब तक _C = αAB + _C_ अद्वितीय सामान्यीकरण नहीं है, मुझे नहीं लगता कि तर्क पर्याप्त मजबूत है। यह इस बात पर भी निर्भर करता है कि क्या आप BLAS API जानते हैं और मुझे यकीन नहीं है कि यह विशिष्ट जूलिया उपयोगकर्ताओं के लिए मूल ज्ञान है।

इसके अलावा, _C = AB_ और _C = αAB + areC_ कम्प्यूटेशनल रूप से बहुत भिन्न हैं कि C की सामग्री का उपयोग किया जाता है या नहीं। यह पूर्व के लिए केवल आउटपुट और बाद के लिए इनपुट-आउटपुट पैरामीटर है। मुझे लगता है कि यह अंतर एक दृश्य क्यू के योग्य है। यदि मुझे mul!(some_func(...), ...) और mul! का पांच-तर्क रूप दिखाई देता है, तो मुझे तर्कों की संख्या को गिनना होगा (जो कि कठिन है जब वे फ़ंक्शन कॉल के परिणाम हैं क्योंकि आपको कोष्ठक से मेल खाना है) यह देखने के लिए कि क्या some_func कुछ गणना करता है या सिर्फ एक आवंटन। यदि हमारे पास addmul! तो मैं तुरंत उम्मीद कर सकता हूं कि some_func mul!(some_func(...), ...) केवल आवंटन करता है।

मुझे लगता है कि वे मूल रूप से एक ही हैं या नहीं कुछ व्यक्तिपरक है। मुझे लगता है कि C = αAB + bothC और Y = A₂ A⋯ ₙ A C X दोनों गणितीय रूप से C = AB के सामान्यीकरण हैं। जब तक C = αAB + isC अद्वितीय सामान्यीकरण नहीं है, मुझे नहीं लगता कि तर्क पर्याप्त मजबूत है।

यह अद्वितीय सामान्यीकरण नहीं हो सकता है, हालांकि यह एक सामान्यीकरण है जिसे लगभग समान लागत पर गणना की जा सकती है, और यह अन्य रैखिक बीजगणित एल्गोरिदम के निर्माण के लिए एक उपयोगी आदिम बनाता है। कई मौकों पर मैंने विभिन्न रैखिक बीजगणित संबंधी एल्गोरिदम को लागू करते समय एक गैर-शून्य बीटा रखना चाहा है, और हमेशा BLAS.gemm! वापस गिरना पड़ा। अन्य सामान्यीकरण जैसे आपके द्वारा उल्लेख किया गया है, वैसे भी मध्यवर्ती अस्थायी के बिना एक शॉट में गणना नहीं की जा सकती है, इसलिए इन-प्लेस संस्करण बहुत कम उपयोगी है। इसके अलावा, वे एक आदिम ऑपरेशन के रूप में आम तौर पर उपयोगी नहीं हैं।

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

जब तक डिफ़ॉल्ट तर्क α=1 और β=0 अभी भी हैं, तीन arg mul! कोई भी जूलिया उपयोगकर्ता BLAS पृष्ठभूमि के बिना यथोचित अपेक्षा करेगा। अधिक उन्नत विकल्पों के लिए, किसी को मैनुअल से परामर्श करना होगा, क्योंकि किसी भी भाषा और किसी भी फ़ंक्शन के साथ करना होगा। इसके अलावा, यह एकल mul! कॉल न केवल gemm सुपरसाइड करता है, बल्कि gemv और trmv (जो कि विचित्र रूप से पर्याप्त α BLAS API में β पैरामीटर) और शायद कई अन्य।

मैं मानता हूं कि BLAS-3 गणना के संदर्भ में सही सामान्यीकरण है और यह बहुत अच्छी तरह से रचना करता है। मैं एक और संभावित सामान्यीकरण ला रहा हूं क्योंकि मुझे लगता है कि यह समान नाम का उपयोग करने के औचित्य के लिए "अद्वितीय पर्याप्त" नहीं है। Https://github.com/JuliaLang/julia/issues/23919#issuecomment -441267056 के अंतिम पैराग्राफ में आउटपुट-केवल बनाम इनपुट-आउटपुट तर्क भी देखें। मुझे लगता है कि अलग-अलग नाम रीडिंग / रिव्यू कोड को आसान बनाते हैं।

इसके अलावा, यह एकल mul! कॉल न केवल gemm सुपरसीड करता है, बल्कि gemv और trmv (जो कि विचित्र रूप से पर्याप्त α BLAS API में β पैरामीटर) और शायद कई अन्य।

हां, पहले से ही # 29634 में लागू किया गया है और यह नाम तय होने के बाद तैयार हो जाएगा (और समीक्षा की जाएगी)!

मुझे इस वार्तालाप के बाद एक कठिन समय मिल रहा है (यह थोड़ा लंबा और विचित्र है ... क्षमा करें!), प्रमुख प्रस्ताव mul!(C, A, B; α=true, β=false) जैसा कुछ है?

मुझे नहीं लगता कि α और β के लिए कीवर्ड तर्क टेबल पर है। उदाहरण के लिए, @andreasnoack ने https://github.com/JuliaLang/julia/issues/23919#issuecomment -365762889 में कीवर्ड तर्कों को खारिज कर दिया। @simonbyrne ने https://github.com/JuliaLang/julia/issues/23919#issuecomment -426881998 में कीवर्ड दलीलों का उल्लेख किया है, लेकिन उनका नवीनतम सुझाव https://github.com/Juliaang/julia/issues/23919#issuecomment -431046516 स्थित है। तर्क।

हमने अभी तक नाम तय नहीं किया है (यानी, mul! vs addmul! muladd! ) और मुझे लगता है कि यह केंद्रीय विषय है (या कम से कम यही मेरी इच्छा है)।

आप आमतौर पर इस तरह के विवाद को कैसे हल करते हैं? वोटिंग? ट्राइएज?

मुख्य प्रस्ताव क्या कुछ है जैसे कि मुल? (C, A, B; α = true, proposal = false)?

मुझे यह पसंद है, लेकिन बिना kwargs के।

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

केवल डेटा एकत्र करने के लिए (कम से कम इस समय), चलो मतदान करें:

_C = αAB + ?C_ के लिए आपका पसंदीदा फ़ंक्शन नाम क्या है?

• : +1: mul!
• : -1: addmul!
• : मुस्कान: muladd!
• : टाडा: कुछ और

मेरे लिए addmul! वर्णन करने के लिए लगता है (A+B)C के बजाय AB + C ।

पहले तो मैंने mul! लिए मतदान किया फिर मैंने ऑपरेशन को देखा और सोचा "यह एक गुणा और फिर एक ऐड है, जाहिर है हमें इसे muladd! कहना चाहिए। अब मैं इसे कॉल करने के बारे में नहीं सोच सकता। कुछ और। तथ्य यह है कि यह जगह में ! द्वारा स्पष्ट रूप से इंगित किया गया है और स्केलिंग भाग कीवर्ड के लिए उपयुक्त लगता है।

यह एक गुणा और फिर एक जोड़ है, जाहिर है हमें इसे muladd! कहना चाहिए

केवल अगर आप डिफ़ॉल्ट मूल्य β=true , लेकिन फिर किसी भी अन्य मूल्य के लिए यह फिर से कुछ सामान्य है। तो इसे mul! न कहे जाने का क्या मतलब है, जहाँ कोई अन्य मूल्य तो डिफ़ॉल्ट मूल्य β=false भी आपको कुछ सामान्य देता है? और आप muladd(x,y,z) = x*y + z तुलना करते हुए, तर्कों का आदेश कैसे देंगे? कुछ गड़बड़ होगी, नहीं?

मुझे लगता है कि muladd! को वर्णनात्मक लगने का दोष है जब यह नहीं है: स्केलिंग वाले हिस्से का उल्लेख करने के लिए एक वर्णनात्मक नाम scalemuladd! होगा।

इसलिए मैं mul! पसंद करता हूं क्योंकि यह उम्मीदों के लिए नेतृत्व नहीं करने के लिए पर्याप्त है।

उस ने कहा, मैं आलसी संस्करण को LazyArrays.jl MulAdd में कहता हूं।

मैं muladd! से mul! प्राथमिकता देता हूं क्योंकि यह एक फ़ंक्शन को अलग रखना अच्छा है जो कभी भी उपयोग करने वाले फ़ंक्शन से C ( mul! ) के मूल्य का उपयोग नहीं करता है ( muladd! )।

• तकनीकी रूप से यह एक मैट्रिक्स गुणन है: [AC] * [Bα; I comment] या, नीचे टिप्पणी देखें, [αA *C] * [B; मैं]
• ~ हमारे पास पहले से ही विरल मैट्रिस के लिए 5-arg mul! , घने लिनेगल के लिए समान होगा ~ (एक नया तर्क नहीं)

तो मैं इसे mul! कहने के पक्ष में रहूँगा।

• तकनीकी रूप से यह एक मैट्रिक्स गुणन है: [AC] * [Bα; Iβ]

... अगर eltype में कम्यूटेटिव गुणा है

... अगर eltype कम्यूटेटिव है।

@Andreasnoack जूलिया के साथ एक चर्चा से IIRC सिर्फ gemm / gemv y <- A * x * α + y * β रूप में परिभाषित करता है क्योंकि यह सबसे अधिक समझ में आता है।

@haampie यह अच्छी तरह से पता है! जैसा कि मैंने इसे # 29634 में दूसरे तरीके से लागू किया।

यह सीमित मदद का है, लेकिन

       C = α*A*B + β*C

सबसे अच्छा तरीका है कि मैं ऑपरेशन को व्यक्त करने के लिए आ सकता हूं और इसलिए शायद एक मैक्रो <strong i="8">@call</strong> C = α*A*B + β*C या <strong i="10">@call_specialized</strong> ... या इन पंक्तियों के साथ कुछ एक प्राकृतिक इंटरफ़ेस होगा - समान स्थितियों के लिए भी। फिर अंतर्निहित फ़ंक्शन को जो भी कहा जा सकता है।

@dlfivefifty द्वारा @mschauer LazyArrays.jl में आपके सिंटैक्स (और अधिक!) की तरह 5-तर्क mul! कॉल करने के लिए एक बढ़िया सिंटैक्स है।

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

केवल अगर आप डिफ़ॉल्ट मूल्य β=true , लेकिन फिर किसी भी अन्य मूल्य के लिए यह फिर से कुछ सामान्य है। तो इसे mul! न कहने का क्या मतलब है, जहाँ कोई अन्य मूल्य तो डिफ़ॉल्ट मूल्य β=false भी आपको कुछ और सामान्य देता है? और आप muladd(x,y,z) = x*y + z तुलना करते हुए, तर्कों का आदेश कैसे देंगे? कुछ गड़बड़ होगी, नहीं?

यकीन है कि वहाँ कुछ स्केलिंग है, लेकिन ऑपरेशन की "हड्डियों" स्पष्ट रूप से गुणा और जोड़ रहे हैं। मैं भी साथ ठीक होगा muladd!(A, B, C, α=true, β=false) के हस्ताक्षर से मेल करने के muladd । दस्तावेज करना होगा, निश्चित रूप से, लेकिन यह बिना कहे चला जाता है। यह मुझे इस तरह की इच्छा करता है कि muladd ने पहले additive हिस्सा लिया, लेकिन जहाज उस एक पर रवाना हो गया।

और muladd(x,y,z) = x*y + z तुलना करते हुए, आप कैसे तर्कों का आदेश देंगे? कुछ गड़बड़ होगी, नहीं?

यही कारण है कि मैं addmul! muladd! से अधिक पसंद करता हूं। हम यह सुनिश्चित कर सकते हैं कि तर्कों का क्रम स्केलर muladd । (हालांकि मैं muladd! mul! अधिक पसंद करता हूं)

FWIW यहाँ अब तक के तर्कों का सारांश है। (मैंने तटस्थ रहने की कोशिश की, लेकिन मैं समर्थक muladd! / addmul! इसलिए इसे ध्यान में रखें ...)

मुख्य असहमति यह है कि उत्तरार्द्ध के लिए एक नया नाम देने के लिए _C = AB_ और _C = αAB + _C अलग हैं या नहीं।

वे समान हैं क्योंकि ...

1. यह BLAS-3 और अच्छी तरह से कंपोजेबल है। तो, _C = αAB + βC_ _C = AB_ (https://github.com/JuliaLang/julia/issues/23919#issuecomment-441246466) https://github.com/JuliaLang/julia/issues/ का स्पष्ट सामान्यीकरण है। 23919 # जारीकरण -441312375, आदि)

2. _ " muladd! को वर्णनात्मक ध्वनि की कमी है जब यह नहीं है: एक वर्णनात्मक नाम scalemuladd! जैसे स्केलिंग भाग का उल्लेख करने के लिए कुछ होगा।" _ --- https://github.com/ जूलियालैंग / जूलिया / मुद्दे / 23919 # जारी करना -441819470

3. _ "तकनीकी रूप से यह एक मैट्रिक्स गुणा है: [AC] * [Bα; Iβ]" _ --- https://github.com/JuliaLang/julia/issues/23919#issuecomment -441825259

वे काफी अलग हैं क्योंकि ...

1. _C = αAB + βC_ गुणा (https://github.com/JuliaLang/julia/issues/23919#issuecomment-430809383, https://github.JuliaLang/julia/issues/23919#issuecomment-427075792) से अधिक है। https://github.com/JuliaLang/julia/issues/23919#issuecomment-441813176, आदि)।

2. mul! अन्य सामान्यीकरण हो सकते हैं जैसे Y = A₁ A₂ ⋯ Aₙ X (https://github.com/JuliaLang/julia/issues/23919#issuecomment-402953987 आदि)

3. इनपुट-ओनली बनाम इनपुट-आउटपुट पैरामीटर: यह एक फ़ंक्शन है जो C डेटा का उपयोग तर्कों की संख्या के आधार पर करता है (https://github.com/JuliaLang/julia/issues/239n#issuecomment) -441267056, https://github.com/JuliaLang/julia/issues/23919#issuecomment-441824982)

एक और कारण है कि mul! बेहतर है क्योंकि ...:

1. विरल मैट्रिक्स पहले से ही है। तो यह पिछड़े संगतता के लिए अच्छा है। काउंटर तर्क: पांच-तर्क mul! प्रलेखित नहीं है, इसलिए हमें इसे सार्वजनिक एपीआई के रूप में विचार करने की आवश्यकता नहीं है।

और क्यों muladd! / addmul! बेहतर है क्योंकि ...:

1. हम mul! और muladd! / addmul! अलग-अलग (https://github.com/JuliaLang/julia/issues) के लिए अलग-अलग तीन- या चार-तर्क "आसान कार्य" कर सकते हैं। / 23919 # जारीकरण -402953987, https://github.com/JuliaLang/julia/issues/23919#issuecomment-431046516, आदि)। काउंटर तर्क: mul!(y, A, x) (https://github.com/JuliaLang/julia/issues/23919#issuecomment-4306493434, आदि) की तुलना में mul!(y, A, x, 1, 1) लिखना अधिक क्रिया नहीं है।

उद्देश्य सारांश @tkf के लिए धन्यवाद

मैं भी मुल्लाद के हस्ताक्षर से मिलान करने के लिए मूलाद! (ए, बी, सी, α = सच, false = गलत) के साथ ठीक होगा।

मुझे आशा है कि mulladd! नामक एक फ़ंक्शन के लिए डिफ़ॉल्ट β=true । फिर भी, मैं बहस के इस आदेश है, जिसमें से निर्धारित होता लगता है muladd , बहुत के संबंध में भ्रामक हो जाएगा mul!(C,A,B)

शायद मैं गलत हूं, लेकिन मुझे लगता है कि ज्यादातर लोगों / अनुप्रयोगों / उच्च-स्तरीय कोड (जो पहले से ही केवल गुणक ऑपरेटर * से संतुष्ट नहीं हैं) को mul! । βC को मिलाने की क्षमता, β=1 ( true )) या अन्यथा, निम्न स्तर के कोड में उपयोग की जाएगी, जो लोग जानते हैं कि मैट्रिक्स गुणन के लिए BLAS API सक्षम करता है यह। मुझे लगता है कि ये लोग mul! तहत इस कार्यक्षमता की तलाश करेंगे, जो कि gemm , gemv लिए स्थापित जूलिया इंटरफ़ेस है, ... एक नया नाम जोड़ना (जो भ्रामक है) विपरीत तर्क आदेश) इसके लायक नहीं लगता है; मैं लाभ देखने में असफल हूं?

मुझे लगता है कि ये लोग mul! तहत इस कार्यक्षमता की तलाश करेंगे, जो कि gemm , gemv लिए स्थापित जूलिया इंटरफ़ेस है, ... एक नया नाम जोड़ना (जो भ्रामक है) विपरीत तर्क आदेश) इसके लायक नहीं लगता है; मैं लाभ देखने में असफल हूं?

मुझे लगता है कि खोजशीलता कोई बड़ी समस्या नहीं है क्योंकि हम केवल muladd! mul! डॉकिंग स्ट्रिंग में उल्लेख कर सकते हैं। जो लोग बीएलएएस जानने के लिए पर्याप्त कुशल हैं, उन्हें पता होगा कि एपीआई की तलाश में कहां, सही?

स्थिति संबंधी बनाम कीवर्ड दलीलों के बारे में: यह अभी तक यहां चर्चा नहीं की गई है, लेकिन मुझे लगता है कि C = αAB + βC α साथ एक विकर्ण मैट्रिक्स कुशलतापूर्वक और आसानी से स्केलर α रूप में लागू किया जा सकता है। इस तरह के विस्तार के लिए आवश्यक है कि हम α के प्रकार को भेज सकें जो कि कीवर्ड तर्क के साथ असंभव है।

इसके अलावा, गैर-संयुक्ताक्षर योग के लिए, आप muladd!(α', B', A', β', C') (काल्पनिक तर्क आदेश) को कॉल करके C = ABα + Cβ कुशलता से गणना करना चाह सकते हैं। यह आवश्यकता हो सकती है कि आप आलसी रैपरों पर Adjoint(α) और Adjoint(β) प्रेषण कर सकें। (मैं व्यक्तिगत रूप से जूलिया में गैर-कम्यूटेटिव नंबरों का उपयोग नहीं करता हूं इसलिए यह संभवतः बहुत काल्पनिक है।)

मैं @ जूथो की इस बात से सहमत हूं कि यह

कीवर्ड तर्क से बचने के लिए एक और तर्क है, जो https://andithub.com/JuliaLang/julia/issues/23919#issuecomment -365762889 से पहले @andreasnoack ने कहा:

जब तक आप BLAS नहीं जानते तब तक α और β भी सुपर सहज नहीं हैं

@tkf, सुनिश्चित करें कि, मेरे तर्क नहीं बल्कि यह है: के वास्तविक उपयोग करता है की संख्या β != 0 की तुलना में छोटा होगा β == 0 , और जो लोग जरूरत है यह हैरान नहीं किया जाएगा इस से थोड़ा अधिक सामान्य लगता है mul! तहत व्यवहार। इसलिए, मैं इसे एक नए नाम के तहत अलग करने का लाभ नहीं देखता, खासकर जब से तर्क क्रम गड़बड़ हो गया है ( muladd! कम से कम)। यदि इसे एक नई विधि बनानी है, तो मैं addmul! लिए आपके तर्क के प्रति भी सहानुभूति रखता हूं।

जिन लोगों को इसकी आवश्यकता है, उन्हें mul! तहत इस थोड़े अधिक सामान्य व्यवहार को देखकर आश्चर्य नहीं होगा।

मैं इस बात से सहमत हूं।

इसलिए, मैं इसे एक नए नाम के तहत अलग करने का लाभ नहीं देखता,

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

खासकर जब से तर्क आदेश गड़बड़ हुआ है ( muladd! कम से कम)

मुझे लगता है कि आप इसे नुकसान के रूप में गिनेंगे और मुझे यह बात मिलेगी। यह सिर्फ मुझे लगता है कि muladd! / addmul! लिए अन्य लाभ अधिक महत्वपूर्ण हैं।

मुझे लगता है कि आप इसे नुकसान के रूप में गिनेंगे और मुझे यह बात मिलेगी। यह सिर्फ मैं muladd के लिए अन्य लाभ लगता है! / Addmul अधिक महत्वपूर्ण हैं।

यह वास्तव में नुकसान है, इस तथ्य के साथ कि mul! हमेशा गुणन से संबंधित कई BLAS कार्यों में एकल प्रविष्टि बिंदु रहा है, इसे α और β तक पूर्ण पहुंच न देकर प्रतिबंधित किया जाए। और अब muladd! , दो अलग-अलग प्रवेश बिंदु होंगे, अनुरोधित ऑपरेशन में बस थोड़ा सा अंतर के आधार पर जिसे आसानी से एक तर्क द्वारा पकड़ा जा सकता है (और वास्तव में, जो BLAS API में एक तर्क द्वारा कैप्चर किया गया है) । मुझे लगता है कि यह पहली बार जूलिया में एक गलती थी जो बीएलएएस एपीआई (इसलिए उस @tkf को ठीक करने के लिए धन्यवाद) की पूरी पहुंच प्रदान नहीं करता है। यह पुराने भयानक फोरट्रान नामकरण सम्मेलन के बावजूद, मुझे लगता है कि ये लोग जानते थे कि वे इस तरह से काम क्यों कर रहे थे। लेकिन इसी तरह, मुझे लगता है कि संचालन का यह परिवार (यानी α और under द्वारा परिचालित परिचालनों का 2-पैरामीटर परिवार एकल प्रविष्टि बिंदु के तहत एक साथ है, क्योंकि वे बीएलएएस में हैं।

मेरे विचार में सबसे मान्य काउंटर तर्क है कि C में मूल डेटा तक पहुँचा जा सकेगा या नहीं। लेकिन इस तथ्य को देखते हुए कि जूलिया ने शून्य परिणाम की गारंटी देने के तरीके के रूप में false साथ गुणा किया है, तब भी जब अन्य कारक NaN , मुझे लगता है कि यह भी ध्यान रखा गया है। लेकिन शायद इस तथ्य को बेहतर ढंग से संप्रेषित / प्रलेखित करने की आवश्यकता है (यह कुछ समय हो गया है क्योंकि मैंने दस्तावेज़ीकरण पढ़ा है), और मैंने भी हाल ही में इसके बारे में सीखा है। (यही कारण है कि KrylovKit.jl में, मुझे एक fill! पद्धति के अस्तित्व की आवश्यकता है, एक मनमाने ढंग से वेक्टर-जैसे उपयोगकर्ता प्रकार को शून्य के साथ आरंभ करने के लिए। लेकिन अब मुझे पता है कि मैं इसके बजाय rmul!(x,false) कर सकता हूं। इसलिए मुझे उस fill! लागू होने की आवश्यकता नहीं है)।

यह सिर्फ मैं muladd के लिए अन्य लाभ लगता है! / Addmul अधिक महत्वपूर्ण हैं।

तो मुझे इस सवाल को उलट देना चाहिए कि एक नई विधि होने के अन्य लाभ क्या हैं? मैंने आपका सारांश फिर से पढ़ा है, लेकिन मैं केवल C तक पहुंचने की बात देख रहा हूं, जिस पर मैंने अभी टिप्पणी की है।

मैंने आज सुबह अपनी पत्नी का जिक्र किया कि जूलिया समुदाय में एक ऑपरेशन के नामकरण को लेकर दो महीने की लंबी बातचीत हुई है। उसने सुझाव दिया कि इसे "फ्रेड" कहा जाए! - नहीं नहीं, कोई गहरा अर्थ नहीं है, बस एक अच्छा नाम है। बस उसे वहाँ से बाहर कर दिया।

अच्छा है कि वह एक विस्मयादिबोधक चिह्न शामिल है! 😄

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

नई विधि होने के ये अन्य लाभ क्या हैं?

जैसा कि आपने टिप्पणी की, मुझे लगता है कि आउटपुट बनाम इनपुट-आउटपुट पैरामीटर तर्क सबसे महत्वपूर्ण है। लेकिन यह सिर्फ एक कारण है कि मुझे लगता है कि _C = αAB + isC_ _C = AB_ से अलग है। मुझे यह भी लगता है कि साधारण तथ्य यह है कि वे इस अर्थ में भिन्न हैं कि पूर्व अभिव्यक्ति बाद के सख्त "सुपरसेट" कोड में स्पष्ट दृश्य संकेत की आवश्यकता है। अलग-अलग नाम एक मध्यवर्ती प्रोग्रामर (या थोड़े अनफ़ोकस्ड एडवांस्ड प्रोग्रामर) को स्किमिंग कोड और यह सूचित करने में मदद करते हैं कि यह mul! तुलना में कुछ weirder का उपयोग कर रहा है।

मैंने फिर से पोल की जाँच mul! से muladd! चले गए? पिछली बार मैंने इसे देखा था, mul! जीत रहा था। चलिए इससे पहले कि वे यहाँ चले जाएँ: हँसते हुए:

• mul! : 6
• addmul! : 2
• muladd! : 8
• कुछ और: १

थोड़ा और अधिक गंभीरता से, मुझे अभी भी लगता है कि यह डेटा mul! या muladd! अन्य की तुलना में स्पष्ट नहीं है। (हालांकि यह दर्शाता है कि addmul! अल्पसंख्यक है: sob :)

ऐसा महसूस होता है कि हम फंस गए हैं। हम कैसे आगे बढ़ते हैं?

बस इसे gemm! बजाय कहेंगे?

बस इसे जेम कहते हैं! बजाय?

मुझे उम्मीद है कि यह एक मजाक है ... जब तक आप मैट्रिक्स * वेक्टर के लिए gemm!(α, A::Matrix, x::Vector, β, y::Vector) = gemv!(α, A, x, β, y) प्रस्ताव नहीं दे रहे हैं।

क्या हम mul! इंटरफ़ेस को छोड़ सकते हैं जो पहले से ही मौजूद है (विरल मैट्रिस के साथ) के लिए अब हम PR को मर्ज कर सकते हैं और इसमें सुधार कर सकते हैं, और चिंता करें कि क्या हम दूसरे PR में muladd! जोड़ना चाहते हैं ?

शायद यह पहले से ही यहाँ हर किसी के लिए स्पष्ट है, लेकिन मैं सिर्फ इस बात पर जोर देना चाहता था कि वोट नहीं है

• mul! बनाम muladd!

परंतु

• mul! बनाम ( mul! और muladd! )

अर्थात एकल के बजाय दो उत्परिवर्तन गुणन कार्य।

मैंने किसी भी समय पोस्ट नहीं करने का फैसला किया क्योंकि मैंने mul! पक्ष में पोस्ट किया, वोट mul! ( mul! और muladd! ) से स्थानांतरित होते प्रतीत हुए।

हालाँकि, मेरे पास एक सवाल है? अगर हम वर्तमान बहुमत वाले वोट के साथ जाते हैं, और हमारे पास mul!(C,A,B) और muladd!(A,B,C,α=true,β=true) , और मैं एक ऐसा PR तैयार करना चाहता हूं जो axpy! और axpby! साथ add! , कि add!(y, x, α=true, β=true) या add!(x, y, α=true, β=true) (जहां, स्पष्टता के लिए, y उत्परिवर्तित है)। या कुछ और?

यदि यह स्पष्ट नहीं है, तो muladd!(A,B,C) उस कन्वेंशन का उल्लंघन करेंगे जो उत्परिवर्तित तर्क पहले जाते हैं ।

क्या हम mul! इंटरफ़ेस छोड़ सकते हैं जो पहले से मौजूद है

@ जेजेब मुझे लगता है कि इस "पिछड़े संगतता" तर्क पर बड़े पैमाने पर चर्चा की गई है। फिर भी, यह किसी को मना नहीं करता (मतदान को देखते हुए, यह सिर्फ मेरे लिए नहीं है)।

इस बारे में चिंता करें कि क्या हम दूसरे PR में muladd! जोड़ना चाहते हैं?

सार्वजनिक एपीआई को तोड़ना बुरा है। इसलिए अगर हम mul! तो यह mul! हमेशा के लिए है (हालांकि सिद्धांत में LinearAlgebra API को तोड़ने के लिए इसके प्रमुख संस्करण को टक्कर दे सकता है)।

मैं एक ऐसा पीआर तैयार करना चाहता हूं जो axpy! और axpby! पर एक अधिक जूलियन नाम के साथ add! , add!(y, x, α=true, β=true) या add!(x, y, α=true, β=true)

@ जूथो धन्यवाद, यह बहुत अच्छा होगा! मुझे लगता है कि एक बार जब हमने बहु-ऐड-एपीआई एपीआई के कॉल हस्ताक्षर का फैसला किया तो तर्क का क्रम चुनना सीधा होगा।

muladd!(A,B,C) कन्वेंशन का उल्लंघन होगा जो कि उत्परिवर्तित तर्क पहले जाते हैं ।

@simonbyrne लेकिन (आप पहले से ही https://github.com/JuliaLang/julia/issues/23919#issuecomment-426881998 में उल्लेख किया), lmul! और ldiv! मे बदलें गैर पहला तर्क। इसलिए मुझे लगता है कि हमें पसंद से muladd!(A,B,C,α,β) बाहर करने की आवश्यकता नहीं है, बल्कि इसे इस हस्ताक्षर के लिए एक नकारात्मक बिंदु के रूप में गिना जाता है।

(लेकिन मैं कहूंगा कि अगर हम "पाठ्य क्रम" एपीआई के लिए जा रहे हैं तो muladd!(α, A, B, β, C) साथ जाना होगा।)

वैसे, एक बात जो मुझे वोट के परिणाम से समझ में नहीं आती, वह है muladd! और addmul! की विषमता। यदि आप C = βC + αAB लिखते हैं, तो मुझे लगता है कि यह addmul! अधिक स्वाभाविक है।

@tkf यह इस बारे में है कि आप पहले कौन सा ऑपरेशन करते हैं। मेरे लिए addmul! सुझाव है कि आप पहले एक जोड़ करते हैं, और फिर गुणा करें, जैसा कि (A+B)C । बेशक यह व्यक्तिपरक है। लेकिन अच्छे नामों को अंतर्ज्ञान की अपील करनी चाहिए।

आह, मुझे वह बात मिल गई।

जैसा कि यह अभी भी अटका हुआ है, मेरे प्रस्ताव का उपयोग पैटर्न होगा जिसमें फ़ंक्शन परिभाषाओं से युक्त ( @callexpr सेकंड के लिए जा रहा है)

@callexpr(C .= β*C + α*A*B) = implementation(C, β, α, A, B)
@callexpr(C .= β*C + A*B) = implementation(C, β, true, A, B)

और शायद एक अधिक प्रचलित मैत्रीपूर्ण रूप (दूसरे के लिए @callname के साथ जा रहा है)

function @callname(β*C + A*B)(C::Number, β::Number, A::Number, B::Number)
     β*C + A*B
end

और कॉल करता है

@callexpr(A .= 2*C + A*B)
@callexpr(2*3 + 3*2)

और किसी को भी चिंता करने की ज़रूरत नहीं है (या जानते हैं) कि कैसे callexpr बीजीय प्रचालनों को एक अद्वितीय फ़ंक्शन नाम में (जो कि तर्क प्रतीकों पर निर्भर नहीं करता है, केवल संचालन और संचालन के क्रम पर है।)
मैंने कार्यान्वयन के बारे में थोड़ा सोचा और यह अच्छी तरह से उचित होना चाहिए।

@mschauer मुझे लगता है कि यह एक दिलचस्प दिशा है। क्या आप एक नया मुद्दा खोल सकते हैं? आपके द्वारा प्रस्तावित एपीआई कई अन्य मुद्दों को हल कर सकता है। मुझे लगता है कि जिस मुद्दे को हल कर सकते हैं उसका एक भी उदाहरण हल करने की तुलना में एक सावधान डिजाइन प्रक्रिया से गुजरना होगा।

तो मैंने अफवाह सुनी है कि अगले हफ्ते 1.1 की सुविधा फ्रीज हो गई है। हालांकि अगली छोटी रिलीज "केवल" चार महीने दूर है, यह वास्तव में अच्छा होगा अगर हम इसे 1.1 में कर सकते हैं ...

वैसे भी, हमें PR को मर्ज करने से पहले कॉल सिग्नेचर (तर्कों और कीवर्ड का क्रम या नहीं) तय करना होगा।

तो चलो फिर से वोट करें (जैसा कि मैंने पाया है कि यह एक अच्छा उत्तेजक है)।

_If_ हम _C = ABα + C ,_ के लिए muladd! उपयोग करते हैं, आपका पसंदीदा कॉल हस्ताक्षर क्या है?

• : +1: muladd!(C, A, B, α, β)
• : -1: muladd!(A, B, C, α, β)
• : मुस्कान: muladd!(C, A, B; α, β) (जैसे: +1 :, लेकिन कीवर्ड तर्क के साथ)
• : टाडा: muladd!(A, B, C; α, β) (जैसे: -१ :, लेकिन खोजशब्द तर्क के साथ)
• : भ्रमित: muladd!(A, B, α, C, β)
• : दिल: कुछ और

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

जैसा कि हमने तय नहीं किया है कि नाम क्या होना चाहिए, हमें इसे mul! के लिए भी करने की आवश्यकता है:

_If_ हम _C = ABα + C ,_ के लिए mul! उपयोग करते हैं, आपका पसंदीदा कॉल हस्ताक्षर क्या है?

• : +1: mul!(C, A, B, α, β)
• : -1: mul!(A, B, C, α, β)
• : मुस्कान: mul!(C, A, B; α, β) (जैसे: +1 :, लेकिन कीवर्ड तर्क के साथ)
• : टाडा: mul!(A, B, C; α, β) (यह असंभव है)
• : भ्रमित: mul!(A, B, α, C, β)
• : दिल: कुछ और

नोट: हम मौजूदा API mul!(C, A, B) को नहीं बदल रहे हैं

नोट: हम मौजूदा API mul!(C, A, B) को नहीं बदल रहे हैं

मैंने इस तथ्य पर पर्याप्त ध्यान नहीं दिया था- हमारे पास पहले से ही mul! और इसका यही अर्थ है:

mul!(Y, A, B) -> Y

गणना करता है मैट्रिक्स मैट्रिक्स या मैट्रिक्स वेक्टर उत्पाद A*B और दुकानों में परिणाम Y , के मौजूदा मूल्य अधिलेखित Y । ध्यान दें कि Y को A या B साथ अलियास नहीं किया जाना चाहिए।

यह देखते हुए, यह सिर्फ इस तरह से विस्तार करने के लिए बहुत स्वाभाविक लगता है:

mul!(Y, A, B) -> Y
mul!(Y, A, B, α) -> Y
mul!(Y, A, B, α, β) -> Y

मैट्रिक्स मैट्रिक्स या मैट्रिक्स वेक्टर उत्पाद की गणना करता है A*B में और दुकानों परिणाम Y , के मौजूदा मूल्य अधिलेखन Y । ध्यान दें कि Y को A या B साथ अलियास नहीं किया जाना चाहिए। यदि एक स्केलर मूल्य, α की आपूर्ति की जाती है, तो α*A*B A*B बजाय गणना की जाती है। यदि एक स्केलर मूल्य, β की आपूर्ति की जाती है, तो इसके बजाय α*A*B + β*Y की गणना की जाती है। इन वैरिएंट्स पर एक ही अलियासिंग प्रतिबंध लागू होता है।

हालाँकि, मुझे लगता है कि इसके साथ एक बड़ी चिंता की बात है: यह कम से कम mul!(Y, A, B, C, D) A*B*C*D Y जगह में गणना करने के लिए स्वाभाविक लगता है कि सामान्य धारणा बहुत बुरी तरह से टकराती है mul!(Y, A, B, α, β) कंप्यूटिंग α*A*B + β*C । इसके अलावा, यह मुझे लगता है कि A*B*C*D को Y में कंप्यूटिंग करना एक ऐसी चीज है, जो मध्यवर्ती आवंटन से बचने के लिए कुशलतापूर्वक करना उपयोगी और संभव होगा, इसलिए मैं वास्तव में उस अर्थ को अवरुद्ध नहीं करना चाहूंगा। ।

मन में mul! अन्य प्राकृतिक सामान्यीकरण के साथ, यहाँ एक और विचार है:

mul!(Y, α, A, B) # Y .= α*A*B

के सामान्य मॉडल में यह फिट mul!(out, args...) में जहां की गणना और लिखने out गुणा करके args एक साथ। यह α के साथ सौदा करने के लिए प्रेषण पर निर्भर करता है बजाय इसे एक विशेष मामला बनाने के - यह सिर्फ एक और चीज है जिसे आप गुणा कर रहे हैं। जब α एक अदिश राशि और A , B और Y matrices हों, तो हम इस सुपर को कुशलतापूर्वक करने के लिए BLAS को भेज सकते हैं। अन्यथा, हम एक सामान्य कार्यान्वयन कर सकते हैं।

इसके अलावा, यदि आप एक गैर-कम्यूटेटिव क्षेत्र (जैसे quaternions) में हैं, तो आप नियंत्रित कर सकते हैं कि α के हिसाब से स्केलिंग किस पर होती है: mul!(Y, A, B, α) α बाएँ के बजाय दाईं ओर:

mul!(Y, A, B, α) # Y .= A*B*α

हां, हम क्वाटर्न्स के लिए BLAS को कॉल नहीं कर सकते हैं, लेकिन यह सामान्य है और हम शायद इसे यथोचित रूप से कुशलतापूर्वक कर सकते हैं (हो सकता है कि इसे किसी तरह BLAS कॉल में बदल दें)।

Y .= α*A*B के लिए उस दृष्टिकोण को मानते हुए अगला सवाल बन जाता है: Y स्केलिंग और वेतन वृद्धि के बारे में क्या? मैंने उसके लिए कीवर्ड के बारे में सोचना शुरू किया, लेकिन फिर गैर-कम्यूटेटिव फील्ड का ख्याल आया जो बहुत अजीब और सीमित महसूस हुआ। इसलिए, मैंने इसके बजाय इस एपीआई के बारे में सोचना शुरू कर दिया- जो पहले थोड़ा अजीब लगता है, लेकिन मेरे साथ है:

mul!((β, Y), α, A, B) # Y .= β*Y .+ α*A*B

थोड़ा अजीब है, लेकिन यह काम करता है। और एक गैर-कम्यूटेटिव क्षेत्र में, आप Y को β इस तरह दाईं ओर गुणा करने के लिए कह सकते हैं:

mul!((Y, β), α, A, B) # Y .= Y*β .+ α*A*B

गैर-कम्यूटेटिव क्षेत्र में पूर्ण सामान्यता में, आप बाएं और दाएं दोनों को इस तरह से माप सकते हैं:

mul!((β₁, Y, β₂), α₁, A, B, α₂) # Y .= β₁*Y*β₂ + α₁*A*B*α₂

अब, निश्चित रूप से, यह थोड़ा अजीब है और इसके लिए कोई BLAS ऑपरेशन नहीं है, लेकिन यह GEMM का एक सामान्यीकरण है कि आइए हम चीजों के _lot_ को व्यक्त करते हैं और जिसे हम BLAS संचालन को बिना किसी गंदा के भी भेज सकते हैं, अन्यथा शाखाओं।

मैं वास्तव में एक अंतर्निहित API कॉल के रूप में @StefanKarpinski का सुझाव पसंद करता

@affine! Y = β₁*Y*β₂ + α₁*A*B*α₂

अंतर्निहित फ़ंक्शन तब कुछ ऐसा होगा जैसे @StefanKarpinski का प्रस्ताव है।

लेकिन हमें यहां और आगे जाना चाहिए। मुझे वास्तव में लगता है कि, यदि आप इसके लिए एक एपीआई बनाते हैं और एक सामान्य कार्य करते हैं, तो कोई जूलिया लाइब्रेरी बनाएगा जो इसे कुशलता से करता है, इसलिए मैं मानता हूं कि हमें यहां केवल BLAS से नहीं रहना चाहिए। MatrixChainMultiply.jl जैसी चीजें पहले से ही कई मैट्रिक्स संगणनाओं के लिए डीएसएल का निर्माण कर रही हैं और डिफेक एक्‍पाइन ऑपरेटर भावों के साथ अपनी बात कर रही है। यदि हम बेस में एक अमूर्त अभिव्यक्ति के लिए सिर्फ एक प्रतिनिधित्व करते हैं, तो हम अपने सभी कार्यों को एक ही चीज़ पर परिभाषित कर सकते हैं।

@dlfivefifty ने पहले आलसी रैखिक बीजगणित में देखा, मुझे लगता है कि यहां वास्तव में पुनर्जीवित किया जाना चाहिए। अमूर्त सरणियों और वैकल्पिक कम्प्यूटेशनल हार्डवेयर पर काम करने वाले तत्व-वार संचालन प्राप्त करने के लिए प्रसारण का आलसी प्रतिनिधित्व महत्वपूर्ण था। हमें रैखिक बीजगणित के लिए समान होना चाहिए। रैखिक बीजीय अभिव्यक्तियों का प्रतिनिधित्व हमें एक जूलिया BLAS से मक्खी पर नए BLAS गुठली को परिभाषित करने या एक GPU / TPU पर समीकरणों को स्थानांतरित करने की अनुमति देगा।

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

मुझे इस प्रस्ताव के बारे में अधिक सोचना होगा, लेकिन अभी के लिए, मैं सिर्फ टिप्पणी करूंगा कि मुझे नहीं लगता कि आप अस्थायी बिना A*B*C गणना करना चाहते हैं। यह मुझे लगता है कि अस्थायी से बचने के लिए आपको बहुत सारे अंकगणितीय कार्यों के साथ भुगतान करना होगा।

मुझे नहीं लगता कि आप अस्थायी बिना A*B*C गणना करना चाहते हैं।

हालाँकि, mul! आपके पास पहले से ही एक आउटपुट ऐरे है। मुझे यकीन नहीं है कि मदद करता है या नहीं। किसी भी मामले में, यह एक कार्यान्वयन विवरण की तरह लगता है। एपीआई mul!(Y, A, B, C...) व्यक्त करता है कि आप क्या गणना करना चाहते हैं और कार्यान्वयन इसे करने का सबसे अच्छा तरीका चुन सकते हैं, जो यहां सामान्य लक्ष्य था।

मैं वास्तव में एक अंतर्निहित API कॉल के रूप में @StefanKarpinski का सुझाव पसंद करता

@ क्रिसट्रैकैस : मुझे लगता है कि आपके अंदर जाने वाली चीजें और बाहरी पैकेजों में तलाश की जानी चाहिए - आलस्य, जो आप चाहते हैं उस लेखन को लिखना और कुछ प्रकार के ऑप्टिमाइज़ेशन पास लेने के लिए कुछ ऐसे बीजीय पैटर्न से मेल खाते हैं जो इसे अनुकूलित करना जानते हैं। mul! का उपयोग करना इस तरह का लगता है जैसे कि हम इस स्तर पर जेनेरिक लेकिन आसानी से समझने वाला ऑपरेशन चाहते हैं।

ध्यान दें कि mul!(Y, α, A, B) होने की कोई वास्तविक बहस नहीं है - बहुत अधिक Y .= α*A*B होने का मतलब है क्योंकि इसका और क्या मतलब होगा? तो मेरे लिए यहाँ एक ही खुला प्रश्न है कि क्या मैट्रिक्स और बाएँ और / या दाएं स्केलरों के साथ एक ट्यूपल का उपयोग करना यह व्यक्त करने का एक उचित तरीका है कि हम वेतन वृद्धि को बढ़ाना और स्केल करना चाहते हैं। सामान्य मामले होंगे:

1. mul!(Y::Matrx, args...) : Y .= *(args...)
2. mul!((β, Y)::{Number, Matrix}, args...) : Y .= β*Y + *(args...)
3. mul!((Y, β)::{Matrix, Number}, args...) : Y .= Y*β + *(args...)
4. mul!((β₁, Y, β₂)::{Number, Matrix, Number}, args...) : Y .= β₁*Y*β₂ + *(args...)

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

यह मेरे " mul!(out, args...) "

लेकिन मेरी चिंता यह है कि यदि ओवरलोडिंग इंटरफ़ेस के रूप में उपयोग करना आसान है। हमें नेस्टेड टुपल्स के लिए अच्छी तरह से काम करने के लिए टाइप सिस्टम पर भरोसा करने की आवश्यकता है। क्या नेस्टेड ट्यूपल्स जूलिया के प्रकार प्रणाली में फ्लैट ट्यूपल्स के रूप में अच्छा काम करते हैं? अगर की तरह कुछ "मैं सोच रहा हूँ Tuple{Tuple{A1,B1},C1,D1} की तुलना में अधिक विशिष्ट है Tuple{Tuple{A2,B2},C2,D2} iff Tuple{A1,B1,C1,D1} अधिक है की तुलना में विशिष्ट Tuple{A2,B2,C2,D2} रखती है"। अन्यथा यह अधिभार एपीआई के रूप में उपयोग करने के लिए मुश्किल होगा।

ध्यान दें कि हमें जटिल मैट्रिसेस के लिए पुनर्व्याख्या हैक का उपयोग करने के लिए अदिश प्रकार पर प्रेषण करने की आवश्यकता है (यह PR # 29634 से है ताकि फ़ंक्शन नाम पर ध्यान न दें):

https://github.com/JuliaLang/julia/blob/fae1a7a3ae646c7ea1c08982976b57096fb0ae8d/stdlib-LinearAlgebra/src/matmul.jl#L157 -L169 -L169

एक और चिंता की बात यह है कि यह एक संगणना ग्राफ निष्पादनकर्ता के लिए कुछ हद तक सीमित इंटरफ़ेस है। मुझे लगता है कि मल्टीप्लेयर-ऐड इंटरफ़ेस का मुख्य उद्देश्य पुस्तकालय कार्यान्वयनकर्ताओं को एक छोटे से पुन: प्रयोज्य संगणना कर्नेल को परिभाषित करने के लिए एक ओवरलोडिंग एपीआई प्रदान करना है जिसे कुशलता से लागू किया जा सकता है। इसका अर्थ है कि हम केवल _C = ABα_ लागू कर सकते हैं, उदाहरण के लिए, _αAB_ (https://github.com/JuliaLang/julia/pull/29634#issuecomment-44310363667) देखें। गैर-संयुक्ताक्षरी के लिए _αutABα₂_ का समर्थन करने के लिए या तो एक अस्थायी सरणी की आवश्यकता होती है या अंकगणितीय ऑपरेशनों की संख्या बढ़ाना होता है। यह स्पष्ट नहीं है कि कौन सा उपयोगकर्ता चाहता है और आदर्श रूप से यह विन्यास योग्य होना चाहिए। इस बिंदु पर हमें निष्पादन तंत्र से अलग एक संगणना ग्राफ प्रतिनिधित्व की आवश्यकता होती है। मुझे लगता है कि बाहरी पैकेज (जैसे, LazyArrays.jl, MappedArrays.jl) में इसका बेहतर पता लगाया जा सकता है। हालांकि, अगर हम किसी कार्यान्वयन रणनीति को पा सकते हैं जो किसी न किसी बिंदु पर सबसे अधिक उपयोग को कवर करती है, तो मुख्य प्रविष्टि बिंदु के रूप में mul! का उपयोग करना होगा। मुझे लगता है कि यह वास्तव में muladd! पक्ष में एक और कारण है; भविष्य के कॉलिंग एपीआई के लिए एक स्थान आवंटित करना।

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

आप वास्तव में इस बात का प्रमाण दे सकते हैं कि दसियों की एक मनमानी संख्या के किसी भी संकुचन, पूरी चीज का मूल्यांकन करने का सबसे कुशल तरीका हमेशा युग्मक संकुचन का उपयोग कर रहा है। इसलिए कई मैट्रिसेस को गुणा करना सिर्फ एक विशेष मामला है, आपको उन्हें जोड़ीदार तरीके से गुणा करना चाहिए (सबसे अच्छा ऑर्डर निश्चित रूप से एक गैर-तुच्छ समस्या है)। इसलिए मुझे लगता है कि mul!(Y,X1,X2,X3...) इतनी उपयोगी आदिम नहीं है। और अंत में, मुझे लगता है कि mul! है, यह एक आदिम संचालन है जो डेवलपर्स अपने विशिष्ट प्रकारों के लिए अधिभार कर सकते हैं। किसी भी अधिक जटिल ऑपरेशन को उच्च स्तर के निर्माण का उपयोग करके लिखा जा सकता है, उदाहरण के लिए मैक्रोज़ का उपयोग करना, और उदाहरण के लिए एक गणना ग्राफ बनाया जाएगा, जिसका अंत में mul! जैसे आदिम संचालन को कॉल करके मूल्यांकन किया जाता है। बेशक, कि आदिम गैर-कम्यूटेटिव जैसे @StefanKarpinski उल्लेखों जैसे मामलों को शामिल करने के लिए पर्याप्त रूप से सामान्य हो सकता है।

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

सामान्य तौर पर, मैं मानता हूं कि आधार में एक डिफ़ॉल्ट आलसी प्रतिनिधित्व / अभिकलन ग्राफ प्रकार होना अच्छा होगा, लेकिन मुझे नहीं लगता कि mul! इसका निर्माण करने का तरीका है।

@tkf :

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

हाँ, हम उस मोर्चे पर अच्छे हैं। मुझे यकीन नहीं है कि घोंसला कहाँ आता है, लेकिन कुछ चीजों को गुदगुदी से गुजारना बस उतनी ही कुशल है जितना कि उन सभी को तत्काल तर्क देना - यह बिल्कुल उसी तरह से लागू होता है।

इसका अर्थ है कि हम केवल _C = ABα_ लागू कर सकते हैं, उदाहरण के लिए, _αAB_

मुझे भ्रम है ... आप mul!(C, A, B, α) और mul!(C, α, A, B) लिख सकते हैं। आप mul!(C, α₁, A, α₂, B, α₃) भी लिख सकते हैं। यह अब तक प्रस्तावित सबसे लचीली जेनेरिक मैट्रिक्स गुणन एपीआई की तरह लगता है।

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

इस बिंदु पर हमें निष्पादन तंत्र से अलग एक संगणना ग्राफ प्रतिनिधित्व की आवश्यकता होती है।

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

@Jutho

इसलिए कई मैट्रिसेस को गुणा करना सिर्फ एक विशेष मामला है, आपको उन्हें जोड़ीदार तरीके से गुणा करना चाहिए (सबसे अच्छा ऑर्डर निश्चित रूप से एक गैर-तुच्छ समस्या है)। इसलिए मुझे लगता है कि mul!(Y,X1,X2,X3...) इतनी उपयोगी आदिम नहीं है।

mul! संचालन कार्यान्वयन को गुणन के क्रम को चुनने की अनुमति देगा, जो एक उपयोगी संपत्ति है। वास्तव में, संभावित रूप से ऐसा करने की क्षमता थी, इसलिए हमने पहली जगह में * ऑपरेशन पार्स को n-ary के रूप में बनाया और यही तर्क mul! पर भी लागू होता है क्योंकि आप इसका उपयोग कर रहे हैं , आप संभवतः प्रदर्शन के बारे में पर्याप्त देखभाल करते हैं।

सामान्य तौर पर, मैं यह नहीं बता सकता कि आप mul! लिए मेरे प्रस्ताव के लिए बहस कर रहे हैं या नहीं।

मुझे यकीन नहीं है कि घोंसला कहाँ आता है लेकिन कुछ चीजों को गुदगुदी से गुजारना उतना ही कुशल है जितना कि उन सभी को तत्काल तर्क के रूप में पारित करना।

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

इसका अर्थ है कि हम केवल _C = ABα_ लागू कर सकते हैं, उदाहरण के लिए, _αAB_

मुझे भ्रम है ... आप mul!(C, A, B, α) और mul!(C, α, A, B) लिख सकते हैं।

मेरे कहने का अर्थ है "हम केवल _C = ABα_ को कुशलतापूर्वक _C = AB_ के

इस बिंदु पर हमें निष्पादन तंत्र से अलग एक संगणना ग्राफ प्रतिनिधित्व की आवश्यकता होती है।

यह मामला हो सकता है, लेकिन यह इसके लिए जगह नहीं है - जिसे बाहरी पैकेज में विकसित किया जा सकता है और होना चाहिए।

बिलकुल मेरी बात। मैं इस एपीआई को इस तरह के उपयोग के लिए न्यूनतम बिल्डिंग ब्लॉक के रूप में देखने का सुझाव देता हूं (बेशक, यह पूरा उद्देश्य नहीं है)। बाहरी पैकेजों में डिज़ाइन स्थान की खोज करने के बाद वेरग mul! कार्यान्वयन और डिज़ाइन किया जा सकता है।

वर्तमान mul! लिए प्रकारों पर डिस्पैच करना पहले से ही "टूटा हुआ" है: SubArray और Adjoint जैसे कंपोजेबल सरणी प्रकारों के साथ काम करने के लिए आवश्यक अस्पष्टता ओवरब्रिज में एक जुझारू वृद्धि है।

समाधान विशेषता का उपयोग करने के लिए है, और LazyArrays.jl के पास mul! लक्षण के साथ अवधारणा संस्करण का प्रमाण है।

लेकिन यह एपीआई की तुलना में कार्यान्वयन पर अधिक चर्चा है। लेकिन समूह की शर्तों के लिए टुपल्स का उपयोग करना गलत लगता है: क्या यह नहीं है कि किस प्रकार की प्रणाली है? जिस स्थिति में आप LazyArrays.jl समाधान पर पहुंचते हैं।

मुल! ऑपरेशन कार्यान्वयन को गुणन के क्रम को चुनने की अनुमति देगा, जो एक उपयोगी संपत्ति है। वास्तव में, संभावित रूप से ऐसा करने की क्षमता थी, इसलिए हमने * ऑपरेशन पार्स को पहली जगह में n-ary के रूप में बनाया और यही तर्क mul पर और भी अधिक लागू होता है! यदि आप इसका उपयोग कर रहे हैं, तो आप संभवतः प्रदर्शन के बारे में पर्याप्त देखभाल करेंगे।

वह * n पर्स @tensoropt मैक्रो को लागू करने के लिए TensorOperations.jl में इसका उपयोग करता हूं, जो वास्तव में संकुचन आदेश को अनुकूलित करता है। कि मुझे n mul! संस्करण मिलता है क्योंकि कम बिंदु है, दक्षता के दृष्टिकोण से, परिणाम देने के लिए पूर्व-आवंटित जगह प्रदान करने में, यदि सभी मध्यवर्ती सरणियों को अभी भी फ़ंक्शन के अंदर आवंटित किया जाना है और फिर gc'ed। वास्तव में, TensorOperations.jl में, कई लोगों ने देखा कि बड़े अस्थायी लोगों का आवंटन उन स्थानों में से एक है जहां जूलिया का gc वास्तव में बहुत खराब प्रदर्शन कर रहा है (जो अक्सर 50% के gc समय के लिए अग्रणी होता है)।

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

मैं तुपलों के साथ आपके प्रस्ताव को नापसंद नहीं करता, लेकिन संभावित भ्रम को दूर कर सकता हूं
केस 4 से केस 2 तक सीमित करने से डिफ़ॉल्ट मान β₁ = 1 और β₂ = 1 (या वास्तव में true ) लगता है। लेकिन फिर, यदि न तो निर्दिष्ट किया गया है, तो इसका मतलब अचानक β₁ = β₂ = 0 ( false ) है। ज़रूर, वाक्यविन्यास थोड़ा अलग है, क्योंकि आप mul!(Y, args...) लिखते हैं, mul!((Y,), args...) । अंत में, यह दस्तावेज़ीकरण की बात है, इसलिए मैं इसे इंगित करना चाहता था।

इसलिए सारांश में, नहीं, मैं वास्तव में इस वाक्य-विन्यास का विरोध नहीं कर रहा हूं, हालांकि यह एक नए प्रकार का प्रतिमान है जिसे पेश किया जा रहा है, और फिर संभवतः अन्य स्थानों पर भी इसका पालन किया जाना चाहिए। जिस चीज का मैं विरोध कर रहा हूं, वह यह चाहती है कि मैट्रिक की एक मनमानी संख्या के गुणन के लिए इसे सामान्यीकृत किया जाए, जो, जैसा कि ऊपर तर्क दिया गया है, मुझे इसका लाभ नहीं दिखता है।

@dlfivefifty : लेकिन यह एपीआई की तुलना में कार्यान्वयन पर अधिक चर्चा है। लेकिन समूह की शर्तों के लिए टुपल्स का उपयोग करना गलत लगता है: क्या यह नहीं है कि किस प्रकार की प्रणाली है? जिस स्थिति में आप LazyArrays.jl समाधान पर पहुंचते हैं।

लेकिन हम यहाँ पूर्ण आलसी एरेज़ नहीं जा रहे हैं - इसके लिए पहले से ही LazyArrays है। इस बीच, हमें Y स्केलिंग व्यक्त करने के लिए किसी तरह की आवश्यकता है। Tuples का उपयोग संरचना की उस छोटी मात्रा को व्यक्त करने के लिए एक सरल, हल्के दृष्टिकोण की तरह लगता है। क्या किसी के पास कोई अन्य सुझाव है? हमारे पास lscale और / या rscale β₁ और β₂ लिए कीवर्ड हो सकते हैं, लेकिन ऐसा लगता नहीं है कि कोई और अधिक सुरुचिपूर्ण है और हम क्षमता खो देंगे उस पर प्रेषण, जो महत्वपूर्ण नहीं है, लेकिन अच्छा है।

@ जूथो : इसलिए, मैं mul! को वास्तव में एक आदिम संचालन के रूप में प्रतिबंधित करूंगा , जैसा कि mul! रैपर की कमी है।

मैं mul! लिए केवल संचालन के एक छोटे उपसमुच्चय को परिभाषित करने के साथ ठीक हूं, शायद यहां तक ​​कि उन लोगों के लिए भी जो संरचनात्मक रूप से मान्य BLAS कॉल के अनुरूप हैं। यह होगा:

# gemm: alpha = 1.0, beta = 0.0
mul!(Y::Matrix, A::Matrix, B::Matrix) # gemm! Y, A

# gemm: alpha = α, beta = 0.0 (these all do the same thing for BLAS types)
mul!(Y::Matrix, α::Number, A::Matrix, B::Matrix)
mul!(Y::Matrix, A::Matrix, α::Number, B::Matrix)
mul!(Y::Matrix, A::Matrix, B::Matrix, α::Number)

# gemm: alpha = α, beta = β (these all do the same thing for BLAS types)
mul!((β::Number, Y::Matrix), α::Number, A::Matrix, B::Matrix)
mul!((β::Number, Y::Matrix), A::Matrix, α::Number, B::Matrix)
mul!((β::Number, Y::Matrix), A::Matrix, B::Matrix, α::Number)
mul!((Y::Matrix, β::Number), α::Number, A::Matrix, B::Matrix)
mul!((Y::Matrix, β::Number), A::Matrix, α::Number, B::Matrix)
mul!((Y::Matrix, β::Number), A::Matrix, B::Matrix, α::Number)

# gemm: alpha = α, beta = β₁*β₂ (these all do the same thing for BLAS types)
mul!((β₁::Number, Y::Matrix, β₂::Number), α::Number, A::Matrix, B::Matrix)
mul!((β₁::Number, Y::Matrix, β₂::Number), A::Matrix, α::Number, B::Matrix)
mul!((β₁::Number, Y::Matrix, β₂::Number), A::Matrix, B::Matrix, α::Number)

किस हद तक? बीएलएएस संचालन को व्यक्त करने के तरीके में इतनी भिन्नता क्यों दें?

1. क्योंकि यह लोगों को अपने इरादे को व्यक्त करने की अनुमति देता है - यदि इरादा बाईं या दाईं ओर या दोनों को गुणा करना है, तो लोगों को इसे व्यक्त करने और सही कार्यान्वयन चुनने की अनुमति क्यों नहीं है?

2. हमारे पास सामान्य कमियां हो सकती हैं जो गैर-कम्यूटेटिव तत्व प्रकारों के लिए भी सही काम करती हैं।

इस मुद्दे का पूरा बिंदु इन-प्लेस मैट्रिक्स गुणन का सामान्यीकरण करना है जो जेम को सब्सक्राइब करता है! जेम से अधिक सामान्य होने के दौरान! अन्यथा, क्यों न केवल gemm! लिखना जारी रखें?

लेकिन हम यहाँ पूर्ण आलसी एरेज़ नहीं जा रहे हैं

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

materialize!(applied(+, applied(*, α, A, B), applied(*, β, C)))

यह चीनी की तरह प्रसारित किया जा सकता है जैसे प्रसारण के .* अंकन इसे और अधिक पठनीय बनाने के लिए, लेकिन मुझे लगता है कि यह तुरंत स्पष्ट है कि टुल्ल-आधारित प्रस्ताव के विपरीत क्या चाहिए।

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

mul!((β₁::Number, Y::Matrix, β₂::Number), α₁::Number, A::Matrix, α₂::Number, B::Matrix, α₃::Number)

और इसके सभी कम किए गए संस्करण, अर्थात यदि सभी 5 स्केलर तर्क अनुपस्थित हो सकते हैं, तो यह 2 ^ 5 = 32 विभिन्न संभावनाएं हैं। और यह अलग-अलग मैट्रिस या वैक्टर की सभी संभावनाओं के साथ संयुक्त है।

मैं @dlfivefifty से सहमत

हां, मैंने महसूस किया कि मैंने कुछ विकल्पों को छोड़ दिया है, लेकिन 32 विधियां मुझे वह सब पागल नहीं लगती हैं, आखिरकार हमें उन्हें हाथ से लिखना नहीं है। एक "ब्रॉडकास्ट-लाइक सिस्टम" या एक आलसी मूल्यांकन प्रणाली जो हमें materialize!(applied(+, applied(*, α, A, B), applied(*, β, C))) लिखने देता है, इस मुद्दे के लिए एक बड़े पैमाने पर जोड़ और दायरे से बाहर की तरह लगता है। हम चाहते हैं कि सामान्य मैट्रिक्स गुणन की वर्तनी का कुछ तरीका दोनों सामान्य हो और हमें BLAS को भेजने की अनुमति दे। यदि हम सभी इस पर सहमत नहीं हो सकते हैं तो मैं लोगों को gemm! सीधे कॉल करने देना चाहूंगा।

हाँ, यह शायद सच है; मैंने यह मान लिया कि स्केलर के तर्कों को पीछे छोड़ना आसान होगा, आसानी से चूक प्रदान करना। लेकिन अगर कुछ @eval metaprogramming के साथ हम आसानी से सभी 32 परिभाषाएँ उत्पन्न कर सकते हैं, तो यह उतना ही अच्छा है। (ध्यान दें, जैसा कि आप निश्चित रूप से जानते हैं, mul न केवल gemm! बल्कि gemv और trmm और ...) भी है।

मुझे जोड़ने दें कि यह सिर्फ एक BLAS आवरण नहीं है। Stdlib में अन्य शुद्ध-जूलिया विशेष तरीके हैं। इसके अलावा, यह अतिभारित एपीआई के रूप में होना महत्वपूर्ण है: पैकेज लेखक अपने विशेष मैट्रिक्स प्रकारों के लिए mul! परिभाषित कर सकते हैं।

मुझे लगता है कि यह मेरा रुख है:

1. जब से यह पहले से ही SparseArrays.jl में मौजूद है, हम mul!(C, A, B, a, b) समर्थन कर सकते हैं
2. हमें कुछ और नहीं करना चाहिए क्योंकि मैट्रिक्स प्रकारों पर डिस्पैच करना ठीक नहीं है। (BandedMatrices.jl, BlockArrays.jl, LowRankApprox.jl, आदि के अनुरक्षक के रूप में मैं अनुभव से यह कह सकता हूं।)
3. Trait आधारित डिज़ाइन अच्छी तरह से पैमाने पर है, लेकिन सभी में जाना और Applied जैसे प्रसारण करना सबसे अच्छा होगा, क्योंकि डिज़ाइन पैटर्न पहले से ही स्थापित है। इसके लिए जूलिया 2.0 का इंतजार करना होगा, एक प्रोटोटाइप के साथ LazyArrays.jl में विकसित किया जाना जारी रहेगा जो आपकी आवश्यकताओं के अनुरूप है।

@dlfivefifty क्या आपको लगता है की बहुविकल्पी में कठिनाई mul!((Y, β), α, A, B) एपीआई के रूप में बराबर है mul!(Y, A, B, α, β) ? मैट्रिक्स के रैपर को Transpose मानने से कठिनाई का परिचय होता है, जिसमें 2- और 3-टुपल्स भी शामिल हैं, जैसे कठिनाई को और अधिक बढ़ाना (हालाँकि मुझे पता है कि ट्यूल जूलिया के प्रकार प्रणाली में एक विशेष मामला है)।

1. जब से यह पहले से ही SparseArrays.jl में मौजूद है, हम mul!(C, A, B, a, b) समर्थन कर सकते हैं

तथ्य यह है कि किसी ने फैसला किया है कि mul!(C, A, B, a, b) का अर्थ C .= b*C + a*A*B mul!(C, A, B, a, b) होना चाहिए, बिना यह सोचे कि इस पर दोगुना करने का एक अच्छा कारण नहीं है। तो mul! की यथा-स्थान संस्करण है * तो मैं नहीं दिख रहा है कि कैसे mul!(out, args...) के अलावा कुछ भी मतलब हो सकता है out .= *(args...) । सच कहूँ तो, यह है कि आप एक प्रणाली के साथ समाप्त हो जाते हैं जो खराब तरीके से सोचा गया, असंगत एपीआई है जो केवल ऐतिहासिक दुर्घटना से मौजूद है। mul! फ़ंक्शन SparseArrays _and_ से निर्यात नहीं किया जाता है कि विशेष विधि का दस्तावेजीकरण नहीं किया गया है, इसलिए यह वास्तव में एक गैर-कल्पित विधि को लुभाने का सबसे संभव कारण है जो शायद केवल इसलिए जोड़ा गया क्योंकि फ़ंक्शन wasn 'टी पब्लिक! मेरा प्रस्ताव है कि हम उस गलती को पूर्ववत करें और इसके बजाय mul! की उस पद्धति को हटा दें।

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

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

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

विशेष रूप से, मुझे लगता है कि पैकेज डेवलपर्स को केवल लागू करने की आवश्यकता है:

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::MyMat, α₂, B:: MyVecOrMat, α₃)

और शायद, जैसे,

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::Adjoint{<:MyMat}, α₂, B:: MyVecOrMat, α₃)
...

जबकि जूलिया बेस (या बल्कि, रैखिकअलब्रे मानक पुस्तकालय) सभी चूक मूल्यों आदि से निपटने का ख्याल रखता है।

मुझे लगता है कि पैकेज डेवलपर्स को केवल लागू करने की आवश्यकता है:

mul!((β₁, Y::MyVecOrMat, β₂), α₁, A::MyMat, α₂, B:: MyVecOrMat, α₃)

मैं दस्तावेज देने का सुझाव दूंगा

mul!((Y, β), A, B, α)

अतिभारित होने के लिए हस्ताक्षर के रूप में। ऐसा इसलिए है क्योंकि α लिए अन्य स्थानों पर बड़ी O समय जटिलता बदल जाती है। देखें: https://github.com/JuliaLang/julia/pull/29634#issuecomment -443103667 यह गैर-कम्यूटेटिव संख्याओं को एक गैर-प्रथम श्रेणी का उपचार देता है। लेकिन AFAICT यहां कोई भी वास्तव में गैर-कम्यूटेटिव नंबरों का उपयोग नहीं कर रहा है और मुझे लगता है कि हमें तब तक इंतजार करना चाहिए जब तक कि वास्तविक जरूरत न हो।

एक बात जो मुझे @StefanKarpinski के दृष्टिकोण के बारे में पसंद है, वह यह है कि हम समय की जटिलता को बदलने के बिना A (जैसे, Adjoint{_,<:SparseMatrixCSC} ) के लिए mul!((Y, β), α::Diagonal, A, B) लिए विशेष पद्धति को लागू कर सकते हैं। । (यह मेरे आवेदन के लिए महत्वपूर्ण है।) बेशक, इस तरह से जाने के लिए विशेष रूप से विशेष विधि के अस्तित्व के लिए क्वेरी करने के लिए एपीआई में आगे की चर्चा की आवश्यकता होगी। फिर भी, एपीआई का विस्तार करने का अवसर महान है।

यदि कोई विधि अस्पष्टताओं के बारे में मेरी चिंता को स्पष्ट करता है तो मैं समूह-दर-चरण दृष्टिकोण के लिए रहूंगा।

ऐसा इसलिए है क्योंकि α के लिए अन्य स्थान बड़े ओ समय जटिलता को बदलते हैं।

क्या यह कुछ विशेष रूप से विरल मैट्रिक्स है? मैं काफी तर्क नहीं देता, विशेष रूप से घने मैट्रिस के लिए नहीं। आपके द्वारा लिंक किए गए कार्यान्वयन में, आप एक ऐसा मामला दिखाते हैं जहां α A और B ?

मुझे लगता है कि पैकेज डेवलपर्स को केवल लागू करने की आवश्यकता है ...

यह बहुत अधिक है। मान लें कि हमारे पास एक मैट्रिक्स है जो एक स्ट्रेंडेड मैट्रिक्स की तरह व्यवहार करता है, जैसे कि ब्लॉकअर्सेज.ज्ल से PseudoBlockMatrix । पूरी तरह से gemm! समर्थन करने के लिए हमें PseudoBlockMatrix प्रत्येक क्रमचय को ओवरराइड करने की आवश्यकता है (1) स्वयं के साथ, (2) StridedMatrix , (3) Adjoint स्वयं के , (4) Transpose s, (5) Adjoint का StridedMatrix , (6) Transpose s का StridedMatrix , और संभवतः अन्य। यह पहले से ही 6 ^ 3 = 216 अलग-अलग संयोजन है। फिर आप trmm! का समर्थन करना चाहते हैं और आपको UpperTriangular , UnitUpperTriangular , उनके पास, उनके स्थानान्तरण, और इसी तरह करना होगा। तब gsmm! Symmetric और Hermitian ।

लेकिन कई अनुप्रयोगों में हम सिर्फ मैट्रिस के साथ काम नहीं करना चाहते हैं, लेकिन उनके साक्षात्कार भी, विशेष रूप से ब्लॉक मैट्रिस के लिए जहां हम ब्लॉक के साथ काम करना चाहते हैं। अब हमें ऊपर दिए गए 6 संयोजनों के साथ अपने मैट्रिक्स के विचारों के प्रत्येक क्रम को जोड़ना होगा।

अब हमारे पास हजारों ओवरराइड हैं, जिसमें StridedMatrix , जो एक बहुत ही जटिल संघ प्रकार है। यह संकलक के लिए बहुत अधिक है, using समय सेकंड के बजाय मिनटों में ले जाता है।

इस बिंदु पर एक को पता चलता है कि मौजूदा mul! , और mul! के प्रस्तावित एक्सटेंशन को

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

@ डॉलिवेफिफ्टी , मैं केवल इस बात का जिक्र कर रहा था कि स्केलर के तर्क कैसे संभाले जाते हैं। विभिन्न प्रकार के मैट्रिक्स के साथ सभी जटिलताएं जो वर्तमान में mul!(C,A,B) लिए मौजूद हैं, निश्चित रूप से रहेगी।

ऐसा इसलिए है क्योंकि α के लिए अन्य स्थान बड़े ओ समय जटिलता को बदलते हैं।

क्या यह कुछ विशेष रूप से विरल मैट्रिक्स है? मैं काफी तर्क नहीं देता, विशेष रूप से घने मैट्रिस के लिए नहीं। आपके द्वारा लिंक किए गए कार्यान्वयन में, आप एक ऐसा मामला दिखाते हैं जहां α A और B ?

@ जूथो मुझे लगता है कि सामान्य तौर पर आप आंतरिक सबसे पाश स्थिति में α नहीं डाल सकते। उदाहरण के लिए, इस मामले में आप α₁*A*B*α₃ समर्थन कर सकते हैं लेकिन A*α₂*B

https://github.com/JuliaLang/julia/blob/11c5680d5620b0b64420055e8474a2b8cf757010/stdlib/LinearAlivebra/src/matmul.jl#L661 -L6701

मुझे लगता है कि कम से कम α₁ या α₂ α₁*A*α₂*B*α₃ होने के 1 होने के लिए बढ़ती हुई विषमता समय की जटिलता से बचना चाहिए।

@dlfivefifty लेकिन यहां तक ​​कि LazyArrays.jl को प्रेषण करने के लिए कुछ आदिम कार्यों की आवश्यकता है? मेरी समझ यह है कि यह "प्रेषण नरक" को हल करता है लेकिन गणना "गुठली" को लागू करने के लिए लोगों की संख्या में कमी नहीं करता है।

नहीं, वहाँ कोई "आदिम" नहीं है उसी तरह Broadcasted में "आदिम" नहीं है। लेकिन हाँ फिलहाल यह "कर्नेल" सवाल हल नहीं करता है। मुझे लगता है कि अगला कदम एक आलसी Applied प्रकार के साथ ApplyStyle । तब BLAS जैसे कार्यों को पहचानने के लिए MulAddStyle हो सकते थे, इस तरह से कि कोई फर्क नहीं पड़ता।

मैं materialize! या copyto! एक आदिम कहूंगा। कम से कम यह प्रसारण तंत्र के लिए बिल्डिंग ब्लॉक है। इसी तरह, मुझे लगता है कि LazyArrays.jl को कुछ बिंदुओं पर बाहरी पुस्तकालयों के लिए छोरों या ccall s के साथ अपने आलसी प्रतिनिधित्व को कम करना होगा? अगर ऐसे फंक्शन का नाम mul! हो तो बुरा होगा?

यह बहुत अधिक है। मान लीजिए कि हमारे पास एक मैट्रिक्स है जो एक ब्लॉक किए गए मैट्रिक्स की तरह व्यवहार करता है, जैसे कि ब्लॉकऑरेस.जेएल से PseudoBlockMatrix। पूरी तरह से रत्न का समर्थन करने के लिए! हमें (1) स्वयं, (2) स्ट्रैडममैट्रिक्स, (3) स्वयं के, (4) स्वयं के प्रस्तावों, (5) स्ट्रैडममेट्रिक्स, (6) स्ट्रैडममैट्रिक्स के प्रस्तावों, और संभवतः दूसरों के परिवर्तनों के साथ PseudoBlockMatrix के हर क्रमांक को ओवरराइड करने की आवश्यकता है। । यह पहले से ही 6 ^ 3 = 216 अलग-अलग संयोजन है। तब आप ट्रम का समर्थन करना चाहते हैं! और आपको अपरट्रैंगुलर, यूनिटअपपर ट्राइंगुलर, उनके एडजॉइंट्स, उनके ट्रांज़ोज़ और इसी तरह के काम करने होंगे। फिर gsmm! सममित और हर्मिटियन के साथ।
लेकिन कई अनुप्रयोगों में हम सिर्फ मैट्रिस के साथ काम नहीं करना चाहते हैं, लेकिन उनके साक्षात्कार भी, विशेष रूप से ब्लॉक मैट्रिस के लिए जहां हम ब्लॉक के साथ काम करना चाहते हैं। अब हमें ऊपर दिए गए 6 संयोजनों के साथ अपने मैट्रिक्स के विचारों के प्रत्येक क्रम को जोड़ना होगा।
अब हमारे पास हजारों ओवरराइड हैं, जिसमें स्ट्रेडमैटिक्स शामिल है, जो एक बहुत ही जटिल संघ प्रकार है। यह संकलक के लिए बहुत अधिक है, जिससे सेकंड के बजाय मिनट का उपयोग करने में समय लगता है।

मैं निश्चित रूप से सहमत हूं कि वर्तमान StridedArray प्रकार का संघ एक प्रमुख डिजाइन दोष है। मैंने कुछ बिंदु पर इसे ठीक करने के आपके प्रयास का समर्थन किया।

जब मैं सभी मैत्रियों में शामिल हो, तब केवल mul! लागू होने पर, मैं अपने कस्टम प्रकार (Abstract)StridedView को लागू करता हूं, जब भी ए, बी और सी के प्रकार में कुछ मिलावट होती है, मैं जूलिया आधार / रेखीयएब्लेज इसे संभालते हैं। बेशक, यह @strided मैक्रो वातावरण में उपयोग किया जाना है, जो सभी संभव बेस प्रकारों को StridedView प्रकार में परिवर्तित करने का प्रयास करता है। यहां, StridedView सब, समान (पैरामीट्रिक) प्रकार के साथ साक्षात्कार, प्रस्ताव और सहायक, और कुछ फेरबदल का प्रतिनिधित्व कर सकते हैं। कुल मिलाकर, पूर्ण गुणन कोड लगभग 100 लाइनें हैं:
https://github.com/Jutho/Strided.jl/blob/master/src/abbridstridedview.jl#L46 -L147
मूल जूलिया के मामले में BLAS लागू नहीं होने पर उस पैकेज द्वारा उपलब्ध कराए गए अधिक सामान्य mapreducedim! कार्यक्षमता का उपयोग करके लागू किया जाता है, और LinearAlgebra में एक से कम कुशल नहीं है; लेकिन यह भी बहुआयामी है।

मुझे लगता है कि कम से कम α₁ या α₂ α₁*A*α₂*B*α₃ में विषमतापूर्ण समय की जटिलता को बढ़ाने से बचने के लिए 1 होना चाहिए।

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

मुझे यकीन नहीं है कि हम 1 ( true ) द्वारा सभी गुणाओं को समाप्त करने के लिए निरंतर प्रसार पर भरोसा कर सकते हैं। उदाहरण के लिए, eltype Matrix हो सकता है। उस स्थिति में, मुझे लगता है कि true * x (जहां x::Matrix ) को x ढेर-आवंटित प्रति बनाना है। क्या जूलिया उसे खत्म करने के लिए कुछ जादू कर सकती है?

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

function simplemul!((β₁, Y, β₂), α₁, A, α₂, B, α₃)
    <strong i="7">@assert</strong> size(Y, 1) == size(A, 1)
    <strong i="8">@assert</strong> size(Y, 2) == size(B, 2)
    <strong i="9">@assert</strong> size(A, 2) == size(B, 1)
    <strong i="10">@inbounds</strong> for i in 1:size(A, 1), j = 1:size(B, 2)
        acc = zero(α₁ * A[i, 1] * α₂ * B[1, j] * α₃ +
                   α₁ * A[i, 1] * α₂ * B[1, j] * α₃)
        for k = 1:size(A, 2)
            acc += A[i, k] * α₂ * B[k, j]
        end
        Y[i, j] = α₁ * acc * α₃ + β₁ * Y[i, j] * β₂
    end
    return Y
end

function simplemul!((Y, β), A, B, α)
    <strong i="11">@assert</strong> size(Y, 1) == size(A, 1)
    <strong i="12">@assert</strong> size(Y, 2) == size(B, 2)
    <strong i="13">@assert</strong> size(A, 2) == size(B, 1)
    <strong i="14">@inbounds</strong> for i in 1:size(A, 1), j = 1:size(B, 2)
        acc = zero(A[i, 1] * B[1, j] * α +
                   A[i, 1] * B[1, j] * α)
        for k = 1:size(A, 2)
            acc += A[i, k] * B[k, j]
        end
        Y[i, j] = acc * α + Y[i, j] * β
    end
    return Y
end

fullmul!(Y, A, B) = simplemul!((false, Y, false), true, A, true, B, true)
minmul!(Y, A, B) = simplemul!((Y, false), A, B, true)

using LinearAlgebra
k = 50
n = 50
A = [randn(k, k) for _ in 1:n, _ in 1:n]
B = [randn(k, k) for _ in 1:n]
Y = [zeros(k, k) for _ in 1:n]
<strong i="15">@assert</strong> mul!(copy(Y), A, B) == fullmul!(copy(Y), A, B) == minmul!(copy(Y), A, B)

using BenchmarkTools
<strong i="16">@btime</strong> mul!($Y, $A, $B)     # 63.845 ms (10400 allocations: 99.74 MiB)
<strong i="17">@btime</strong> fullmul!($Y, $A, $B) # 80.963 ms (16501 allocations: 158.24 MiB)
<strong i="18">@btime</strong> minmul!($Y, $A, $B)  # 64.017 ms (10901 allocations: 104.53 MiB)

अच्छा बेंचमार्क। मैंने पहले ही ध्यान दिया था कि यह वास्तव में कुछ समान प्रयोगों द्वारा इन आवंटन को समाप्त नहीं करेगा। ऐसे मामलों के लिए, यह एक विशेष उद्देश्य One सिंगलटन प्रकार को परिभाषित करने के लिए उपयोगी हो सकता है, जो सिर्फ *(::One, x::Any) = x और *(x::Any, ::One) = x को परिभाषित करता है, और किसी भी उपयोगकर्ता प्रकार के बारे में अब कभी ज़रूरत नहीं है। तब डिफ़ॉल्ट मान, के लिए कम से कम α₂ , हो सकता है One() ।

आह, हाँ, यह चतुर है! मैंने पहले सोचा था कि अब मैं α₁ * A * α₂ * B * α₃ समर्थन करने के साथ ठीक था, लेकिन फिर मुझे लगता है कि मुझे एक और समस्या मिली: यह गणितीय रूप से अस्पष्ट है कि हमें क्या करना चाहिए जब (कहते हैं) A एक मैट्रिक्स से मैट्रिक्स है α₁ एक मैट्रिक्स है। यदि हम α स्थितियों में गैर-अदिश तर्कों का समर्थन करते हैं तो यह कोई समस्या नहीं होगी। हालांकि, Y .= β₁*Y*β₂ + *(args...) को mul!((β₁, Y, β₂), args...) के मानसिक मॉडल के रूप में पेश करना असंभव बनाता है। इसके अलावा, यह वास्तव में बहुत अच्छा होगा यदि विकर्ण मैट्रिसेस को α₁ या α₂ किया जा सकता है क्योंकि इसकी गणना कभी-कभी "मुफ्त में" (और अनुप्रयोगों में महत्वपूर्ण) की जा सकती है। मुझे लगता है कि दो मार्ग हैं:

(1) mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) साथ जाएं, लेकिन जब विधि को ओवरलोड कर रहे हैं, तो तर्क α और β Diagonal को स्वीकार करना चाहिए। कॉल पथ को परिभाषित करना आसान है ताकि अंत-उपयोगकर्ता कोड अभी भी स्केलर मानों के माध्यम से इसे लागू कर सके। लेकिन इसके लिए कुशलता से काम करने के लिए, Diagonal(fill(λ, n)) https://github.com/JuliaLang/julia/pull/30298#discussion_r239845163 का "O (1) संस्करण" कुशलतापूर्वक काम करने के लिए, LinearAlgebra में लागू किया जाना है। ध्यान दें कि स्केलर और विकर्ण α लिए कार्यान्वयन बहुत अलग नहीं हैं; अक्सर यह सिर्फ α और α.diag[i] स्वैप कर रहा है। इसलिए मुझे नहीं लगता कि यह पैकेज लेखकों के लिए बहुत अधिक बोझ है।

यह ऊपर उल्लिखित अस्पष्टता को हल करता है क्योंकि अब आप mul!(Y, α * I, A, B) तब कॉल कर सकते हैं जब A एक मैट्रिक्स-ऑफ-मैट्रिक्स है और α एक मैट्रिक्स है जिसे eltype रूप में माना जाना चाहिए A ।

(२) शायद उपरोक्त मार्ग (१) अभी भी जटिल है? यदि हां, तो अब के बजाय muladd! जाएं। यदि हम कभी भी mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) का समर्थन करना चाहते हैं, तो पिछड़े अनुकूलता को बनाए रखते हुए इसका पलायन मुश्किल नहीं है।

इस बिंदु पर मुझे आश्चर्य होगा कि क्या हमें सिर्फ एक बहुत ही प्रतिबंधित और विशिष्ट matmul!(C, A, B, α, β) नहीं होना चाहिए जो केवल इस सामान्य हस्ताक्षर के लिए काम करने के लिए परिभाषित किया गया है:

matmul!(
    C :: VecOrMatT,
    A :: Matrix{T},
    B :: VecOrMatT,
    α :: Union{Bool,T} = true,
    β :: Union{Bool,T} = false,
) where {
    T <: Number,
    VecOrMatT <: VecOrMat{T},
}

साथ ही, यह वास्तव में आश्चर्यजनक है कि इस हस्ताक्षर को लिखा और भेजा जा सकता है।

यह अनिवार्य रूप से मेरा सुझाव (2) है, है ना? (मुझे लगता है कि A :: Matrix{T} शाब्दिक अर्थ Core.Array{T,2} ; अन्यथा यह कमोबेश gemm! )

मैं एक अस्थायी समाधान के रूप में इससे खुश होऊंगा, और मेरे द्वारा बनाए गए पैकेजों में आंशिक रूप से इसका समर्थन कर सकता हूं (बकाया लक्षणों के कारण "आंशिक"), हालांकि यह मिश्रण में एक और नाम जोड़ता है: mul! , muladd! और अब matmul! ।

... किसी के लिए समय के बारे में "triage कहते हैं ..." पोस्ट नहीं है और इसे कॉल करें?

साथ ही, यह वास्तव में आश्चर्यजनक है कि इस हस्ताक्षर को लिखा और भेजा जा सकता है।

क्या यह तथ्य नहीं है कि आप केवल इस हस्ताक्षर को mul! विधि बनाने के लिए तर्क पर सटीक रूप से प्रेषण कर सकते हैं। इसके बाद कुछ और सामान्य समाधान के मामले में भी सफाई की जा सकती है।

यह mul! विधि है

अगर हम mul!(C, A, B, α, β) तो इसे mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) और समान रूप से अनुकूलता को तोड़ने के बिना इसे सामान्य बनाने का कोई तरीका नहीं है। (शायद यह एक "विशेषता" है क्योंकि हम इस चर्चा से हमेशा के लिए मुक्त हैं: मुस्कान :)।

इसके अलावा, मुझे ध्यान दें कि तत्व प्रकार Number _and_ को वर्तमान 3-arg mul! (जो पहले से ही गैर- Number तत्व प्रकार का समर्थन करता है) के साथ संगतता को बनाए रखने के लिए बहुत कुछ पेश करेगा दोहराव का।

मुझे नहीं पता कि आप mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) क्या करने की उम्मीद करेंगे ... इसलिए मुझे लगता है कि यह एक विशेषता है।

टक्कर। बेहतर प्रदर्शन करने के लिए हर जगह BLAS फ़ंक्शंस का उपयोग करना मुझे दुखी करता है।

@StefanKarpinski क्या आप इसे यात्रा में ला सकते हैं?

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

मुझे लगता है कि सर्वसम्मति की कमी का मतलब यह है कि स्टैडलिब में इसे शामिल करने का सही समय नहीं है।

क्यों नहीं सिर्फ एक पैकेज MatMul.jl जो उन सुझावों में से एक को लागू करता है जो उपयोगकर्ताओं द्वारा उपयोग किए जा सकते हैं? मैं यह नहीं देखता कि StdLib में होना व्यवहार में महत्वपूर्ण क्यों है। मैं उन पैकेजों में खुशी से समर्थन करूंगा जिन्हें मैं बनाए रखता हूं।

मैं मणि का सिर्फ एक अच्छा जूलियन संस्करण सोच रहा हूँ! और रत्न! SparseArrays में जो हमारे पास है, उसका मिलान करना। प्रति @andreasnoack ऊपर:

मैंने सोचा था कि हम पहले से ही α , β लिए डिफ़ॉल्ट मानों के साथ mul!(C, A, B, α, β) पर बस गए। हम इस संस्करण का उपयोग कर रहे हैं

जूलिया / stdlib / SparseArrays / src / linalg.jl

बी 32 ए 4 में 32 से 50 तक

...
मुझे लगता है कि कुछ पैकेज भी इस फॉर्म का उपयोग कर रहे हैं, लेकिन मुझे याद नहीं है कि मेरे सिर के ऊपर कौन सा है।

उस सुझाव में 7 अंगूठे थे और कोई अंगूठे नीचे नहीं था। हम घने वैक्टर / मेट्रिसेस के लिए उस फ़ंक्शन को लागू क्यों नहीं करते हैं? यह एक सरल समाधान होगा जो सबसे आम उपयोग के मामले को सही तरीके से कवर करता है?

ठीक। इसलिए मुझे लगता है कि अगर आम सहमति नहीं है तो भी आम सहमति नहीं है: पसीना_सामने:

_I_ ने सोचा कि बहुत ज्यादा हर कोई [*] इस एपीआई को चाहता था और यह केवल फ़ंक्शन नाम और हस्ताक्षर की बात है। _Not_ के पास इस API की तुलना में, मुझे लगा कि हर कोई किसी भी विकल्प से खुश है ( mul!((β₁, Y, β₂), α₁, A, α₂, B, α₃) , muladd!(C, A, B, α, β) , और mul!(C, A, B, α, β) )। जब तक कोई व्यक्ति यह तर्क नहीं दे सकता कि एक निश्चित एपीआई _not_ के होने से बहुत खराब है, मैं जो कुछ भी निर्णय लेता है, उससे खुश रहूंगा।

@StefanKarpinski लेकिन अगर आपको लगता है कि चर्चा अभी तक समेकित नहीं हुई है, तो कृपया triage टैग को हटाने के लिए स्वतंत्र महसूस करें।

[*] ठीक है, @dlfivefifty , मुझे लगता है कि आप वर्तमान 3-arg mul! बारे में भी संदिग्ध हैं। लेकिन इसके लिए स्क्रैच से 3-arg mul! इंटरफ़ेस बदलने की आवश्यकता होगी, इसलिए मैंने सोचा कि इस चर्चा के दायरे से परे एक तरीका है (जो, मैं _adding_ के बारे में 5-arg वेरिएंट के कुछ रूप की व्याख्या कर रहा हूं)। मुझे लगता है कि हमें कुछ ऐसा चाहिए, जो LazyArrays.jl परिपक्व होने तक "पर्याप्त" काम करे।

क्यों नहीं सिर्फ एक पैकेज MatMul.jl जो उन सुझावों में से एक को लागू करता है जो उपयोगकर्ताओं द्वारा उपयोग किए जा सकते हैं?

@dlfivefifty मुझे लगता है कि LinearAlgebra.jl में यह महत्वपूर्ण है क्योंकि यह एक इंटरफ़ेस फ़ंक्शन (अधिभार एपीआई) है। इसके अतिरिक्त, क्योंकि mul!(C::AbstractMatrix, A::AbstractVecOrMat, B::AbstractVecOrMat) LinearAlgebra.jl में कार्यान्वित किया जाता है, हम नहीं परिभाषित करने के लिए सक्षम हो जाएगा mul! के मामले में MatMul.muladd! । बेशक कुछ वर्कअराउंड हैं, लेकिन यह एक सरल कार्यान्वयन के लिए बहुत अच्छा है, खासकर यह देखते हुए कि इसे "केवल" नाम और हस्ताक्षर तय करने की आवश्यकता है।

हम घने वैक्टर / मेट्रिसेस के लिए उस फ़ंक्शन को लागू क्यों नहीं करते हैं?

@chriscoey दुर्भाग्य से यह सभी के लिए पसंदीदा नहीं है: https://github.com/JuliaLang/julia/issues/23919#issuecomment -441717678। इसके और अन्य विकल्पों के लिए मेरा सारांश और अन्य विकल्प https://github.com/JuliaLang/julia/issues/23919#issuecomment -441865841 पर मेरा सारांश है। (अन्य लोगों की टिप्पणियाँ भी देखें)

ट्राइएज से: जेनेरिक टेंसर कॉन्ट्रिब्यूशन API की लॉन्ग टर्म प्लानिंग होती है, जिसमें कंपाइलर सपोर्ट और BLAS सेलेक्शन शामिल हैं, लेकिन मीडियम टर्म के लिए, जो भी API आपकी तत्काल जरूरत का पता करता है, उसे चुनें। यदि यह BLAS से मेल खाता है, तो BLAS नाम चुनना उचित लगता है।

@ केनो , कोई भी जानकारी जो आप सामान्य टेंसर संकुचन एपीआई और संकलक समर्थन के बारे में साझा कर सकते हैं? मेरे पास साझा करने के लिए कुछ दिलचस्प जानकारी हो सकती है, हालांकि सार्वजनिक (अभी तक) नहीं।

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

यदि यह BLAS से मेल खाता है, तो BLAS नाम चुनना उचित लगता है।

जेनेरिक रैखिक बीजगणित फ़ंक्शन नामों के लिए हम अब तक जो कर रहे हैं, यह पूरी तरह से विपरीत है।

क्या मजबूत / कमजोर के लिए योजना है β == 0 के प्रस्तावित सामान्य संस्करण में BLAS.gemm!(α, A, B, β, C) ?

अगर हम BLAS करते हैं तो यह एक मजबूत शून्य की तरह व्यवहार करेगा, भले ही यह अब lmul! साथ असंगत हो। मैं generic_muladd! β == 0 वापस गिरने के अलावा इसके समाधान के बारे में नहीं सोच सकता।

मजबूत / कमजोर 0 == 0 के लिए क्या योजना है

यह केवल https://github.com/JuliaLang/julia/issues/23919#issuecomment -430139849 में मेरी टिप्पणी के बारे में संक्षेप में चर्चा की गई थी, इसलिए शायद उस प्रश्न को संबोधित नहीं किया।

@Keno हालाँकि अभी तक कोई API डिज़ाइन नहीं हुआ है, लेकिन क्या आप यह कल्पना करते हैं कि "कंपाइलर समर्थन और BLAS के लिए चयन सहित API" को म्यूटिंग के रूप में परिभाषित किया जाएगा या यह XLA रैखिक बीजगणित की तरह अपरिवर्तनीय होगा, ताकि मदद करने के लिए संकलक? Ie क्या आपको लगता है कि mul! और / या muladd! ऐसे API का हिस्सा होंगे?

@andreasnoack 'के लिए पिंग @Keno में सवाल है https://github.com/JuliaLang/julia/issues/23919#issuecomment -+४७,५५,३४,४५४

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

यदि यह BLAS से मेल खाता है, तो BLAS नाम चुनना उचित लगता है।

जैसा कि @andreasnoack ने बताया, हम gemm! ( gemm! उपयोग नहीं कर सकते क्योंकि हम मैट्रिक्स-वेक्टर गुणन आदि का समर्थन करना चाहते हैं, लेकिन मुझे लगता है कि हम इस ट्राइएज निर्णय को अनदेखा कर सकते हैं (जो सिर्फ इतना कहता है कि "यदि यह BLAS से मेल खाता है" यह नहीं है)।

जो भी एपीआई आपकी तत्काल जरूरत को संबोधित करता है, बस उसे चुनें।

इसलिए, मुझे लगता है कि हम इस दिशा का अनुसरण कर सकते हैं। मुझे लगता है कि यह @StefanKarpinski द्वारा सुझाए गए टपल-आधारित एपीआई के बारे में भूल जाने का mul! muladd! addmul! muladd! mul! ।

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

कोई भी विचार mul! / muladd! / addmul! कैसे चुना जाए?

@chriscoey मुझे लगता है कि भविष्य के एपीआई पर चर्चा करना बेहतर है। यह मुद्दा पहले से ही सुपर लंबा है और हम तब तक कोई प्रगति नहीं कर पाएंगे जब तक कि हम मध्यावधि समाधान पर ध्यान केंद्रित नहीं करते। कैसे एक नया मुद्दा (या प्रवचन धागा) खोलने के बारे में?

मेरा सुझाव है कि अब से 10 दिनों की समयसीमा के साथ अनुमोदन मतदान का एक दौर। स्वीकृति मतदान का अर्थ है: सभी लोग उन सभी विकल्पों के लिए मतदान करते हैं जिन्हें वे चर्चा जारी रखने के लिए बेहतर मानते हैं। लोग, जो निरंतर चर्चा के बजाय अब अपना कम से कम पसंदीदा नाम रखना चाहते हैं, को तीनों को वोट देना चाहिए। यदि कोई विकल्प व्यापक स्वीकृति प्राप्त नहीं करता है, या मतदान योजना स्वयं व्यापक अनुमोदन को पूरा करने में विफल रहती है, तो हमें चर्चा जारी रखनी चाहिए। स्वीकृत विकल्पों के बीच लगभग संबंधों के मामले में, @tkf को निर्णय लेना है (PR लेखक का विशेषाधिकार)।

+1: मैं इस मतदान योजना से सहमत हूं और अपने अनुमोदन के वोट डाले हैं।
-1: मैं इस मतदान योजना से असहमत हूं। यदि बहुत अधिक या बहुत महत्वपूर्ण लोग इस विकल्प का चयन करते हैं, तो वोट मूक है।

दिल: mul! निरंतर चर्चा के लिए बेहतर है।
रॉकेट: muladd! निरंतर चर्चा के लिए बेहतर है।
हुर्रे: addmul! निरंतर चर्चा के लिए बेहतर है।

मैं अस्थायी रूप से सुझाव देता हूं कि 75% अनुमोदन और 5 को निश्चित रूप से एक कोरम (यानी 75% लोगों को वोट देना चाहिए, जिसमें संपूर्ण मतदान प्रक्रिया से असहमति शामिल है, और कम से कम 5 लोगों ने जीतने के विकल्प को मंजूरी दी है; यदि भागीदारी कम है; , तो 5/6 या 6/8 कोरम बनाते हैं लेकिन सर्वसम्मति से 4/4 को असफल माना जा सकता है)।

1.3 के लिए फ़ीचर फ्रीज 15 अगस्त के आसपास है: https://discourse.julialang.org/t/release-1-3-branch-date-approaching-aug-15/27233?u=chriscoey। मुझे आशा है कि हम इसे तब तक विलय कर सकते हैं it उन सभी को धन्यवाद जिन्होंने पहले ही मतदान किया है!

हमें अभी भी β == 0 https://github.com/JuliaLang/julia/issues/23919#issuecomment -475420149 का व्यवहार तय करने की आवश्यकता है जो नाम तय करने के लिए ऑर्थोगोनल है। इसके अलावा, मेरे पीआर में मर्ज संघर्ष को हल किया जाना है और पीआर को कार्यान्वयन विवरण पर कुछ समीक्षा की आवश्यकता है (उदाहरण के लिए, मैंने वहां उपयोग किया था जो गंतव्य सरणी में undef s को संभालने के लिए उपयोग किया गया था)। हम समीक्षा के दौरान अन्य मुद्दों की खोज कर सकते हैं। इसलिए, मुझे यकीन नहीं है कि यह 1.3 में मिल सकता है ...।

पुन :: β == 0 , मुझे लगता है कि @andreasnoack की टिप्पणी https://github.com/JuliaLang/julia/issues/23919#issuecomment -430139849 (मेरा सारांश: β == 0 -हंडलिंग BLAS होनी चाहिए जितना संभव हो उतना BLAS का लाभ उठाने के लिए असंगत) समझ में आता है। नीचे दिए गए @simonbyrne के तर्क के अलावा अन्य विचारों का विरोध करना मुश्किल है ("हर कार्यान्वयन को शून्य की जांच के लिए एक शाखा की आवश्यकता होगी")। क्या BLAS जैसे β == 0 हैंडलिंग के खिलाफ कोई अन्य तर्क हैं?

@simonbyrne आपकी टिप्पणी के बारे में https://github.com/JuliaLang/julia/issues/23919#issuecomment -430375349, मुझे नहीं लगता कि स्पष्ट ब्रांचिंग एक बड़ा मुद्दा है क्योंकि यह ज्यादातर केवल β != 0 ? rmul!(C, β) : fill!(C, zero(eltype(C))) । इसके अलावा, बहुत ही सामान्य कार्यान्वयन के लिए, जहाँ आपको संभालने की आवश्यकता है, जैसे, C = Matrix{Any}(undef, 2, 2) , वैसे भी कार्यान्वयन के लिए स्पष्ट रूप से "मजबूत शून्य" से निपटने की आवश्यकता होती है (मेरे PR https में सहायक फ़ंक्शन _modify! : // github .com / JuliaLang / जूलिया / पुल / 29,634 / फ़ाइलें # diff-e5541a621163d78812e05b4ec9c33ef4R37)। इसलिए, मुझे लगता है कि BLAS जैसी हैंडलिंग यहां सबसे अच्छा विकल्प है। तुम क्या सोचते हो?

क्या उच्च प्रदर्शन कमजोर शून्य होना संभव है? इस अर्थ में कि हम चाहेंगे:

julia> A = [NaN 0;
                     1 0]

julia> b = [0.0,0];

julia> 0.0*A*b
2-element Array{Float64,1}:
 NaN  
   0.0

julia> false*A*b
2-element Array{Float64,1}:
 0.0
 0.0

यही है, अगर हम BLAS को कम करते हैं (जो मजबूत 0 का उपयोग करता है), तो हमें मैन्युअल रूप से यह निर्धारित करने की आवश्यकता होगी कि कौन सी पंक्तियाँ NaN ।

@dlfivefifty मुझे लगता है कि A और B में NaN को संभाल सकता है, लेकिन C ?

मुझे लगता है कि NaN- अवगत _C = α * A * B + 0 * C_ कुशलतापूर्वक BLAS.gemm! आदि [1] का उपयोग करने का कोई तरीका नहीं है और यही @andreasnoack का तर्क है।

[१] आपको isnan.(C) कहीं बचाने की जरूरत है और " C "

@ चेतहेगा को वोट दिए 10 दिन से ज्यादा हो चुके हैं

@chriscoey आप सही हैं, मतदान बंद है।

मैं उन लोगों की पूरी सूची प्राप्त करने के लिए बहुत बुरा हूं, जिन्होंने मतदान किया था (यह गणना करने के लिए आवश्यक होगा कि कितने लोग किसी भी तरह के वोट डालते हैं)। हालांकि, जब मैं संख्याओं पर नजर रखता हूं, तो यह काफी स्पष्ट दिखाई देता है कि mul! का भारी समर्थन है (शायद 75% अनुमोदन कोरम का प्रबंधन), और दूसरा दावेदार muladd! 50% से काफी नीचे है।

मतदान योजना में एक भी आपत्ति नहीं थी। मैं वोट को कॉल करता हूं, mul! जीता है, और नाम तय किया गया है। @tkf इसे उड़ाने पर जा सकता है :)

@ चेतेगा धन्यवाद, यह तय करने के लिए यह एक अच्छी योजना थी!

BTW, मैं तुरंत रिबास नहीं कर सकता (लेकिन शायद कुछ हफ्तों के भीतर) तो अगर कोई रिबेस या रीइम्प्लीमेंट करना चाहता है तो कृपया मेरा इंतजार न करें।

दुर्भाग्य से, हमारे पास NaN- शब्दार्थ पर एक वोट नहीं था। फ़ीचर फ़्रीज़ अगले सप्ताह है, और हमारे पास सार्थक वोट के लिए पर्याप्त समय नहीं है।

मेरा प्रस्ताव है कि हमारे पास एक गैर-बाध्यकारी जनमत संग्रह है जो धागे में मूड का एक स्नैपशॉट एकत्र करता है।

मुझे निम्नलिखित विकल्प दिखाई देते हैं:

1. चर्चा जारी रखें, आशा है कि आम सहमति किसी तरह समय सीमा से पहले पहुंच जाती है, या मुख्य लोग हमें एक एक्सटेंशन, या कुछ और देते हैं। : टाडा: (स्पष्टीकरण के लिए संपादित करें: यह डिफ़ॉल्ट विकल्प है, अर्थात यदि हम किसी भिन्न विकल्प पर सर्वसम्मति तक नहीं पहुंच सकते हैं, तो सबसे अधिक संभावित परिणाम यह है कि 5-arg mul! 1.4 तक देरी हो जाती है।)
2. बैकस्टॉप के रूप में अपरिभाषित NaN- व्यवहार के साथ नई सुविधा को मर्ज करें। जैसे ही हम आम सहमति पर पहुंचते हैं, हम निर्धारित NaN व्यवहार (मजबूत बनाम कमजोर शून्य) प्राप्त करने के लिए कोड और / या डॉक्स अपडेट करते हैं। अपरिभाषित कार्यान्वयन-परिभाषित NaN- व्यवहार का बैकस्टॉप अनिश्चितकाल तक समाप्त हो सकता है, लेकिन आज मतदान के लिए नहीं है। (जो भी सबसे तेज़ है उसे लागू करें; जो उपयोगकर्ता देखभाल करते हैं उन्हें विभिन्न तरीकों को कॉल करने की आवश्यकता होती है)। :थम्स अप:
3. जेम का मतलब जेम! मजबूत शून्य के लिए प्रलेखित प्रतिबद्धता के साथ 1.3 के लिए मर्ज करें। :दिल:
4. NaN अर्थ NaN ! कमजोर शून्य के लिए प्रलेखित प्रतिबद्धता के साथ 1.3 के लिए विलय। :आंखें:
5. 1.3 चट्टान से टकराने से पहले, बस कुछ भी करो। : रॉकेट:
6. जनमत को खारिज करें। :नाकामयाबी:
7. में लिखना
8. प्रस्तावित downthread : वैकल्पिक backstop व्यवस्था। जल्दी से विलय करने की कोशिश करें, और कमजोर / मजबूत शून्य विचलन को 1.3-अल्फा के लिए त्रुटि दें, जब तक कि हम बाद में एक अधिक विचार किए गए निर्णय तक नहीं पहुंच सकते। यही है, हम !(alpha === false) && iszero(alpha) && !all(isfinite, C) && throw(ArgumentError()) साथ विलय करते हैं, और इस त्रुटि की जाँच करें कि कुछ और के पक्ष में सेवानिवृत्त होने की संभावना है। : भ्रमित:

संभवतः कई विरोधाभासी विकल्पों का चयन करने के लिए स्वतंत्र महसूस करें, और @tkf / triage संभावित रूप से मतदान की उपेक्षा करने के लिए स्वतंत्र महसूस करें।

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

मैं मजबूत शून्य (: दिल :) के लिए मतदान करूंगा, अगर यह "मर्ज 1.x" के बजाय "मर्ज फॉर 1.3" था। यदि विकल्प "1.3 के लिए मर्ज" "1.x मर्ज" कर रहे हैं, तो समझ में नहीं आएगा?

धन्यवाद @ चचेता @tkf मैं वास्तव में नए मूल की जरूरत की स्थिति में हूँ! ASN NaN निर्णय के बारे में बहुत अधिक परवाह किए बिना (जब तक प्रदर्शन समझौता नहीं किया जाता है)।

क्या आपने LazyArrays.jl की जांच की? FYI करें, यह वास्तव में अच्छा फ्यूज्ड मैट्रिक्स गुणन समर्थन है। आप सार्वजनिक रूप से https://docs.julialang.org/en/latest/stdlib/LinearAlgebra/#LinearAlgebra/BLAS.gemm! के बाद से BLAS.gemm! आदि का सुरक्षित रूप से उपयोग कर सकते हैं ।

मैं वास्तव में जेनेरिक मूल की जरूरत है! चूंकि हम विभिन्न अनुकूलन समस्याओं का सबसे कुशलता से प्रतिनिधित्व करने के लिए कई प्रकार के संरचित और विरल और सादे पुराने घने मैट्रेस का उपयोग करते हैं। मैं यहाँ की उदारता और गति के लिए हूँ।

समझा। और मुझे सिर्फ इतना याद है कि हमने LazyArrays.jl में चीजों पर चर्चा की है, तो बेशक आप पहले से ही इसे जानते थे ...

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

संपादित करें: रिलीज़ -> मर्ज करें

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

यह बहुत अच्छा है कि आप सक्रिय रूप से इस धागे को ऊर्जा इंजेक्ट कर रहे हैं!

मैं वास्तव में जेनेरिक मूल की जरूरत है! चूंकि हम विभिन्न अनुकूलन समस्याओं का सबसे कुशलता से प्रतिनिधित्व करने के लिए कई प्रकार के संरचित और विरल और सादे पुराने घने मैट्रेस का उपयोग करते हैं। मैं यहाँ की उदारता और गति के लिए हूँ।

5-तर्क mul! कई अलग-अलग प्रकारों के होने पर आप अच्छी तरह से काम नहीं करेंगे: अस्पष्टता से बचने के लिए आपको जुझारूपन की आवश्यकता होगी। यह LazyArrays.jl MemoryLayout प्रणाली के पीछे की प्रेरणाओं में से एक है। यह BandedMatrices.jl और BlockBandedMatrices.jl में इस कारण से "संरचित और विरल" मेट्रिक्स के लिए उपयोग किया जाता है। (यहां तक ​​कि बैंडेड मैट्रिस के उप-दृश्य बैंडेड बीएलएएस रूटीनों को भेजते हैं।)

धन्यवाद, मैं फिर से LazyArrays की कोशिश करूंगा।

चूंकि 5-arg mul को आम तौर पर एक अस्थायी स्टॉपगैप माना जाता है (जब तक कि 2.0 में LazyArrays जैसे कुछ समाधान का उपयोग नहीं किया जा सकता है), मुझे लगता है कि हम इसे लंबे समय तक चलने के लिए आदर्श या सही समाधान के बिना विलय करने का लक्ष्य बना सकते हैं।

@ चेतहेगा जब आपको लगता है कि हमें नए नॉनबाइंडिंग वोट के लिए

@tkf ज़रूर, आप सही कह रहे हैं कि मज़बूत / कमज़ोर / अशक्त शून्य 1.x के लिए भी मायने रखता है।

हालाँकि, मुझे लगता है कि ऐसे बहुत से लोग हैं जो अब mul! 1.3 mul! मिलेगा। यदि कोई समय सीमा नहीं थी, तो मैं कुछ और इंतजार करूँगा और उचित मतदान (कम से कम 10 दिन मतदान के लिए) करने के बारे में सोचने के लिए कुछ और समय लूंगा। सबसे महत्वपूर्ण बात, हम कमजोर / मजबूत शून्य की गति और शान पर पहले प्रस्तुतिकरण और बेंचमार्किंग प्रतिस्पर्धा कार्यान्वयन के बिना एक सार्थक वोट नहीं कर सकते। मुझे व्यक्तिगत रूप से संदेह है कि कमजोर शून्य लगभग iszero(alpha) जितनी तेजी से मजबूत किया जा सकता है, पहले !isfinite मानों के लिए मैट्रिक्स को स्कैन करना, और उसके बाद ही अतिरिक्त आवंटन के साथ धीमी गति का उपयोग करना; लेकिन मैं वैसे भी मजबूत शून्य शब्दार्थ पसंद करता हूं।

@ चेतहेगा जब आपको लगता है कि हमें नए नॉनबाइंडिंग वोट के लिए

ट्राइएज को इस सप्ताह 1.3 अल्फा के लिए एक निर्णय (देरी / मजबूत / कमजोर / बैकस्टॉप) करना चाहिए। मुझे लगता है कि गुरुवार 15 वीं या बुधवार 14 वीं गणना के लिए ट्राइएज के समझदार विकल्प हैं, और इसे ध्यान में रखें। मैं शायद गुरुवार को शामिल नहीं हो पाऊंगा, इसलिए किसी और को गिनना होगा।

वास्तविक रूप से, यहां रूढ़िवादी होना ठीक है, और समय सीमा याद आती है, और चर्चा जारी रखें और 1.4 की प्रतीक्षा करें।

दूसरी ओर, हम पहले से ही इसे स्वीकार किए बिना सर्वसम्मति तक पहुंच सकते हैं:

अभी के लिए एक त्रुटि क्यों नहीं फेंकें:

β == 0.0 && any(isnan,C) && throw(ArgumentError("use β = false"))

अभी के लिए एक त्रुटि क्यों नहीं फेंक दिया

मैंने उस विकल्प को पोल में जोड़ा। महान समझौता विचार!

बस उम्मीदें सेट करने के लिए: 1.3 के लिए सुविधा फ्रीज तीन दिनों में है, इसलिए मूल रूप से कोई रास्ता नहीं है जिससे यह समय में बना सके। हम फ़ीचर फ़्रीज़ और ब्रांचिंग के बारे में बहुत सख्त हैं क्योंकि यह रिलीज़ चक्र का एकमात्र हिस्सा है जिससे हम वास्तव में समय को नियंत्रित कर सकते हैं।

काम पहले से ही https://github.com/JuliaLang/julia/pull/29634 में किया गया है। बस जरूरत है समायोजित और विद्रोह की।

# 29634 के लिए @tkf क्या आप उस कार्य को सूचीबद्ध कर सकते हैं जो किया जाना बाकी है (वोट के अनुसार शून्य का नामकरण और संभालना)? मुझे पता है कि आप व्यस्त हैं इसलिए शायद हम किसी भी शेष टोड को विभाजित करने का एक तरीका ढूंढ सकते हैं ताकि बोझ फिर से आप पर न पड़े।

एटीएम के बारे में मैं सोच सकता हूं:

• रिबेस
• addmul! -> mul! नाम बदलें
  
  
  
  • और यह मानते हुए कि नए API को mul! API <strong i="15">@deprecate</strong> mul!(C, A, B, α, β) addmul!(C, A, B, α, β) ) नहीं कहा जाएगा समायोजित करें
  
  
• MulAddMul आदि के कार्यान्वयन की रणनीति के बारे में कोर देव से ठीक हो; https://github.com/JuliaLang/julia/pull/29634#issuecomment -440510551 देखें। @andreasnoack , क्या आपके पास इसे देखने का मौका था?
• आदर्श रूप से Quaternion का उपयोग करके परीक्षण जोड़ें; देखें https://github.com/JuliaLang/julia/pull/29634#issuecomment -443333999914

मेरा पीआर β = 0 हैंडलिंग के BLAS शब्दार्थों को लागू करता है। तो अन्य हैंडलिंग, जैसे कि एक त्रुटि को फेंकना, भी लागू करना होगा।

मेरा पीआर β = 0 हैंडलिंग के BLAS शब्दार्थों को लागू करता है।

क्षमा करें, मेरी स्मृति बासी थी; मेरा कार्यान्वयन सुसंगत नहीं था और NaN _sometimes_ का प्रचार करता था। तो अतिरिक्त TODO β = 0.0 अनुरूप व्यवहार करना है।

MulAddMul प्रकार केवल आंतरिक उपयोग के लिए होगा, है ना?

हां, यह पूरी तरह से एक आंतरिक विवरण है। मेरी चिंताएं थीं (1) बहुत अधिक विशेषज्ञता हो सकती है (बीटा = 0 आदि प्रकार पैरामीटर में एन्कोडेड है) और (2) यह स्रोत कोड की पठनीयता कम हो जाती है।

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

FYI करें नरम शून्य में सरल कार्यान्वयन हैं:

if iszero(β) && β !== false && !iszero(α)
   lmul!(zero(T),y) # this handles soft zeros correctly
   BLAS.gemv!(α, A, x, one(T), y) # preserves soft zeros
elseif iszero(α) && iszero(β)
   BLAS.gemv!(one(T), A, x, one(T), y) # puts NaNs in the correct place
   lmul!(zero(T), y) # everything not NaN should be zero
elseif iszero(α) && !iszero(β)
   BLAS.gemv!(one(T), A, x, β, y) # puts NaNs in the correct place
   BLAS.gemv!(-one(T), A, x, one(T), y) # subtracts out non-NaN changes
end

@andreasnoack क्षमा करें, मैं भूल गया कि हमें वास्तव में mul!(C, A::BiTriSym, B, α, β) https://github.com/JuliaLang/julia/pull/29634#issuecomomment -440510551 जैसे कुछ संरचित मैट्रिसेस के लिए इनर-मोस्ट लूप को अनुकूलित करने के लिए विशेषज्ञता की आवश्यकता थी। कुछ विशेषज्ञताओं को हटाया जा सकता है लेकिन यह वास्तव में अधिक काम है (इसलिए देरी)।

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

महान!

Https://github.com/JuliaLang/julia/pull/29634 द्वारा निर्धारित

@andreasnoack इस समय की समीक्षा और विलय के लिए बहुत बहुत धन्यवाद!

अब जब इसे १.३ के लिए विलय कर दिया गया है, तो यह मुझे कार्यान्वयन के बारे में बहुत परेशान करता है: मुस्कान:। मैं सराहना करता हूं कि अगर 1.3-आरसी निकलता है तो यहां के लोग अपने रैखिक बीजगणित कोड का अधिक अच्छी तरह से परीक्षण कर सकते हैं!

चिंता करने की ज़रूरत नहीं है, कीड़े को बाहर निकालने के लिए 1.3 आरसी + पीकेएवल के लिए बहुत समय होगा।