Julia: बेस में आंतरिक उत्पादों की स्थिति

क्या आप अपने उपयोग के मामले के बारे में कुछ और बता सकते हैं और इसे अपने पैकेज में परिभाषित करने के बजाय इसे बेस में रखना फायदेमंद क्यों है? एक ठोस उदाहरण सबसे अच्छा होगा। क्या आप एक साथ लोड किए गए पैकेजों में कई inner परिभाषाओं की अपेक्षा करते हैं?

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

एक ठोस उदाहरण के रूप में, मैं आज इस सीमा के पार आया, जो कि कंपोजिटल डेटा के लिए एक ज्यामिति को परिभाषित करने की कोशिश कर रहा था: https://github.com/juliohm/CoDa.jl मैं इसके बजाय एक प्रसिद्ध inner फ़ंक्शन पर विशेषज्ञ होना चाहता हूं मेरे अपने इंटरफ़ेस को परिभाषित करने के बजाय बेस में परिभाषित किया गया है कि किसी और को इसके बारे में पता नहीं होगा।

अपने हिल्बर्ट अंतरिक्ष प्रकारों के लिए dot का विस्तार क्यों न करें? मुझे पूरा यकीन है कि इसे सामान्य आंतरिक उत्पाद को ध्यान में रखकर बनाया गया है।

आंतरिक उत्पाद की अवधारणा की तुलना में डॉट उत्पाद की अवधारणा अधिक सख्त है। जबकि बाद वाले को सामान्य रिक्त स्थान के लिए परिभाषित किया गया है, एक डॉट उत्पाद केवल तभी परिभाषित किया जाता है जब एक सीमित आधार द्वारा परिभाषित एक समन्वय प्रणाली की धारणा होती है। dot(x,y) का शब्दार्थ x'*y है जहां x और y कार्टेशियन दुनिया में वस्तुओं के निर्देशांक का प्रतिनिधित्व करते हैं। गणितीय पाठ्यपुस्तकों में शायद ही कभी डॉट उत्पाद शब्द का उल्लेख होगा क्योंकि लेखक आमतौर पर सामग्री को अधिक सामान्य (जरूरी नहीं कि परिमित और न ही यूक्लिडियन) रिक्त स्थान में इलाज करने में रुचि रखते हैं।

आगे अंतर करने के लिए, आंतरिक उत्पाद <x,y> (या inner(x,y) ) के साथ हिल्बर्ट स्थान में वस्तुएं अनंत हो सकती हैं और शब्दार्थ x'*y लागू नहीं होता है। उदाहरण के लिए, कार्यात्मक डेटा विश्लेषण में वस्तुएं f और g फ़ंक्शन हैं और आंतरिक उत्पाद आमतौर पर संख्यात्मक एकीकरण द्वारा प्राप्त किया जाता है: inner(f,g) = quadrature(f*g) । इस ऑपरेशन को डॉट उत्पाद कहना भ्रामक है।

एक और उदाहरण जैसा कि मैंने अपने CoDa.jl पैकेज में बताया है, वह है कंपोजिटल डेटा। कंपोजीशन ऑब्जेक्ट एक सिंप्लेक्स दुनिया में स्थित हैं, जिसके लिए ऑपरेशन x'*y का कोई मतलब नहीं है। हालांकि, एक आइसोमेट्रिक ट्रांसफॉर्मेशन (लॉग-रेशियो ट्रांसफॉर्मेशन) मौजूद है, जिसका उपयोग किसी अन्य ज्योमेट्री में कंपोजिशन को मैप करने के लिए किया जा सकता है, जहां कोई फिर कोऑर्डिनेट्स के साथ डॉट प्रोडक्ट को लागू कर सकता है। निर्देशांक के साथ काम करना आवश्यक नहीं है, लेकिन इस क्षेत्र में यह आम बात है। परिणाम वापस मूल स्थान में परिवर्तित किया जा सकता है जहां वस्तुएं मौजूद हैं।

मुझे भाषा में dot शब्द को बनाए रखने में कोई लाभ नहीं दिख रहा है, लेकिन अगर कोई पिछड़ा संगतता मांगता है, तो सामान्यीकरण inner(x::AbstractVector, y::AbstractVector) = dot(x,y) पूरी तरह से काम करता है।

क्या आप इस परिवर्तन के लिए आपत्तियों के बारे में विस्तार से बता सकते हैं?

क्या आप इस परिवर्तन के लिए आपत्तियों के बारे में विस्तार से बता सकते हैं?

बेस में नए सार्वजनिक कार्यों को जोड़ने के लिए हमें आम तौर पर उचित मात्रा में औचित्य की आवश्यकता होती है, यही आपत्ति है। यह InnerProducts पैकेज द्वारा प्रदान किया जा सकता है। इसे भाषा में ही निर्मित करने की आवश्यकता क्यों है? यह पहला सवाल था जो @andreasnoack ने ऊपर पूछा था - इसका कुछ हद तक अस्पष्ट उत्तर मिला "मुझे लगता है कि इन गणितीय रिक्त स्थान के लिए औपचारिक इंटरफ़ेस होने से उपयोगकर्ताओं को टाइप सिस्टम का बेहतर फायदा उठाने में मदद मिलेगी"। ऐसा कोई कारण नहीं है कि पैकेज में परिभाषित इंटरफ़ेस बेस में किसी एक से कम औपचारिक है। Base.inner के साथ ऐसा क्या है जो Base.inner InnerProducts.inner पेशकश नहीं करता है? यह एक वास्तविक प्रश्न है जिसका एक ठोस उत्तर हो सकता है, लेकिन मुझे नहीं पता कि वह उत्तर क्या हो सकता है, इसलिए प्रश्न पूछा जा रहा है।

मुझे बुनियादी गणितीय अवधारणा को परिभाषित करने के लिए एक अच्छा तर्क नहीं दिखता है जैसे कि आंतरिक उत्पाद कहीं और जो बेस में नहीं है। एक भाषा जिसका मुख्य दर्शक वैज्ञानिक कंप्यूटिंग है, लोग सही शब्दावली से लाभान्वित होंगे। norm Base.LinAlg और inner में परिभाषित क्यों किया गया है, जो एक ही समूह में है, को पैकेज में परिभाषित किया जाना चाहिए? इस विसंगति के अलावा, भाषा में पहले से ही dot है, जो मुझे आश्चर्यचकित करता है कि इसमें अधिक सामान्य अवधारणा के बजाय इतना विशिष्ट क्यों होना चाहिए?

तो आप सभी संभावित गणितीय अवधारणाओं को मूल भाषा में चाहते हैं? आधार में परिभाषित कुछ नहीं होने से लोगों को गलत शब्दावली का उपयोग करने के लिए मजबूर नहीं किया जाता है। norm फ़ंक्शन LinAlg से निर्यात किया जाता है क्योंकि इसे LinAlg में परिभाषित और उपयोग किया जाता है। dot के लिए समान। क्या आप प्रस्ताव कर रहे हैं कि dot का नाम बदलकर inner कर दिया जाए?

तो आप सभी संभावित गणितीय अवधारणाओं को मूल भाषा में चाहते हैं?

मैंने कभी नहीं कहा कि।

आधार में परिभाषित कुछ नहीं होने से लोगों को गलत शब्दावली का उपयोग करने के लिए मजबूर नहीं किया जाता है।

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

क्या आप प्रस्ताव कर रहे हैं कि बिंदु का नाम बदलकर आंतरिक कर दिया जाना चाहिए?

मेरी राय में यह पहले से ही एक बड़ा सुधार होगा। मैंने ऊपर दिए गए सभी उदाहरण कार्यात्मक और रचनात्मक डेटा पर देखें। इन समुदायों के लोग अपने काम में कभी भी dot शब्द का प्रयोग नहीं करेंगे। "डॉट" किसी अन्य चीज़ की तुलना में कंप्यूटर विज्ञान शब्द की तरह अधिक है।

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

https://github.com/JuliaLang/julia/issues/22227 और https://github.com/JuliaLang/julia/pull/22220 में इसकी थोड़ी चर्चा हुई।

डॉट का नाम बदलकर इनर करना डॉट के अलावा इनर को बेस में जोड़ने की तुलना में काफी अलग प्रस्ताव है।

इस सूत्र में मैंने अपने पहले संदेश में यही प्रस्तावित किया था:

मैं आंतरिक रूप से डॉट का नाम बदलने का प्रस्ताव देना चाहता हूं, या शायद उपयोगकर्ताओं को आंतरिक (x, y) को ऑब्जेक्ट्स x और y के बीच सामान्य आंतरिक उत्पाद के रूप में परिभाषित करने के लिए निर्देशित करना चाहता हूं

मैं दोहराता हूं कि डॉट उत्पाद उस ऑपरेशन के लिए गलत शब्द है जिसकी मैं यहां चर्चा कर रहा हूं। आंतरिक, बाहरी, अदिश गुणन... ये गणितीय वस्तुएँ हैं। "डॉट उत्पाद" एक कम्प्यूटेशनल ऑब्जेक्ट है: यह संख्याओं के दो अनुक्रम प्राप्त करता है और x1*y1 + x2*y2 + ... xn*yn निष्पादित करता है, जो अन्य गणितीय रिक्त स्थान में एक बेकार ऑपरेशन है।

मैंने आपके द्वारा प्रस्तावित दूसरे विकल्प पर ध्यान केंद्रित किया था, जो लगता है कि Base.inner को कॉल करने के लिए फॉलबैक के साथ जोड़ रहा है Base.dot । कोई भी विकल्प संभव है, लेकिन दोनों को कुछ औचित्य की आवश्यकता है: एक नया ऑपरेशन जोड़ने के लिए, एक कारण की आवश्यकता है कि यह सिर्फ एक पैकेज में क्यों नहीं हो सकता है (इस चर्चा का प्रारंभिक भाग क्या था); नाम बदलने के लिए, यह तय करने की आवश्यकता है कि dot गलत नाम है और inner सही नाम है (ऐसा लगता है कि बातचीत में बदल गया है)।

@juliohm यह शायद (पुनः) कहने लायक है कि वर्तमान में Base को सिकोड़ने और पैकेजों के उपयोग को प्रोत्साहित करने के लिए एक सक्रिय प्रयास है। इस मामले में dot मानक जूलिया में प्रदान किए गए रैखिक बीजगणित में भाग लेने वाले सभी प्रकारों के लिए सही प्रतीत होता है (यानी Number और Array - तो हाँ, एक निश्चित, ज्ञात है , सभी मामलों में सीमित आधार - इस प्रकार मुझे नहीं लगता कि हमने शब्दावली में कोई गलती की है, हालांकि बेहतर विकल्प हो सकते हैं)। मैं इस प्रस्ताव के खिलाफ नहीं हूं - लेकिन यह स्पष्ट करना चाहता हूं कि आप बदलाव के लिए कुछ "अव्यक्त" प्रतिरोध का अनुभव क्यों कर रहे हैं।

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

इस प्रकार, इसे Base (या LinAlg ) में डालने के लिए एक उचित मामला बनाने का बोझ है, इसे उपयोगकर्ता पैकेज में डालने से सख्ती से बेहतर है। प्राथमिक कारण एक इंटरफ़ेस प्रदान करना प्रतीत होता है जिसे दूसरों द्वारा साझा और विस्तारित किया जा सकता है - क्या यह एक उचित सारांश है? Clustering.jl से जेनेरिक कोड को आपके आंतरिक उत्पाद के साथ काम करने देने के बारे में तर्क बहुत आकर्षक लगता है। इसके अलावा, इस संदर्भ में कि हम LinAlg को एक stdlib पैकेज में विभाजित कर रहे हैं - मैं सोच रहा था कि अगर मैं LinearAlgebra नामक पैकेज का लेखक होता तो शायद मुझे एक inner शामिल करने में खुशी होगी

अपने विचार साझा करने के लिए @andyferris धन्यवाद। मैं प्रतिरोध को बहुत स्पष्ट रूप से देखता हूं, जो एक ऐसी चीज है जिसे लेकर मैं बहुत उत्साहित नहीं हूं। फिर भी, मैं इस बारे में उत्सुक हूं कि यह विशिष्ट प्रस्ताव कैसे कोड वृद्धि की ओर ले जाता है? मेरे लिए, यह अमूर्तता में बड़े सुधार के साथ कोड में एक मामूली बदलाव की तरह लगता है। Clustering.jl के साथ उदाहरण कई में से एक है, किसी भी कर्नेल-आधारित विधि के बारे में सोचें जिसे मनमाने ढंग से जूलिया प्रकारों के साथ काम करने के लिए बनाया जा सकता है जिसके लिए आंतरिक उत्पाद की धारणा मौजूद है। MultivariateStats.jl में उनमें से बहुत सारे हैं।

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

हां, मानक पुस्तकालय सभी जूलिया सिस्टम छवि के साथ बनाए गए हैं और डिफ़ॉल्ट रूप से उपलब्ध हैं। कम से कम v1.x श्रृंखला के लिए किसी को भी using LinAlg टाइप करने की आवश्यकता नहीं होगी (मुझे नहीं लगता कि इसका नाम बदलकर LinearAlgbebra कर दिया जाएगा, btw, मैंने अभी इसे एक काल्पनिक प्रतियोगी के रूप में बनाया है) .

स्पष्ट करने के लिए, इसे मानक जूलिया के साथ लोड किया जाएगा, इसलिए आपको कुछ भी इंस्टॉल करने की आवश्यकता नहीं है, लेकिन आपको अभी भी using LinAlg लिखना होगा ताकि इसे निर्यात किए जाने वाले नाम प्राप्त हो सकें।

यह वह जगह है जहां यह अजीब हो जाता है, ठीक है, क्योंकि हमें * तरीके मिलेंगे और इसी तरह बिना using LinAlg ? (दूसरे शब्दों में, LinAlg एक प्रकार का समुद्री डाकू है)।

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

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

लक्ष्य संरचना डेटा के साथ कारक विश्लेषण करना है। मेरे पास Composition नामक एक प्रकार है और रचनाओं के स्थान में एक आंतरिक उत्पाद है। मैं कई नमूने (जैसे चट्टान के नमूने) एकत्र करता हूं और उन सभी को एक बड़े Vector{Composition} (जैसे संरचना =% पानी,% अनाज,% हवा) में डाल देता हूं। अब मैं डेटा के इस वेक्टर पर एक अन्य पैकेज (जैसे MultivariateStats.jl) में लागू एक कारक विश्लेषण एल्गोरिदम को कॉल करना चाहता हूं। डिफ़ॉल्ट रूप से आयात किए गए inner उत्पाद के बिना आप इसे सामान्य रूप से कैसे कार्यान्वित करेंगे?

पिछली टिप्पणियों से मुझे जो समझ में आया वह यह है कि MultivariateStats.jl और CoDa.jl दोनों को LinAlg.jl पर निर्भर रहना होगा। MultivariateStats.jl में निर्भरता सिर्फ नाम inner को दायरे में लाने के लिए है। CoDa.jl में निर्भरता inner के लिए एक विधि को परिभाषित करना है जिसे MultivariateStats.jl द्वारा बुलाया जा सकता है। क्या आप यही सुझाव दे रहे हैं?

ऐसा लगता है कि Composition{D} D के तहत + और * के तहत एक आयामी वेक्टर स्थान है।

मैं दोहरी वेक्टर स्पेस को परिभाषित करने के लिए काफी लुभावना होगा।

तो, आप adjoint(::Composition) -> DualComposition और *(::DualComposition, ::Composition) -> scalar (वर्तमान में inner ) को परिभाषित कर सकते हैं। DualComposition को अंदर Composition रखने के अलावा बहुत कुछ नहीं करना होगा।

https://en.wikipedia.org/wiki/Dot_product में पहला वाक्य यह सुझाव देता है कि dot किन्हीं दो पुनरावृत्तियों पर एक ऑपरेशन हो सकता है। हम इसे पुनरावर्ती बना सकते हैं और इसे Number के लिए परिभाषित कर सकते हैं, और inner को अमूर्त रैखिक बीजगणित फ़ंक्शन के रूप में परिभाषित कर सकते हैं, जो Number और AbstractArray के लिए ओवरलैप होता है।

धन्यवाद @andyferris , मैं दोहरी जगह पर आपके विचारों की सराहना करता हूं। हालांकि मैं इस कार्य के लिए एक नए प्रकार पर भरोसा नहीं करना चाहता। अंतिम समाधान अनावश्यक रूप से जटिल है।

मुझे यह समझने में दिलचस्पी है कि ऐसा कुछ क्यों है:

inner(x,y) = sum(x.*y)
norm(x) = sqrt(inner(x,x))

export inner, norm

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

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

अगर मैं इस पर और जोर दे सकता हूं, तो आंतरिक उत्पाद की अवधारणा है, जो सरणी से स्वतंत्र है। इस अवधारणा को बेस में export inner कथन द्वारा दर्शाया गया है। निर्देशांक inner(x,y) = sum(x.*y) प्रतिनिधित्व करने वाली सरणी जैसी वस्तुओं के लिए आंतरिक उत्पादों का कार्यान्वयन है। यदि आवश्यक हो, तो इस ऑपरेशन को ऊपर की तरह बेस में फॉलबैक विधि के रूप में परिभाषित किया जा सकता है।

उपयोग के मामले का एक अन्य उदाहरण क्रायलोव विधियाँ हैं। यदि आपके पास आंतरिक उत्पादों के साथ फ़ंक्शन रिक्त स्थान हैं, तो आप उस अनंत आयामी फ़ंक्शन स्पेस के एक छोटे परिमित-आयामी उप-स्थान में रैखिक समस्या या eigenproblem का अनुमान लगाने के लिए क्रिलोव विधियों का उपयोग कर सकते हैं।

मेरे पास भी मेरी अपनी वस्तुएं हैं जो वेक्टर/हिल्बर्ट स्पेस बनाती हैं लेकिन <: AbstractArray का हिस्सा नहीं हैं। सादृश्य से जो रैंक N>1 के साथ वेक्टर रिक्त स्थान बनाता है और क्रायलोव विधियों में 'वैक्टर' के रूप में उपयोग किया जा सकता है, मैं vecdot और vecnorm का उपयोग करने पर भरोसा करने आया हूं आंतरिक उत्पाद और आदर्श की सामान्यीकृत धारणा होने के नाते। इसलिए मैं क्रायलोव विधियों के साथ एक पैकेज विकसित कर रहा हूं जो रैखिक ऑपरेटरों के रूप में कार्यों का उपयोग करता है और जहां 'वेक्टर किसी भी प्रकार का हो सकता है, बशर्ते उस प्रकार की वस्तुएं vecdot , vecnorm और कुछ का समर्थन करें अन्य चीजें ( scale! , zero , ...) लेकिन हो सकता है कि बेस में इन अवधारणाओं का क्या मतलब था, इसका दुरुपयोग कर रहा है, इसलिए यहां सही इंटरफ़ेस को सीधा करना अच्छा होगा।

दाएं - vecdot का नाम बदलकर inner किया जा सकता है।

(अब मैं अस्पष्ट रूप से सोच रहा हूं कि norm को वास्तव में matrixnorm कहा जाना चाहिए, norm के साथ हमेशा मेल खाने वाले मैट्रिक्स के लिए inner । ऐसा लगता है कि शायद दो अलग-अलग हैं norm के साथ चल रही चीजें जो इसे सामान्य बनाने में कुछ कठिनाइयों का कारण बन रही हैं)

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

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

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

विकल्प 1 (मेरी व्याख्या अब तक):
उपसर्ग vec एक सामान्य वेक्टर के रूप में व्याख्या करते समय उस वस्तु की संपत्ति को इंगित करता है, इसलिए

• नेस्टेड सरणियों के लिए vecdot और vecnorm निश्चित हैं (PR #25093)
• एक नई veclength परिभाषा जोड़ी गई है

विकल्प 2 (शायद बेहतर): अधिक गणितीय रूप से सही नामों का उपयोग करें

• inner
• dimension
• लेकिन norm के साथ क्या करना है?

और अंत में, बस @stevengj को पिंग करना क्योंकि उसके पास निश्चित रूप से कुछ उपयोगी टिप्पणियां होंगी; मेरी क्षमायाचना अगर यह असुविधाजनक है।

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

@juliohm , inner(x,y) = sum(x.*y) सामान्य रूप से एक आंतरिक उत्पाद भी नहीं है, इसलिए आधार में डालने के लिए यह एक बहुत ही भयानक फॉलबैक होगा।

लेकिन dot पहले से ही आधार में विभिन्न वस्तुओं के लिए सही आंतरिक उत्पाद (वास्तव में असफल) की गणना नहीं कर रहा है जो वैक्टर के रूप में व्यवहार करता है, उदाहरण के लिए रैंक N>1 या नेस्टेड सरणी के साथ सरणी (नेस्टेड वैक्टर एकमात्र मामला है जहां यह सही ढंग से काम करता है)। इसके अलावा, सामान्य नाम norm मैट्रिसेस के लिए अस्पष्ट हो जाता है, क्योंकि मैं इस रिटर्न को प्रेरित मानदंड के वर्तमान विकल्प से सहमत हूं, लेकिन कभी-कभी "वेक्टर मानदंड" (फ्रोबेनियस मानदंड) की भी आवश्यकता होती है।

इसलिए, मेरा सबसे कम प्रभाव वाला प्रस्ताव यह होगा कि शब्दार्थ vecnorm(x) = norm(vec(x)) को छोड़ दिया जाए और इसके बजाय vecnorm(x) की व्याख्या " x के लिए कुछ सामान्य प्रकार की वस्तु के रूप में की जाए जो एक के रूप में व्यवहार करती है वेक्टर स्पेस, x " (और vecdot के समान) के संबंधित वेक्टर मानदंड की गणना करें। हालांकि यह व्याख्या (और इसलिए प्रलेखन) में एक बदलाव है, बेस में वस्तुओं के लिए वास्तविक कार्यान्वयन/कार्रवाई बहुत अलग नहीं होगी (पीआर #25093) और अधिकांश मामलों के लिए एक ही परिणाम उत्पन्न करेगी (रैंक N सरणी अदिश या सदिशों का)। एक फ़ंक्शन veclength(x) जो x के संबंधित वेक्टर स्पेस आयाम को लौटाता है, इंटरफ़ेस को पूरा करेगा।

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

अनौपचारिक उपयोग में "फ़ंक्शंस का डॉट उत्पाद" देखना बहुत आम है, विशेष रूप से शैक्षणिक सेटिंग्स में जहां कोई परिमित-आयामी वेक्टर रिक्त स्थान के समानता पर जोर देने की कोशिश कर रहा है

कृपया यह न कहें कि नाम महत्वहीन है, क्योंकि यह है। मैं एन-वें समय के लिए दोहराऊंगा: आंतरिक उत्पाद और डॉट उत्पाद एक ही चीज़ नहीं हैं। सार हिल्बर्ट रिक्त स्थान के साथ काम को उजागर करने वाली कोई भी गंभीर सामग्री कभी भी "डॉट" का उपयोग नहीं करेगी। यदि आप मेरे शब्दों के बजाय विकिपीडिया पर भरोसा करना पसंद करते हैं, तो यहाँ परिभाषाएँ कॉपी और पेस्ट की गई हैं:

अंदरूनी प्रोडक्ट

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

डॉट उत्पाद

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

भाषा में शब्दावली और गणितीय स्थिरता को सुधारने का यह प्रतिरोध मनोबल गिराने वाला है। कोई फर्क नहीं पड़ता कि मैं आपके सामने कितने तथ्य प्रस्तुत करता हूं, उदाहरणों की संख्या और मामलों का उपयोग करने से कोई फर्क नहीं पड़ता, "मैं डॉट के साथ ठीक हूं" के अलावा कोई काउंटर तर्क नहीं है।

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

यह तय करना महत्वपूर्ण है कि कोई व्यक्ति यहां क्या चाहता है, और कार्यों के सेट को लागू करना चाहिए यदि वे एक नए हिल्बर्ट स्थान या बनच स्थान को परिभाषित करते हैं। वर्तमान में, यदि आप एक नए हिल्बर्ट स्थान का प्रतिनिधित्व करने वाले प्रकार को परिभाषित करना चाहते हैं, तो आपको यकीनन dot और norm को परिभाषित करना चाहिए (क्योंकि वर्तमान में हमारे पास बाद वाले के लिए कमबैक की कमी है), और मुझे लगता है कि adjoint यदि आप एक दोहरे स्थान वाली वस्तु की मैपिंग चाहते हैं।

जैसा कि @ जुथो कहते हैं, यह सरणी-सरणी मामले से जटिल है, क्योंकि वहां कई संभावित चीजें हैं जिन्हें कोई वहां चाहता है। चूंकि सभी संभावित शब्दार्थों के लिए मानकीकृत नाम नहीं हैं, इसलिए ऐसे नाम/अर्थशास्त्र खोजना कठिन है जो सभी को संतुष्ट कर सकें। vecdot शब्दार्थ की चर्चा के लिए #25093 देखें। मेरे पास यहां कोई अच्छा जवाब नहीं है, खुद।

यहां कुछ संभावनाएं

1. x[i]' * y[i] का योग। वर्तमान में, यह dot(x,y) है। मैट्रिक्स के वैक्टर (जहां यह एक मैट्रिक्स देता है) के लिए एक आंतरिक उत्पाद नहीं है, और वर्तमान में बहुआयामी सरणी के लिए सभी को परिभाषित नहीं किया गया है।
2. बहुआयामी सरणियों सहित dot(x[i], y[i]) का योग, और conj(x)*y के लिए Number । वर्तमान में, यह vecdot(x,y) है।
3. कुछ फ़ंक्शन, जैसे inner(x,y) को हमेशा एक सच्चे आंतरिक उत्पाद के रूप में परिभाषित किया जाता है, और सरणियों के लिए इसे inner(x[i],y[i]) योग बनाते हैं - अनिवार्य रूप से "पुनरावर्ती vecdot" जो @Jutho चाहता है। लेकिन फिर, मैट्रिक्स के लिए A , यह आंतरिक उत्पाद प्रेरित मानदंड norm(A) के साथ असंगत है जो कि हमारी वर्तमान norm परिभाषा है। इसे ठीक करने के लिए, हमें मैट्रिक्स के लिए norm(A) को फ्रोबेनियस मानदंड में डिफ़ॉल्ट रूप से बदलना होगा, जो संभावित रूप से एक दूरगामी ब्रेकिंग परिवर्तन होगा।

एक प्रश्न (#25093 में आंशिक रूप से चर्चा की गई) यह है कि क्या हमें बेस में इन तीनों की आवश्यकता है, या यदि हम दो (और कौन से दो, और हम उन्हें क्या कहते हैं) से दूर हो सकते हैं। @जुथो का प्रस्ताव, जैसा कि मैं इसे समझता हूं, अनिवार्य रूप से आधार में विकल्प 2 को समाप्त करना है और फिर विकल्प 3 के लिए vecdot और vecnorm का उपयोग करना है। तब हमारे पास एक वास्तविक आंतरिक उत्पाद है, लेकिन शब्दावली जूलिया के लिए बल्कि अद्वितीय है, और अनंत-आयामी हिल्बर्ट रिक्त स्थान के लिए थोड़ा अजीब है। यह निश्चित रूप से दुनिया का अंत नहीं होगा।

एक और संभावना (जो हम vecdot के साथ करते हैं उससे कुछ हद तक स्वतंत्र) एक वास्तविक आंतरिक उत्पाद होने के लिए dot की आवश्यकता के लिए (वापस) जाना होगा। यानी व्यवहार 1 को खत्म करें, और dot(x::AbstractVector, y::AbstractVector) को sum dot(x[i],y[i]) $ के बराबर बनाएं। फिर भी इसे बहुआयामी सरणियों के लिए परिभाषित न करें ( norm के अनुरूप रहने के लिए)।

मेरा वर्तमान व्यक्तिगत झुकाव dot को एक सच्चे आंतरिक उत्पाद के रूप में परिभाषित करना होगा (जो norm के अनुरूप होना चाहिए), इसे वैक्टर के लिए dot(x[i],y[i]) के योग में बदलना (यानी बदलना वेक्टर-ऑफ-मैट्रिस केस), और इसे बहुआयामी सरणी के लिए परिभाषित नहीं करना जारी रखता है। फिर vecdot को पुनरावर्ती रूप से vecdot पर कॉल करने के लिए परिभाषित करें जैसा कि @Jutho ने सुझाव दिया है, फॉलबैक vecdot(x,y) = dot(x,y) के साथ। अंत में, कहें कि नए "हिल्बर्ट-स्पेस" प्रकारों को dot और norm परिभाषित करना चाहिए। यह मेरे लिए सबसे कम-विघटनकारी, सबसे अधिक समझने योग्य परिवर्तन जैसा लगता है।

(एक norm(x) = sqrt(real(dot(x,x))) फॉलबैक भी एक संभावना है, हालांकि यह कुछ हद तक खतरनाक है क्योंकि यह नकली अतिप्रवाह के लिए कमजोर है। ध्यान दें कि हम तकनीकी कारणों से sqrt(dot(x,x)) को फॉलबैक के रूप में उपयोग नहीं कर सकते हैं: हम एक चाहते हैं Real परिणाम, Complex परिणाम नहीं।)

इस सूचनात्मक प्रतिक्रिया के लिए धन्यवाद @stevengj । बस एक छोटी सी टिप्पणी:

फ़ॉलबैक के साथ vecdot(x,y) = dot(x,y) । अंत में, कहें कि नए "हिल्बर्ट-स्पेस" प्रकारों को dot और norm परिभाषित करना चाहिए।

इसमें दो समस्याएं हैं। vecdot(x,y) = dot(x,y) फ़ॉलबैक मौजूद नहीं हो सकता, क्योंकि vecdot पहले से ही सामान्य पुनरावृत्तियों से निपटने के लिए Any तर्क स्वीकार करता है। दूसरी समस्या यह है कि, यदि dot और norm को वास्तविक आंतरिक उत्पाद के रूप में उजागर किया जाता है और मानदंड है कि उपयोगकर्ता प्रकार जैसे किसी भी वेक्टर को परिभाषित करना चाहिए, तब भी जब एक पैकेज लिखते हैं जैसे कि क्रायलोव विधियां पूरी तरह से सामान्य वेक्टर जैसे प्रकारों के साथ काम करना चाहिए, यह अभी भी उस मामले के लिए काम नहीं करेगा जहां उपयोगकर्ता नेस्टेड या बहुआयामी सरणी को वेक्टर जैसे ऑब्जेक्ट्स के रूप में उपयोग करना चाहता है। इसलिए, मैं तर्क दूंगा कि vecdot और vecnorm सामान्य आंतरिक उत्पाद और वेक्टर जैसी वस्तुओं के मानदंड हैं। यह इस तथ्य के साथ भी अच्छी तरह से फिट बैठता है कि मैट्रिस के लिए, अधिकांश लोग वास्तव में norm को प्रेरित मैट्रिक्स/ऑपरेटर मानदंड होने की उम्मीद करेंगे।

वास्तविक उपयोग के मामले के लिए (यह दिखाने के लिए कि यह कुछ असाधारण मामला नहीं है)। स्टोकेस्टिक मेट्रिसेस में सबसे बड़ा (पेरोन-फ्रोबेनियस) आइजेनवैल्यू होता है, जिसके लिए संबंधित आइजेनवेक्टर एक निश्चित बिंदु संभाव्यता वितरण का प्रतिनिधित्व करता है। इसके क्वांटम सामान्यीकरण में, संभाव्यता वितरण एक सकारात्मक निश्चित मैट्रिक्स (घनत्व मैट्रिक्स) के लिए सामान्यीकृत होता है और ऐसा मैट्रिक्स पूरी तरह से सकारात्मक मानचित्र का निश्चित बिंदु (सबसे बड़ा eigenvalue के अनुरूप eigenvector) होता है, अर्थात नक्शा rho -> sum(A[i] rho A[i]^\dagger for i = 1:N) जहां इस प्रकार rho घनत्व मैट्रिक्स है और A[i] प्रत्येक i के लिए एक मैट्रिक्स है (जिसे क्रॉस ऑपरेटरों के रूप में जाना जाता है जो पूरी तरह से सकारात्मक मानचित्र का प्रतिनिधित्व करता है)। बड़े मैट्रिक्स आयामों के लिए, निश्चित बिंदु घनत्व मैट्रिक्स खोजने के लिए एक अर्नोल्डी विधि आदर्श रूप से उपयुक्त है।

मेरा वर्तमान व्यक्तिगत झुकाव डॉट को एक सच्चे आंतरिक उत्पाद (जो आदर्श के अनुरूप होना चाहिए) के रूप में परिभाषित करना होगा, इसे वैक्टर के लिए डॉट (x [i], y [i]) के योग में बदलना होगा। अंत में, कहें कि नए "हिल्बर्ट-स्पेस" प्रकारों को डॉट और मानदंड को परिभाषित करना चाहिए।

यह पहले से ही बहुत बड़ा सुधार है। dot को आधार में inner शब्दार्थ रखने के लिए दस्तावेजीकरण कम से कम उपयोगकर्ताओं को अनावश्यक पुस्तकालयों को आयात किए बिना अपने स्वयं के स्थान को परिभाषित करने की अनुमति देगा। मैं नामकरण से खुश नहीं हूं, लेकिन कम से कम उन लोगों के लिए कार्यक्षमता उपलब्ध होगी जिन्हें इसकी आवश्यकता है।

हां, मुझे लगता है कि "हिल्बर्ट-स्पेस" प्रकारों के लिए लागू करने के लिए एक दस्तावेज इंटरफ़ेस होना अच्छा होगा।

बेशक, वेक्टर रिक्त स्थान के लिए इस सामान्य इंटरफ़ेस के बारे में सोचते हुए, यदि इसमें ऊपर दिए गए सुझाव के अनुसार norm शामिल है तो यह मैट्रिक्स के लिए फ्रोबेनियस मानदंड होना चाहिए (और उच्च-आयामी सरणी के लिए सामान्यीकृत, क्योंकि सभी सरणी वेक्टर के तत्व हैं स्थान)। उस स्थिति में हमें मैट्रिक्स के लिए एक अलग "ऑपरेटर मानदंड" फ़ंक्शन की आवश्यकता होगी ( matnorm या opnorm या कुछ और, या norm ... पर एक कीवर्ड तर्क)।

@andyferris , कृपया मेरी आखिरी टिप्पणी नोट करें। norm और dot सामान्य हिल्बर्ट स्पेस इंटरफ़ेस नहीं बन सकते, क्योंकि वे जूलिया में उच्च-आयामी सरणियों और नेस्टेड सरणियों जैसे वेक्टर जैसी वस्तुओं पर भी काम नहीं करते हैं। इसलिए vecdot और vecnorm इसके लिए एक 'बेहतर' (कम से कम तोड़ने के अर्थ में) उम्मीदवार हैं।

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

यहाँ उत्पाद से संबंधित मेरे व्यक्तिगत गणित ऑन्कोलॉजी का हिस्सा है।
अगर यह स्मृति को ब्रश करने/आम सहमति लाने में मदद कर सकता है

• डॉट उत्पाद ; समानार्थी शब्द : अदिश उत्पाद
• अंदरूनी प्रोडक्ट
• पार उत्पाद
• टेंसर उत्पाद ; समानार्थी शब्द : बाहरी उत्पाद
• कील उत्पाद ; समानार्थी शब्द : बाहरी उत्पाद
• कप उत्पाद
• ट्रिपल उत्पाद

बोनस: कोई विकिपीडिया रेफरी नहीं

इस बिंदु पर, #25093 में @Jutho का प्रस्ताव कम से कम विघटनकारी परिवर्तन की तरह लगता है, भले ही इस संदर्भ में vec* शब्दावली मेरे लिए थोड़ी अजीब है।

मैं सहमत हूं कि vec* शब्दावली विषम है। इसलिए मानक नाम रखने के लिए कार्यों का नाम बदलना सभी उपयोगकर्ताओं के लिए फायदेमंद होगा।

मैं भी सहमत हूं कि vec* शब्दावली विषम है।

मैं सहमत हूं, vecdot के विकल्प के रूप में हम एक नई विधि inner पेश कर सकते हैं, लेकिन मुझे vecnorm "प्रतिस्थापित" करने के लिए एक अच्छा नाम नहीं पता है। वास्तव में, मुझे vecnorm नहीं लगता कि खराब, वेक्टर मानदंड हमारे इच्छित ऑपरेशन के लिए एक अच्छी तरह से स्थापित और स्पष्ट शब्द है।

यहां मूल मुद्दा मैट्रिसेस और बहुआयामी सरणियों के साथ है, जिसके लिए सामान्य norm(A) एक आंतरिक उत्पाद के साथ-साथ ऊपर चर्चा किए गए सरणियों के सरणियों के अनुरूप नहीं है। इन मामलों में कुछ असंबद्धता (जैसे vec* या fro* ) की आवश्यकता होती है ताकि यह इंगित किया जा सके कि कौन सा आंतरिक उत्पाद अभिप्रेत है।

आपके पास एक inner फ़ंक्शन हो सकता है जो डिफ़ॉल्ट रूप से vecdot है, लेकिन एक ही फ़ंक्शन के लिए दो नाम रखना थोड़ा मूर्खतापूर्ण है, और अभी भी समस्या है कि मानदंड को क्या कहा जाए।

मुझे vecdot नाम भी अजीब लगता है, वास्तव में, मुझे यह भी नहीं पता था कि यह अस्तित्व में है और इसके लिए अपना स्वयं का कार्य किया है ... जिसे inner कहा जाता है।

मेरी समझ यह है कि हम $#$1 inner vecdot को हटा सकते हैं, और इसे उपयोगकर्ताओं को अपने स्वयं के रिक्त स्थान को लागू करने के लिए आंतरिक उत्पाद शब्दार्थ दे सकते हैं।

norm के बारे में, जो मुझे नहीं पता। मैंने इस मुद्दे को आंतरिक उत्पादों पर चर्चा करने के लिए खोला, शायद एक और मुद्दा बेस में मानदंडों की स्थिति पर चर्चा करने के लिए उपयुक्त होगा।

मुझे लगता है कि हमारे पास $#$ vecdot और vecnorm के बजाय inner(x,y) और innernorm(x) = sqrt(inner(x,x)) (अतिप्रवाह से बचने के लिए अनुकूलित विशेष मामलों के साथ) हो सकते हैं। innernorm थोड़ा असामान्य है लेकिन संदर्भ में काफी स्पष्ट है।

इस बदलाव के लिए अंगूठे। inner और innernorm नाम स्पष्ट और अवधारणाओं के अनुरूप हैं। काश वे इसे जूलिया v1.0 में बना पाते।

inner और innernorm मुझे ठीक लगते हैं।

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

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

यानी मैं एक ऐसा फ़ंक्शन पसंद करूंगा जो हमेशा वेक्टर मानदंड करता है और दूसरा फ़ंक्शन जो हमेशा ऑपरेटर मानदंड करता है, और कोई फ़ंक्शन जो दोनों को करने का प्रयास नहीं करता है।

इसे और भी बेहतर पसंद करें @andyferris : +1: विशिष्ट मानदंड जो अंतरिक्ष में आंतरिक उत्पाद द्वारा प्रेरित मानदंड नहीं हैं, उनका अधिक विशिष्ट नाम हो सकता है। नाम norm का अर्थ बिल्कुल norm(x) = sqrt(inner(x,x)) होगा, और उपयोगकर्ता प्रकारों के लिए आवश्यकतानुसार इसे फिर से परिभाषित किया जा सकता है।

मैं व्यक्तिगत रूप से कह सकता हूं कि " norm एक वेक्टर स्थान के एक तत्व का मानदंड देता है"

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

आप "मानदंड" की परिभाषा के बारे में कुछ हद तक भ्रमित हो सकते हैं यदि आपको लगता है कि ऑपरेटर मानदंड "वेक्टर स्थान का मानदंड" नहीं है।

यह norm और innernorm के बीच एक उपयोगी अंतर भी है। यदि आप norm को परिभाषित करते हैं, तो मैं कहूंगा कि इसका तात्पर्य केवल यह है कि आपके पास एक बनच स्थान है (या कम से कम एक आदर्श वेक्टर स्थान)। यदि आप innernorm को परिभाषित करते हैं, तो इसका तात्पर्य है कि आपके पास हिल्बर्ट स्थान (या कम से कम एक आंतरिक उत्पाद स्थान) है और यह मानदंड inner के अनुरूप है।

उदाहरण के लिए, अनुकूली संख्यात्मक एकीकरण (ala quadgk) एक ऐसी चीज है जिसके लिए केवल एक मानक सदिश स्थान की आवश्यकता होती है, न कि आंतरिक-उत्पाद स्थान की।

निश्चित रूप से, क्षमा करें, मैं शायद अपनी भाषा के साथ थोड़ा अधिक सटीक था। वेक्टर स्पेस के लिए स्पष्ट रूप से कई मान्य मानदंड हैं, जिनमें विभिन्न ऑपरेटर मानदंड शामिल हैं।

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

यह norm और innernorm के बीच एक उपयोगी अंतर भी है। यदि आप मानदंड को परिभाषित करते हैं, तो मैं कहूंगा कि इसका तात्पर्य केवल यह है कि आपके पास एक बनच स्थान है (या कम से कम एक आदर्श वेक्टर स्थान)। यदि आप innernorm को परिभाषित करते हैं, तो इसका तात्पर्य है कि आपके पास हिल्बर्ट स्थान (या कम से कम एक आंतरिक उत्पाद स्थान) है और यह मानदंड inner के अनुरूप है।

यह उचित प्रतीत होता है, लेकिन मुझे अभी भी आश्चर्य होगा कि अगर किसी वस्तु में innernorm है तो उसे एक अलग norm की आवश्यकता क्यों होगी? मैं वैकल्पिक रूप से प्रस्ताव दूंगा कि बनच स्पेस के लिए इंटरफेस की आवश्यकता है norm जबकि आंतरिक उत्पाद रिक्त स्थान के लिए एक इंटरफ़ेस norm और inner दोनों प्रदान करेगा। फिर इन कार्यों का उपयोग सामान्य कोड में किया जा सकता है जो कि Banach या आंतरिक-उत्पाद रिक्त स्थान की वस्तुओं की अपेक्षा करता है (संपादित करें: इस विचार के साथ कि Banach रिक्त स्थान में काम करने वाला कोड स्वचालित रूप से आंतरिक-उत्पाद रिक्त स्थान पर भी काम करेगा)।

मुझे लगता है कि आप प्रस्ताव कर रहे हैं कि norm(x) हमेशा किसी प्रकार के तत्व-वार यूक्लिडियन मानदंड (यानी मैट्रिस के लिए फ्रोबेनियस मानदंड) का संदर्भ लें, यानी मूल रूप से vecnorm अब रिकर्सिव केस मॉड्यूलो है। इस मामले में हम dot(x,y) को इसी आंतरिक उत्पाद के रूप में फिर से परिभाषित कर सकते हैं ( inner भी काम करता है, लेकिन dot में एक इंफिक्स संस्करण का लाभ है x ⋅ y )

मैं इसके साथ सिद्धांत रूप में ठीक हूं, लेकिन यह एक ब्रेकिंग बदलाव होगा और इसे प्राप्त करने में 0.7 से पहले थोड़ा देर हो सकती है ...

क्या L2 उच्च आयामी में भी एक अच्छा डिफ़ॉल्ट है?
यह लेख दूरी के बारे में बात करता है, लेकिन हो सकता है कि यह मानदंड से भी संबंधित हो
https://stats.stackexchange.com/questions/99171/why-is-euclidean-distance-not-a-good-metric-in-high-dimensions

इस मामले में हम डॉट (एक्स, वाई) को संबंधित आंतरिक उत्पाद के रूप में फिर से परिभाषित कर सकते हैं (आंतरिक कार्य भी, लेकिन डॉट में एक इंफिक्स संस्करण x y का लाभ है)

क्या हम पूरी तरह से dot से छुटकारा पा सकते हैं? इन्फिक्स नोटेशन dot नामक फ़ंक्शन के अस्तित्व से असंबंधित होना चाहिए। बस जूलिया सरणियों के लिए inner विधि के साथ इन्फिक्स को परिभाषित करें। संभव है कि?

यह वास्तव में यही है, डॉट उत्पाद: यूक्लिडियन ज्यामिति के साथ आर ^ एन में एक्स और वाई वैक्टर के बीच आंतरिक उत्पादों के लिए एक सुविधाजनक नोटेशन x ⋅ y।

@stevengj मुझे लगता है कि यह एक अच्छा सारांश है, हाँ।

@ o314 क्या L2 उच्च आयामीता में एक अच्छा डिफ़ॉल्ट है? शायद नहीं, लेकिन मैं वास्तव में इससे नफरत करता हूं अगर उदाहरण के लिए norm(v::AbstractVector) द्वारा चुना गया मानदंड $#$1 length(v) #$ पर निर्भर करता है :) मैं इसे दूसरे अनुमान के लिए समान रूप से पसंद नहीं करूंगा कि मेरा मैट्रिक्स या उच्च-आयामी सरणी "L2 के लिए बहुत बड़ा" है - मैं सुझाव दूंगा कि शायद इसे उपयोगकर्ता द्वारा स्पष्ट रूप से चिह्नित किया जाना चाहिए?

@juliohm यह निश्चित रूप से संभव है, हालांकि जैसा कि उल्लेख किया गया है, ये हमारे द्वारा सुझाए जा रहे परिवर्तनों को तोड़ रहे हैं। (फिर से, पुनरावर्ती मामले में मॉड्यूलो क्या करना है और inner और dot के बीच संभावित अंतरों पर पहले की चर्चा)।

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

दूसरी ओर, मुझे innernorm नाम से भी ऐतराज नहीं है, जो इस बात में स्पष्ट है कि यह एक आंतरिक उत्पाद आधारित मानदंड है (यानी यूक्लिडियन मामले में हमेशा p=2 )। मुझे कस्टम ऑब्जेक्ट्स के लिए गीलेर को आंकना मुश्किल लगता है (vec)norm को एक वैकल्पिक तर्क का समर्थन करना चाहिए p इंटरफ़ेस के हिस्से के रूप में, क्योंकि मेरे कुछ उपयोग मामलों में, केवल p=2 आसान है गणना करना।

यह वास्तव में यही है, डॉट उत्पाद: यूक्लिडियन ज्यामिति के साथ आर ^ एन में एक्स और वाई वैक्टर के बीच आंतरिक उत्पादों के लिए एक सुविधाजनक नोटेशन x ⋅ y।

मैं इससे सहमत हूं, इस अर्थ में कि मुझे याद नहीं है कि मैंने कभी भी सामान्य (जैसे जटिल) वेक्टर रिक्त स्थान के संदर्भ में x ⋅ y नोटेशन देखा हो। मुझे लगता है कि ऐसे मामलों में केवल गणितीय संकेतन (x,y) या Dirac संकेतन < x | y > का उपयोग किया जाता है। विद्युत चुंबकत्व में अक्सर 3-आयामी यूक्लिडियन अंतरिक्ष में वैक्टर के लिए E ⋅ B का उपयोग किया जाता है, और भले ही कोई जटिल संकेतन (अर्थात चरण) का उपयोग करता हो, यह जटिल संयुग्मन का संकेत नहीं देता है। यदि आवश्यक हो, तो ऐसे मामलों में जटिल संयुग्मन स्पष्ट रूप से निरूपित किया जाता है। तो मुझे कोई आपत्ति नहीं होगी अगर dot जटिल या हर्मिटियन संयुग्मन के बिना सिर्फ sum(x_i * y_i) बन गया, और inner सामान्य आंतरिक उत्पाद रिक्त स्थान के लिए सही आंतरिक उत्पाद बन गया। दुर्भाग्य से, यह संभवतः एकल रिलीज़ चक्र में नहीं किया जा सकता है।

क्या L2 उच्च आयामीता में एक अच्छा डिफ़ॉल्ट है? संभवतः नहीं, लेकिन मैं वास्तव में इससे नफरत करता हूं यदि उदाहरण के लिए मानदंड (v :: AbstractVector) द्वारा चुना गया मानदंड लंबाई (v) पर निर्भर करता है :) मैं इसे दूसरे अनुमान के लिए समान रूप से पसंद नहीं करूंगा कि मेरा मैट्रिक्स या उच्च-आयामी सरणी है "L2 के लिए बहुत बड़ा" - मैं सुझाव दूंगा कि शायद इसे उपयोगकर्ता द्वारा स्पष्ट रूप से चिह्नित किया जाना चाहिए?

मैं बीआईएम दुनिया में काम करता हूं जहां हम 2 डी और 3 डी को संभालते हैं, लेकिन 4 डी, 5 डी, 6 डी भी 7 डी हो सकता है। हम कभी आगे नहीं जाते। किसी भी बिंदु पर हम जानते हैं कि हम किन आयामों में काम करते हैं, और कौन सा अहंकार शामिल है। यह काफी हद तक काफी है।

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

सरणी से प्रेरित: समान पूरी तरह कार्यान्वित नहीं है और इसका परीक्षण करें।

norm2 = x -> x |> inner |> sqrt
norminf = ...
NMAX = 10
for N in 1:NMAX
    <strong i="13">@eval</strong> begin norm(a::Array{T,N}) where {T} = norm2 end
end
norm(a::Array{T,n}) where {T} = norminf

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

norm(x::AbstractVector, p::Real=2) = vecnorm(x, p) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L498
vecdot(x::Number, y::Number) = conj(x) * y # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L657
dot(x::Number, y::Number) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L659
function dot(x::AbstractVector, y::AbstractVector) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L677

# Call optimized BLAS methods for vectors of numbers
dot(x::AbstractVector{<:Number}, y::AbstractVector{<:Number}) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L698

Dot / vecdot का अर्थ है संयुग्म का उपयोग करना और यह तय करना कि BLAS में कब जाना है। इसे कहीं संभालना होगा। लेकिन यह एक ही नामस्थान में प्रबंधनीय होना चाहिए।

क्या L2 उच्च आयामीता में एक अच्छा डिफ़ॉल्ट है? शायद नहीं

L2 अनंत-आयामी रिक्त स्थान (जैसे फ़ंक्शन) के लिए भी सबसे सामान्य मानदंड है। मुझे लगता है कि किसी भी वेक्टर स्पेस की अपेक्षा करना उचित डिफ़ॉल्ट है।

जाहिर है आप चाहते हैं कि अन्य मानदंड भी उपलब्ध हों। यदि हम norm(x) को जहां भी संभव हो, तत्व के अनुसार L2 के रूप में फिर से परिभाषित करते हैं, तो norm(x, p) तत्व के अनुसार Lₚ होगा, और हमें संबंधित प्रेरित/ के लिए कुछ अन्य फ़ंक्शन (जैसे opnorm ) की आवश्यकता होगी। ऑपरेटर मानदंड।

मैं इससे सहमत हूं, इस अर्थ में कि मुझे याद नहीं है कि मैंने कभी भी सामान्य (जैसे जटिल) वेक्टर रिक्त स्थान के संदर्भ में x ⋅ y नोटेशन देखा हो।

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

हम dot को यथावत रख सकते हैं और inner को पेश कर सकते हैं, लेकिन मुझे लगता है कि यह एक भ्रमित करने वाला द्वंद्व पैदा करेगा - सबसे आम मामलों में, फ़ंक्शन समान होंगे, लेकिन विषम मामलों में (उदाहरण के लिए मैट्रिसेस के सरणियाँ) वे भिन्न होंगे।

लेकिन फिर से, परिवर्तनों को तोड़ने में थोड़ी देर हो सकती है, इसलिए हमें innernorm और inner का सहारा लेना पड़ सकता है। किसी भी मामले में, किसी को पीआर ASAP बनाने की आवश्यकता होगी।

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

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

• नॉन ब्रेकिंग, एक विशेषता जोड़ता है: inner(x,y) और innernorm(x) । vecdot और vecnorm की जगह, और सरणियों के सरणियों के लिए पुनरावर्ती।

• ब्रेकिंग: norm(x,p=2) को हमेशा एलिमेंट वाइज और रिकर्सिव होने के लिए बदलें, vecnorm की जगह, और ऑपरेटर/प्रेरित मानदंड के लिए एक नया फ़ंक्शन opnorm पेश करें। $#$8 vecdot #$ की जगह, dot(x,y) संबंधित तत्व-वार डॉट उत्पाद बनाएं। (वैकल्पिक: inner का नाम बदलें, लेकिन एक इंफिक्स ऑपरेटर होना अच्छा है, और dot और inner दोनों का होना कष्टप्रद है।)

अगर मैं चीजों को खरोंच से डिजाइन कर रहा था तो मैं 2 पसंद करूंगा, लेकिन चुपचाप इसका अर्थ बदलना बहुत विघटनकारी हो सकता है norm ।

एक मध्यवर्ती विकल्प inner और innernorm ( vecdot और vecnorm ) को परिभाषित करना और norm(matrix) से opnorm को पदावनत करना होगा। norm(matrix) = innernorm(matrix) फिर से पेश करें। इस तरह, लोग अंततः केवल inner और norm का उपयोग कर सकते हैं, और हम dot को वैक्टर-ऑफ-एरे के लिए वर्तमान विषम जानवर के रूप में छोड़ देते हैं ( inner के साथ मेल खाते हुए) संख्याओं के वैक्टर के लिए

innernorm के बारे में एक विषमता यह है कि आप एल 1 या लिनफ "तत्ववार" मानदंडों को निर्दिष्ट करने का एक तरीका चाहते हैं, लेकिन इनमें से कोई भी आंतरिक उत्पाद से मेल नहीं खाता है, इसलिए innernorm(x,p) एक मिथ्या नाम है।

मुझे आपका मध्यवर्ती विकल्प पसंद है।

जैसा कि ऊपर बताया गया है, मुझे innernorm(x) नाम पसंद है क्योंकि इसका अर्थ है p=2 और दूसरा तर्क नहीं होना चाहिए। मेरे पास ऐसी वस्तुएं हैं जिनके लिए मैं केवल आंतरिक उत्पाद मानदंड की गणना करना जानता हूं। लेकिन वर्तमान (vec)norm के साथ, यह मेरे लिए स्पष्ट नहीं है कि p तर्क अनुमानित बेस इंटरफ़ेस का हिस्सा है, और इसलिए मुझे नहीं पता कि दूसरे तर्क को छोड़ना है या समर्थन करना है यह लेकिन फिर p != 2 के लिए स्पष्ट रूप से जांचें और एक त्रुटि उत्पन्न करें।

लेकिन मुझे आपके प्रस्ताव के मध्यवर्ती चरण के दौरान vecnorm(matrix, p!=2) करने का कोई गैर-बहिष्कृत तरीका नहीं होने के साथ समस्या दिखाई दे रही है।

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

क्या हमें वास्तव में innernorm की आवश्यकता होगी या क्या हम अभी के लिए केवल vecnorm का उपयोग कर सकते हैं (और बाद में norm के पक्ष में vecnorm को हटा दें)?

मैं वास्तव में dot को inner से बदलने में कोई संभावित हंगामे नहीं देखता ... मुझे भी लगता है कि यह पर्याप्त स्पष्ट है कि आंतरिक उत्पाद डॉट उत्पादों का सामान्यीकरण है।

परिवर्तन दो अलग-अलग पीआर में लागू किए जा सकते हैं:

1. dot को inner से बदलें और इसे सामान्यीकृत अर्थ दें। वैकल्पिक रूप से, जूलिया सरणियों के बीच इन्फिक्स \cdot संकेतन बिंदु को आंतरिक बनाएं।
2. मानक रूपों और शब्दावली के आसपास अधिक चर्चा और बहिष्करण चक्र।

मेरी समझ यह है कि पीआर 1 को जूलिया v1.0 से पहले विलय किया जा सकता है। यह टूट नहीं रहा है।

dot को inner $ के साथ बदलना अभी भी टूट रहा होगा क्योंकि dot वर्तमान में सरणियों के सरणियों के लिए एक वास्तविक आंतरिक उत्पाद नहीं है - इसलिए आप केवल नाम बदलने के लिए अर्थ नहीं बदल रहे होंगे। मैं एक सच्चे आंतरिक उत्पाद के अर्थ को बदलने के लिए हूं, लेकिन यदि आप अर्थ बदलते हैं (इसे वास्तविक आंतरिक उत्पाद के रूप में परिभाषित करते हैं) तो मुझे इसे dot के रूप में वर्तनी जारी रखने में समस्या नहीं दिखती है।

तो, हम निम्नलिखित 0.7 में कर सकते हैं:

1. norm(matrix) से opnorm(matrix) और norm(vector of vectors) से vecnorm को हटा दें।
2. dot([vector of arrays], [vector of arrays]) को sum पर कॉल करने के लिए पदावनत करें।
3. कहें कि vecdot(x,y) और vecnorm(x, p=2) यूक्लिडियन आंतरिक उत्पाद/मानदंड हैं ( p=2 के लिए), और उन्हें पुनरावर्ती बनाएं (जो थोड़ा टूट रहा है, लेकिन व्यवहार में शायद कोई बड़ी बात नहीं है) .

फिर, 1.0 में:

1. vecnorm से norm और vecdot से dot को हटा दें। (सुनिश्चित नहीं है कि 1.0 रिलीज नियमों, @StefanKarpinski द्वारा इसकी अनुमति है?)

(ध्यान दें कि numpy.inner फ़ंक्शन, आश्चर्यजनक रूप से, हमेशा एक आंतरिक उत्पाद नहीं होता है। लेकिन inner और dot पर NumPy की शब्दावली कुछ समय के लिए अजीब रही है।)

जिन कारणों से मैं इसे dot के रूप में वर्तनी जारी रखना पसंद करता हूं:

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

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

मंगलवार, मई 15, 2018, 5:13 पूर्वाह्न स्टीवन जी. जॉनसन नोटिफिकेशन @github.com
लिखा था:

(ध्यान दें कि numpy.inner
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.inner.html
कार्य, आश्चर्यजनक रूप से, हमेशा एक आंतरिक उत्पाद नहीं होता है।)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/JuliaLang/julia/issues/25565#issuecomment-389144575 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ADMLbdcpeWo7M4prYz76NoqUPIkfVPP3ks5tysZlgaJpZM4ReGXu
.

कोई भी कारण मेरे लिए सम्मोहक नहीं है:

>

• इंफिक्स वैरिएंट होना अच्छा है।

हां, और नाम बदलने के बावजूद इंफिक्स नोटेशन अभी भी मौजूद हो सकता है
आंतरिक जैसा कि ऊपर बताया गया है।

>

• साधारण परिमित-आयामी पर काम करने वाले गैर-गणितज्ञों के लिए
  वेक्टर रिक्त स्थान, डॉट यूक्लिडियन आंतरिक के लिए एक अधिक परिचित नाम है
  उत्पाद। (गणितज्ञ आसानी से dot for . नाम का उपयोग करने के लिए समायोजित हो जाएंगे
  मनमाने ढंग से हिल्बर्ट रिक्त स्थान पर आंतरिक-उत्पाद फ़ंक्शन- "डॉट उत्पाद" में नहीं है
  ऐसे रिक्त स्थान के लिए अन्य संभावित अर्थ।)

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

>

• इनर और डॉट दोनों का होना भ्रमित करने वाला होगा, क्योंकि वे
  कुछ मामलों में मेल खाता है लेकिन शायद अन्य नहीं (यदि हम वर्तमान बिंदु रखते हैं
  अर्थ)।

हमें दोनों की जरूरत नहीं है, कम सामान्य नाम से छुटकारा पाएं, जिससे हम सहमत हैं
इस बिंदु पर डॉट।

>

• रैखिक बीजगणित के बाहर, आंतरिक में बहुत सी अन्य क्षमताएं हैं
  कंप्यूटर विज्ञान में अर्थ, और इसलिए यह कुछ हद तक कष्टप्रद है
  इस नाम को बेस से निर्यात करें।

रैखिक बीजगणित के बाहर मैं डॉट के लिए कई उपयोग पा सकता हूं। के लिए और भी अधिक
डॉट इंफिक्स नोटेशन का अर्थ पूरी तरह से अलग चीजें हैं।

>

मैं निश्चित स्वरूपण के साथ @juliohm की आखिरी पोस्ट को दोबारा पोस्ट कर रहा हूं।

कोई भी कारण मेरे लिए सम्मोहक नहीं है:

इंफिक्स वैरिएंट होना अच्छा है।

हां, और इनफिक्स नोटेशन अभी भी मौजूद हो सकता है, भले ही नाम बदलकर इनर हो, जैसा कि ऊपर बताया गया है।

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

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

इनर और डॉट दोनों का होना भ्रमित करने वाला होगा, क्योंकि वे कुछ मामलों में मेल खाते होंगे लेकिन शायद अन्य नहीं (यदि हम वर्तमान डॉट अर्थ रखते हैं)।

हमें दोनों की आवश्यकता नहीं है, कम सामान्य नाम से छुटकारा पाएं, जो हम मानते हैं कि इस बिंदु पर बिंदु है।

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

रैखिक बीजगणित के बाहर मैं डॉट के लिए कई उपयोग पा सकता हूं। डॉट इंफिक्स नोटेशन के लिए और भी अधिक अर्थ पूरी तरह से अलग चीजें हैं।

हां, और इनफिक्स नोटेशन अभी भी मौजूद हो सकता है, भले ही नाम बदलकर इनर हो, जैसा कि ऊपर बताया गया है।

आप निश्चित रूप से const ⋅ = inner परिभाषित कर सकते हैं, लेकिन तब आपकी शब्दावली असंगत है। मुझे लगा कि आप "डॉट उत्पाद" को सामान्य आंतरिक उत्पाद के रूप में उपयोग करना पसंद नहीं करते हैं?

गणितज्ञों को उनकी इच्छा के विरुद्ध गलत शब्दावली का प्रयोग करने के लिए बाध्य करना

गणितज्ञ जानते हैं कि शब्दावली न तो सही है और न ही गलत, यह केवल पारंपरिक या अपरंपरागत (और शायद सुसंगत या असंगत) है। (और अधिकांश लोग गणित में इसलिए नहीं जाते हैं क्योंकि उन्हें प्रिस्क्रिप्टिव स्पेलिंग का शौक है।) मेरे अनुभव में, यदि आप गणितज्ञों को बताते हैं कि क्वांटम यांत्रिकी में एक वेक्टर को "स्टेट" कहा जाता है, तो आसन्न को "डैगर" कहा जाता है, और एक दोहरे वेक्टर को "ब्रा" कहा जाता है, वे बेहद असंबद्ध होते हैं। इसी तरह, मुझे नहीं लगता कि कोई भी अनुभवी गणितज्ञ एक से अधिक बार झपकाएगा यदि आप उन्हें बताते हैं कि जूलिया में एक आंतरिक उत्पाद की वर्तनी dot(x,y) या x ⋅ y है, खासकर जब से शर्तों को पहले से ही समझा जाता है कई संदर्भों में समानार्थक शब्द। (मुझे संदेह है कि आपको कोई भी गणितज्ञ मिलेगा जो तुरंत नहीं जानता कि आप एक आंतरिक उत्पाद का जिक्र कर रहे हैं यदि आप कहते हैं "इस फ़ंक्शन स्पेस में दो कार्यों का डॉट उत्पाद लें"।)

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

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

रैखिक बीजगणित के बाहर मैं डॉट के लिए कई उपयोग पा सकता हूं। डॉट इंफिक्स नोटेशन के लिए और भी अधिक अर्थ पूरी तरह से अलग चीजें हैं।

सिवाय इसके कि जूलिया और कई अन्य प्रोग्रामिंग भाषाओं में वर्षों से dot है और यह कोई समस्या नहीं है। inner नया टूटना होगा।

अंततः, इस (या किसी अन्य) फ़ंक्शन की वर्तनी शब्दार्थ और पदावनति पथ की तुलना में एक मामूली मामला है, लेकिन मुझे लगता है कि शेष राशि dot के पक्ष में है।

आप निश्चित रूप से const = आंतरिक परिभाषित कर सकते हैं, लेकिन तब आपकी शब्दावली असंगत है। मुझे लगा कि आप "डॉट उत्पाद" को सामान्य आंतरिक उत्पाद के रूप में उपयोग करना पसंद नहीं करते हैं?

मुझे लगता है कि आप अभी भी नहीं समझे हैं। डॉट को आंतरिक उत्पाद कहने में कोई विसंगति नहीं है। यह एक आंतरिक उत्पाद है , हम में से कई लोगों के लिए एक बहुत ही विशिष्ट और बेकार है। sum(x.*y) से ज्यादा कुछ नहीं।

यदि dot शब्द का अंत जूलिया में inner के शब्दार्थ के साथ होता है, तो यह एक ऐतिहासिक आपदा होगी जिसकी मैं आपको गारंटी दे सकता हूं कि बहुत से लोग नाराज महसूस करेंगे। मैं कक्षा में प्रोफेसरों को इस तरह की चीजों की व्याख्या करते हुए देख सकता हूं: "आप जानते हैं, अब हम अपने स्थान के लिए आंतरिक उत्पाद को परिभाषित करने जा रहे हैं, लेकिन जूलिया में किसी (@stevengj) ने इसे डॉट कहने का फैसला किया।"

मैं यह सुनिश्चित करूंगा कि अगर ऐसा हो रहा है तो मैं भविष्य के संदर्भ के लिए इस धागे को स्क्रीनशॉट करूंगा।

आप अकेले @stevengj हैं जो dot शब्दावली पर जोर दे रहे हैं, किसी और ने इसका विरोध नहीं किया है। यह अच्छा होगा यदि आप निर्णय लेने से पहले इस तथ्य पर पुनर्विचार कर सकें।

यह एक आंतरिक उत्पाद है, हम में से कई लोगों के लिए एक बहुत ही विशिष्ट और बेकार है। योग (x.*y) से अधिक कुछ नहीं।

अगर आपको लगता है कि "डॉट उत्पाद" केवल में यूक्लिडियन आंतरिक उत्पाद को संदर्भित कर सकता है, तो आपको const ⋅ = inner परिभाषित नहीं करना चाहिए, आपको केवल ⋅(x::AbstractVector{<:Real}, y::AbstractVector{<:Real}) = inner(x,y) परिभाषित करना चाहिए।

आपके पास यह दोनों तरीके नहीं हो सकते हैं: या तो inner एक इन्फिक्स पर्यायवाची के रूप में ⋅ का उपयोग कर सकते हैं (जिस स्थिति में इंफिक्स ऑपरेटर आपकी भाषा में "गलत" है और नामकरण असंगत है) या इसका कोई इन्फिक्स पर्यायवाची नहीं है (एक विशेष मामले को छोड़कर)।

मैं कक्षा में प्रोफेसरों को इस तरह की चीजों की व्याख्या करते हुए देख सकता हूं: "आप जानते हैं, अब हम अपने स्थान के लिए आंतरिक उत्पाद को परिभाषित करने जा रहे हैं, लेकिन जूलिया में किसी (@stevengj) ने इसे डॉट कहने का फैसला किया।"

हा हा, मैं इस काल्पनिक नाराज प्रोफेसर से गर्मी लेने को तैयार हूं। गंभीरता से, आपको और अधिक देखने की आवश्यकता है यदि आपको लगता है कि "डॉट उत्पाद" शब्द का उपयोग केवल में ही किया जाता है, या यह कि गणितज्ञ नाराज हैं यदि इस शब्द का उपयोग अन्य हिल्बर्ट रिक्त स्थान में किया जाता है।

यह एक ऐतिहासिक आपदा होगी

गंभीरता से?

ऐसा लगता है कि यह चर्चा एक स्वागत योग्य, नागरिक और रचनात्मक वातावरण पर विचार कर सकती है। राय और पृष्ठभूमि अलग-अलग हैं, लेकिन कृपया व्यक्तिगत हमले करने या किसी पर दोषारोपण करने से बचें और मान लें कि सभी पक्ष अपनी बात पर अच्छे विश्वास के साथ बहस कर रहे हैं।

मैं कक्षा में प्रोफेसरों को इस तरह की चीजों की व्याख्या करते हुए देख सकता हूं: "आप जानते हैं, अब हम अपने स्थान के लिए आंतरिक उत्पाद को परिभाषित करने जा रहे हैं, लेकिन जूलिया में किसी (@stevengj) ने इसे डॉट कहने का फैसला किया।"

यहां यह भी ध्यान देने योग्य है कि स्टीवन _is_ एक प्रोफेसर हैं। :आँख मारना:

मैं dot को inner के पक्ष में हटाने के बारे में भी बाड़ पर हूं। dot शब्द काफी व्यापक रूप से उपयोग किया जाता है, और जूलिया में फ़ंक्शन नहीं होने पर, जब यह पायथन और MATLAB में होता है तो आश्चर्य की बात होगी। हालांकि, मुझे inner शब्द भी पसंद है, क्योंकि यह गैर-ℝⁿ वेक्टर रिक्त स्थान और विशेष रूप से मैट्रिक्स के लिए अधिक उपयुक्त है।

संयोग से, जब मैं परीक्षण कर रहा था कि जूलिया में कौन से तरीके कर रहे थे, मैंने देखा कि dot केवल वास्तविक वैक्टर/मैट्रिस पर काम करता है। क्या यह जानबूझकर है?

इनर और डॉट दोनों का होना भ्रमित करने वाला होगा, क्योंकि वे कुछ मामलों में मेल खाते होंगे लेकिन शायद अन्य नहीं (यदि हम वर्तमान डॉट अर्थ रखते हैं)।

@stevengj क्या vecdot को inner से बदलना और साथ ही $# dot रखना पूरी तरह से हास्यास्पद होगा? अभी, आप जिस सटीक समस्या का वर्णन कर रहे हैं वह पहले से मौजूद है, बस vecdot के बजाय inner के साथ।

ठीक है... आगे देख रहे हैं, लाइव सुझाव क्या हैं? क्या वे:

• व्यापक श्रेणी के लिए एक सामान्य आंतरिक उत्पाद के रूप में dot को अपनाएं। यह वैक्टर-ऑफ-वेक्टर पर पहले से ही सही ढंग से रिकर्सिव है, लेकिन हम इसे मैट्रिस आदि पर काम करेंगे ( @jebej मुझे नहीं लगता कि dot और inner दोनों उपयोगी हैं, और जैसा कि स्टीवन कहते हैं, हम कम से कम बोलचाल की भाषा में dot का उपयोग अक्सर आंतरिक उत्पाद का अर्थ करने के लिए करते हैं, और यह गलत नहीं है - यह सिर्फ शब्दावली है)।
• norm को उपरोक्त dot और सभी AbstractArray के साथ थोड़ा और सुसंगत बनाने पर विचार करें, अंततः ऑपरेटर मानदंडों के लिए opnorm ( AbstractMatrix पर) को पेश करना norm(matrix) == vecnorm(matrix) उपयुक्त बहिष्करण के बाद। इस बिंदु पर शायद हमें अब vecdot और vecnorm की आवश्यकता नहीं है?

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

@andyferris , हाँ, मुझे लगता है कि अगर हम यह परिवर्तन करते हैं तो हमें केवल dot और norm की आवश्यकता होती है (जो अब किसी भी आयाम के सरणियों या सरणियों पर पुनरावर्ती यूक्लिडियन संचालन हैं, हालांकि मानदंड के लिए हम norm(x,p) को पी-मानदंड के रूप में परिभाषित करते हैं) और opnorm , और अब vecdot या vecnorm नहीं है।

ध्यान दें कि dot में परिवर्तन एक ब्रेकिंग परिवर्तन है क्योंकि dot वर्तमान में मैट्रिक्स के वैक्टर (#22392) के लिए एक वास्तविक आंतरिक उत्पाद नहीं है, कुछ ऐसा जिस पर #22220 में लंबे समय तक बहस हुई थी ( जिस बिंदु पर vecdot को समाप्त करना IIRC नहीं माना गया था)। हालाँकि, इसे 0.7 में पेश किया गया था, इसलिए यह किसी भी वास्तविक रिलीज़ कोड को नहीं तोड़ता है। वास्तव में, dot में 0.6 पहले से ही यूक्लिडियन डॉट उत्पाद है जो मनमाने-आयामी सरणियों पर है, कुछ हद तक दुर्घटना से (#22374)। यहां सुझाया गया परिवर्तन उस 0.6 व्यवहार को पुनर्स्थापित और विस्तारित करेगा और इसके अनुरूप होने के लिए norm को बदल देगा।

एक सवाल यह है कि क्या norm(x,p) norm(x[i]) या norm(x[i],p) $ को बार-बार कॉल करेगा। दोनों संभावित रूप से उपयोगी व्यवहार हैं। मैं पूर्व की ओर झुकता हूं क्योंकि यह अधिक सामान्य है - x[i] कुछ मनमाना आदर्श वेक्टर स्थान हो सकता है जो केवल norm को परिभाषित करता है लेकिन पी-मानदंड नहीं। norm को पुनरावर्ती रूप से कॉल करना भी वही है जो अब vecnorm करता है, इसलिए यह vecnorm से norm को पदावनत करने के अनुरूप है।

@jebej , dot दोनों मास्टर पर और 0.6 मेरे लिए जटिल सरणियों पर काम करता है: dot([3im],[4im]) उदाहरण के लिए, 12+0im $ सही ढंग से लौटाता है।

norm(matrix) को फ्रोबेनियस मानदंड में बदलने के बारे में एक और अच्छी बात यह है कि यह बहुत सस्ता है। दो मैट्रिक्स के बीच कितना बड़ा अंतर है, यह समझने के लिए केवल norm(A-B) का उपयोग करना आम बात है, लेकिन मानदंड की विशिष्ट पसंद के बारे में बहुत अधिक परवाह नहीं करना है, लेकिन कई उपयोगकर्ताओं को यह नहीं पता होगा कि वर्तमान डिफ़ॉल्ट norm(matrix) के लिए हमें SVD की गणना करने की आवश्यकता है।

कई प्रमुख बिंदुओं पर आम सहमति बनते देखना अद्भुत है! :) (जब तक कोई मुझे इसके लिए हरा नहीं देता (कृपया करें यदि आपके पास बैंडविड्थ है!) या एक अल्फा टैग पहले हिट होता है, तो मैं वर्तमान सर्वसम्मति बिंदुओं को # 26997 शिपिंग के बाद एक शॉट को लागू करने दूंगा।) सर्वश्रेष्ठ!

भविष्य के संदर्भ के लिए एक और लिंक: https://math.stackexchange.com/a/476742

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

और भविष्य के पाठकों के लिए, इसके बजाय क्या किया जाना चाहिए था, हमारे पास सामूहिक निर्णय था:

# make dot what it is, a NOTATION
⋅(x::AbstractVector, y::AbstractVector) = sum(x[i]*y[i] for i in indices(x))

# replace the name dot by the more general inner
inner(x, y) = # anything

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

बहुत अच्छा निर्णय लेना: ताली: यह निश्चित रूप से एक आम सहमति थी। ऊपर दी गई टिप्पणियों को पढ़ें, और आप देखेंगे कि सभी कैसे सहमत हुए। :+1:

या शायद मुझे कुछ टिप्पणियों को उद्धृत करना चाहिए ताकि यह बहुत स्पष्ट हो कि यह आम सहमति कैसे थी:

>

दाएं - vecdot को आंतरिक नाम दिया जा सकता है

द्वारा @andyferris

विकल्प 2 (शायद बेहतर): अधिक गणितीय रूप से सही नामों का उपयोग करें

भीतरी
आयाम
लेकिन आदर्श के साथ क्या करना है?

द्वारा @Jutho

मैं सहमत हूं, vecdot के विकल्प के रूप में हम एक नई विधि इनर पेश कर सकते हैं

द्वारा @Jutho

मुझे vecdot नाम भी अजीब लगता है, वास्तव में, मुझे यह भी नहीं पता था कि यह अस्तित्व में है और इसके लिए मैंने अपना कार्य किया है ... आंतरिक कहा जाता है।

द्वारा @jebej

और बहुत सारे...

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

(ऐसा नहीं है कि कोई अंतिम निर्णय लिया गया है, निश्चित रूप से - अभी तक एक पीआर भी नहीं है, बहुत कम कुछ भी विलय हो गया है।)

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

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

@juliohm , सभी तर्क इस बात पर आधारित हैं कि हम दर्शकों को कौन सोचते हैं, और हम सभी जूलिया को यथासंभव अच्छी भाषा बनाने की कोशिश कर रहे हैं। तर्कसंगत लोग शब्दावली के बारे में अलग-अलग निष्कर्ष पर आ सकते हैं, क्योंकि गणित वर्तनी का निर्धारण नहीं करता है।

सबसे पहले, जैसा कि ऊपर उल्लेख किया गया है, मैं निश्चित रूप से @stevengj के वर्तमान प्रस्ताव से सहमत हो सकता हूं और आंतरिक उत्पाद के सामान्य नाम के रूप में dot पर टिका रह सकता हूं। साथ ही, जिस तरह से यह चर्चा चल रही है, मैं उसे नापसंद करता हूं और निश्चित रूप से सही ढंग से उद्धृत करना चाहूंगा। @juliohm , दूसरा उद्धरण जो आपने मुझे दिया है वह मेरा नहीं है।

कहा जा रहा है, मैं पेशेवरों और विपक्षों के विचार में विचार के लिए भोजन के रूप में निम्नलिखित का उल्लेख करना चाहता हूं। निम्नलिखित ज्यादातर विपक्ष हैं, लेकिन मैं @stevengj द्वारा उल्लिखित पेशेवरों से सहमत हूं। dot बस मतलब sum(x[i]*y[i] for i ...) होने के लिए अलग-अलग उपयोग के मामले आसानी से हो सकते हैं। उन मामलों में जहां गणित में इंफिक्स डॉट नोटेशन का सबसे अधिक उपयोग किया जाता है, यह वास्तव में आम तौर पर अर्थ होता है। एक आंतरिक उत्पाद के रूप में, इंफिक्स डॉट नोटेशन आम तौर पर (हालांकि निश्चित रूप से विशेष रूप से नहीं) वास्तविक वेक्टर रिक्त स्थान के लिए आरक्षित होता है। अन्य उपयोग के मामलों में σ ⋅ n के साथ σ पाउली मैट्रिसेस का एक वेक्टर और n स्केलर का एक वेक्टर जैसी चीजों को सक्षम करना शामिल है। जिस तरह से dot वर्तमान में लागू किया गया है, उसके पीछे यह एक प्रेरणा थी, जैसा कि मुझे किसी अन्य सूत्र में बताया गया था। तथ्य यह है कि बीएलएएस ने वास्तविक वैक्टर के लिए केवल dot का उपयोग करने और जटिल वैक्टर के लिए dotu और dotc के बीच अंतर करने का निर्णय लिया है, यह विचार करने के लिए एक और मुद्दा है। बीएलएएस पृष्ठभूमि वाले लोग भ्रमित हो सकते हैं, जटिल वैक्टर होने पर, वे dot(conj(u),v) या dot(u,v) की गणना करना चाहते हैं, जब वे वास्तविक आंतरिक उत्पाद (यानी dotc ) चाहते हैं। इसके अलावा, वे पहले हाथ में वेक्टर की संयुग्मित प्रतिलिपि बनाये बिना dotu करने का एक तरीका ढूंढ सकते हैं।

@Jutho बोली आपकी है, आपकी पूरी टिप्पणी नीचे कॉपी की गई है:

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

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

@ जुथो : इसके अलावा, वे dotu करने का एक तरीका ढूंढ सकते हैं, पहले हाथ में वेक्टर की संयुग्मित प्रतिलिपि बनाये बिना।

dotu फ़ंक्शन के निर्यात की संभावना समय-समय पर सामने आई है (उदाहरण के लिए #8300 देखें)। मैं मानता हूं कि यह कभी-कभी एक उपयोगी कार्य होता है: एक गैर-संयुग्मित यूक्लिडियन "आंतरिक उत्पाद" (अब वास्तव में एक आंतरिक उत्पाद नहीं) जो एक सममित बिलिनियर है (सेसक्विलिनियर नहीं) dotu(x,y) == dotu(y,x) (संयुग्मित नहीं) जटिल वेक्टर रिक्त स्थान के लिए भी . लेकिन उस ऑपरेशन की उपयोगिता ℂⁿ तक सीमित नहीं है - उदाहरण के लिए, इस तरह का उत्पाद अक्सर मैक्सवेल के समीकरणों के लिए अनंत-आयामी वेक्टर रिक्त स्थान (फ़ंक्शंस) में दिखाई देता है, जो पारस्परिकता के परिणामस्वरूप होता है (अनिवार्य रूप से: विशिष्ट हानिपूर्ण सामग्री में मैक्सवेल ऑपरेटर है एक "जटिल-सममित मैट्रिक्स" के अनुरूप - असंबद्ध "आंतरिक उत्पाद" के तहत सममित)। इसलिए, यदि हम dot(x,y) को सामान्य यूक्लिडियन आंतरिक उत्पाद (संयुग्मित पहले तर्क के साथ) के रूप में परिभाषित करते हैं, तो किसी भी वेक्टर स्थान पर असंबद्ध यूक्लिडियन उत्पाद के लिए dotu(x,y) फ़ंक्शन को परिभाषित करना काफी स्वाभाविक होगा। जहां यह समझ में आता है। हालांकि, मुझे dotu फ़ंक्शन की संभावना dot के विरुद्ध तर्क के रूप में दिखाई नहीं दे रही है। अधिकांश मामलों में, जब आप जटिल वेक्टर रिक्त स्थान के साथ काम कर रहे होते हैं तो आप संयुग्मित उत्पाद चाहते हैं, इसलिए यह सही डिफ़ॉल्ट व्यवहार है।

लेकिन मैं मानता हूं कि एक संभावना dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) को परिभाषित करने की होगी, जो कि वर्तमान में मास्टर (0.6 नहीं) में परिभाषित है, और inner(x,y) को सही डॉट उत्पाद के रूप में परिभाषित करता है। यह दोनों कार्यों की आपूर्ति का लाभ है, जो दोनों कुछ मामलों में उपयोगी हो सकते हैं। हालांकि, हमारे पास दो कार्य हैं जो लगभग हमेशा मैट्रिस के सरणी को छोड़कर मेल खाते हैं, और मुझे संदेह है कि यह तय करना थोड़ा उलझन में होगा कि एक या दूसरे का उपयोग कब करना है। बहुत से लोग dot लिखेंगे जब उनका मतलब inner था, और यह ज्यादातर मामलों में उनके लिए ठीक काम करेगा, लेकिन फिर उनका कोड कुछ अप्रत्याशित करेगा यदि यह मैट्रिक्स की एक सरणी पारित हो जाती है। मेरा संदेह यह है कि 99% मामलों में लोग वास्तविक आंतरिक उत्पाद चाहते हैं, और "उत्पाद का योग" संस्करण एक पैकेज पर छोड़ा जा सकता है, यदि वास्तव में इसकी आवश्यकता है (जैसा कि केवल sum पर कॉल करने के विपरीत है) )

@juliohm , मैंने आपकी पोस्ट को गलत तरीके से पढ़ा क्योंकि मुझे लगा कि नाम ऊपर (नीचे के बजाय) संबंधित उद्धरण हैं, इसलिए मैंने सोचा कि आपने @jebej के उद्धरण को मेरे लिए जिम्मेदार ठहराया है। उसके लिए मेरी माफ़ी।

@stevengj , मैं निश्चित रूप से उचित डिफ़ॉल्ट के रूप में dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) होने के बारे में नहीं सोच रहा था। σ ⋅ n जैसे मामले में, पहले या दूसरे तर्क का जटिल/हर्मिटियन संयुग्मन अनावश्यक है। तो मैं जो कह रहा था, वह यह है कि, कई (लेकिन वास्तव में सभी नहीं) मामलों में जहां वैज्ञानिक सूत्रों में इंफिक्स डॉट नोटेशन का उपयोग किया जाता है, इसका अर्थ dotu के साथ मेल खाता है, यानी sum(x[i]*y[i] for i = 1:length(x)) बिना संयुग्मन के, या तो वास्तविक वेक्टर रिक्त स्थान पर आंतरिक उत्पाद के रूप में या कुछ और सामान्य निर्माण के रूप में।

इसलिए यदि मुझे कोई वैकल्पिक प्रस्ताव देना है (हालाँकि मैं आवश्यक रूप से इसकी वकालत नहीं कर रहा हूँ), तो उसके दो कार्य होंगे:

• dot(x,y) = sum(x[i]*y[i] for i...) , जो अभी भी वास्तविक वैक्टर के लिए सही आंतरिक उत्पाद है (जो संभवतः उन लोगों के उपयोग का मामला है जो आंतरिक उत्पाद शब्द से कम या परिचित नहीं हैं) लेकिन σ ⋅ n जैसे अधिक सामान्य निर्माणों की भी अनुमति देता है

• inner(x,y) संयुग्मन और पुनरावर्तन के साथ हमेशा मान्य आंतरिक उत्पाद होने के नाते, जिसका उपयोग तकनीकी संदर्भों में अधिक सामान्य लोगों द्वारा किया जाएगा।

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

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

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

• असंबद्ध: Numpy dot (और, विचित्र रूप से, आंतरिक ), Mathematica's Dot , Maxima . , BLAS dotu

• संयुग्मित: मैटलैब का dot , फोरट्रान का DOT_PRODUCT , मेपल का DotProduct , पेट्स का VecDot , Numpy vdot , BLAS dotc (ध्यान दें कि की कमी फोरट्रान 77 में ओवरलोडिंग ने इस dot को कॉल करना असंभव बना दिया, भले ही वे चाहें), Eigen's dot

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

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

(मैं सहमत हूं कि ⟨u,v⟩ , ⟨u|v⟩ , या (u,v) मनमाने ढंग से हिल्बर्ट रिक्त स्थान पर आंतरिक उत्पादों के लिए अधिक सामान्य नोटेशन हैं-वे वही हैं जो मैं आमतौर पर स्वयं का उपयोग करता हूं-लेकिन वे नोटेशन एक हैं जूलिया के लिए नॉनस्टार्टर। यूनिकोड ब्रैकेट को फ़ंक्शन/मैक्रो कॉल के रूप में पार्स करने की कुछ चर्चा थी, उदाहरण के लिए # 8934 और # 8892, लेकिन यह कभी भी कहीं नहीं गया और ऐसा लगता है कि जल्द ही बदलने की संभावना नहीं है।)

मैं आपके आकलन @stevengj से पूरी तरह सहमत हूं।

मैं भी।

मुझे संदेह है कि हम में से किसी एक के लिए पीआर में कार्यान्वयन के साथ खेलने का समय है और देखें कि यह कैसे निकलता है।

@ जुथो मैंने हमेशा उच्च ऑर्डर टेंसर पर संकुचन के लिए पाउली मैट्रिस के साथ डॉट उत्पाद को शॉर्टहैंड के रूप में देखा ... वेक्टर रिक्त स्थान में से एक वास्तविक, 3 डी है।

मैं सहमत हूं कि u,v⟩, ⟨u|v⟩, या (u,v) मनमाने ढंग से हिल्बर्ट रिक्त स्थान पर आंतरिक उत्पादों के लिए अधिक सामान्य नोटेशन हैं-वे वही हैं जो मैं आमतौर पर स्वयं का उपयोग करता हूं-लेकिन वे नोटेशन जूलिया के लिए एक नॉनस्टार्टर हैं।

वास्तव में ⟨u,v⟩ काम करना संभव होगा।

@StefanKarpinski : वास्तव में ⟨u, v⟩ काम करना संभव होगा।

बिल्कुल, और इस सटीक संकेतन का समर्थन #8934 में किया गया था, लेकिन यह कभी भी कहीं नहीं गया। (यह भी ध्यान दें कि कोण कोष्ठक के अन्य सामान्य उपयोग हैं, उदाहरण के लिए u⟩ अक्सर किसी प्रकार के औसत को दर्शाता है।) यह गैर-ब्रेकिंग है और अभी भी किसी बिंदु पर जोड़ा जा सकता है, लेकिन निकट में अपेक्षा करना उचित नहीं लगता है अवधि। \langle<tab> x, y \rangle<tab> टाइप करना भी काफी धीमा है, इसलिए प्राथमिक ऑपरेशन के लिए प्रोग्रामिंग दृष्टिकोण से यह बहुत सुविधाजनक नहीं है।

और हम इसके लिए <> ओवरलोड नहीं कर सकते हैं, है ना?

नहीं

मैं यह नहीं कह सकता कि मैंने इस विनम्र सूत्र पर प्रत्येक टिप्पणी को पढ़ा है, लेकिन मैं केवल कुछ बिंदुओं को उजागर करना चाहता हूं, जिनमें से कुछ पहले किए जा चुके हैं:

• डॉट और इनर के बीच अंतर करना अत्यधिक पांडित्यपूर्ण लगता है। वास्तव में मेरे कानों में यह निरर्थक लगता है क्योंकि फ्रेंच में सिर्फ एक शब्द है - "स्केलर उत्पाद" - और उन चीजों के बीच अंतर करना मुश्किल है जो मेरे लिए एक ही नाम है ;-)
• जब आप सुन्न से आ रहे हैं और जटिल सरणियों के साथ काम कर रहे हैं, तो dot डिफ़ॉल्ट रूप से संयुग्मित होना सबसे अच्छी बात है। यहां कोई निर्णय बिंदु नहीं है, मैं केवल यह कहना चाहता था कि मुझे कितनी खुशी है कि मुझे अब ये conj(dot()) s नहीं करना है!
• ज्यादातर मामलों में समान व्यवहार वाले दो कार्यों का होना, लेकिन कभी-कभी भिन्न होता है, खराब डिज़ाइन होता है, और भ्रम पैदा करता है, कोड के साथ जो वास्तव में दूसरे को कॉल करना चाहिए, केवल इसलिए कि उपयोगकर्ता बेहतर नहीं जानता है। यह norm के साथ विशेष रूप से कष्टप्रद है: यदि आप एक अनुकूलन एल्गोरिथ्म को कोड कर रहे हैं और जब भी norm(delta x) < eps को रोकना चाहते हैं, तो आप लिखने जा रहे हैं norm । लेकिन फिर आप एक छवि या कुछ wrt को अनुकूलित करना चाहते हैं, आप अपना कोड चलाते हैं, और यह अचानक एक बड़ी सरणी के एक अनजान (क्योंकि बीएलएएस) एसवीडी में लॉन्च होता है। यह अकादमिक नहीं है, इसने Optim.jl में परेशानी पैदा की है, और निस्संदेह अन्य पैकेजों में भी। किसी को पता नहीं चलेगा कि vecnorm मौजूद है जब तक कि उनके पास इसे खोजने का कोई विशिष्ट कारण न हो।
• पिछले बिंदु के आधार पर, कोई भी समाधान जो dot और vecdot , और norm और vecnorm को मर्ज करता है, अच्छा है, भले ही यह थोड़ा लचीलापन हटा देता है सरणी-से-सरणी मामले। मानदंडों के लिए, मैं अक्सर उन चीजों के साथ काम करता हूं जिन पर कई मानदंड परिभाषित होते हैं (उदाहरण के लिए मैट्रिस), उपयोगकर्ता जो चाहता है वह मानक प्राप्त करने के लिए norm पर कॉल करना है, विशेष रूप से परवाह किए बिना। प्रेरित मानदंड उनकी कम्प्यूटेशनल अट्रैक्टिवता के कारण व्यावहारिक रुचि के बजाय अक्सर सैद्धांतिक होते हैं। वे 2D-सरणी-के रूप में-संचालक व्याख्या के लिए भी विशिष्ट हैं, न कि 2D-सरणी-के रूप में-भंडारण एक (एक छवि एक 2D सरणी है, लेकिन यह किसी भी उपयोगी अर्थ में एक ऑपरेटर नहीं है)। उनकी गणना करने की संभावना होना अच्छा है, लेकिन वे डिफ़ॉल्ट norm होने के योग्य नहीं हैं। उचित, सरल और अच्छी तरह से प्रलेखित चूक जिनमें खोज योग्य विकल्प हैं, प्रयास की गई चतुराई से बेहतर हैं (यदि उपयोगकर्ता एक चतुर काम करना चाहता है, तो उन्हें इसे स्पष्ट रूप से करने दें)।

इसलिए, @stevengj 's . पर +1 करें

हां, मुझे लगता है कि यदि हम यह परिवर्तन करते हैं तो हमें केवल डॉट और मानदंड की आवश्यकता होती है (जो अब किसी भी आयाम के सरणियों या सरणियों पर पुनरावर्ती यूक्लिडियन संचालन हैं, हालांकि आदर्श के लिए हम मानदंड (x, p) को भी परिभाषित करते हैं। p-norm) और opnorm, और अब vecdot या vecnorm नहीं है।

मानदंड/opnorm के लिए एक अधिक "जूलियन" विकल्प में एक ऑपरेटर प्रकार हो सकता है, जो एक 2D सरणी लपेट सकता है, जिस पर norm opnorm करता है। यह पैकेज के स्तर पर किया जा सकता है (जिनमें से कई पहले से मौजूद हैं)

मैं $# norm(Operator(matrix)) के बजाय opnorm(matrix) टाइप करना पसंद करूंगा ...

मैं यहां मूंगफली गैलरी से झंकार करने जा रहा हूं और कहता हूं कि मुझे यह पसंद है कि यह कहां जा रहा है- vecnorm और vecdot ने मुझे हमेशा परेशान किया है। ऑपरेटर मानदंड के लिए स्पष्ट रूप से पूछने की आवश्यकता है - जो हमेशा मेरे लिए काफी विशिष्ट प्रतीत होता है - एक ऐसे मानदंड के लिए पूछने की तुलना में बहुत अधिक समझदार लगता है जो गणना करने के लिए बहुत तेज़ और आसान है (उदाहरण के लिए फ्रोबेनियस मानदंड)। opnorm लिखना अपेक्षाकृत विशिष्ट ऑपरेटर मानदंड के लिए पूछने के लिए एक बढ़िया इंटरफ़ेस की तरह लगता है।

मुझे यह भी लगता है कि dot और inner के बीच एक सूक्ष्म अंतर होने से भ्रम और बड़े पैमाने पर दुरुपयोग होने की संभावना है। उपयोगकर्ताओं को इस बारे में व्याख्यान देना कि वे किस फ़ंक्शन का उपयोग करने के लिए _supposed_ हैं, जब दोनों फ़ंक्शन वही करते हैं जो वे चाहते हैं और उनमें से एक आसान है तो बहुत अच्छी तरह से काम नहीं करता है। मेरी धारणा यह है कि सामान्य कोड में यह अपेक्षाकृत दुर्लभ है कि sum(x*y for (x,y) in zip(u,v)) वास्तव में वही है जो आप चाहते हैं जब एक वास्तविक आंतरिक उत्पाद ⟨u,v⟩ वास्तव में मौजूद हो। जब यह वास्तव में वही है जो चाहता है, यह काफी आसान, स्पष्ट और कुशल है (क्योंकि जूलिया यही है) इसे गणना करने के लिए बस ऐसा कुछ लिखना है।

u⋅v फ़ंक्शन को कॉल करना है या नहीं dot या inner इस सब का कम से कम परिणामी हिस्सा लगता है। मुझे पूरा यकीन है कि इतिहासकारों द्वारा किसी भी विकल्प को एक आपदा के रूप में वापस नहीं देखा जाएगा-हालांकि यह धारणा कि इतिहासकारों की बिल्कुल परवाह होगी, निश्चित रूप से चापलूसी है। एक ओर, यदि हम u⋅v के "सच्चे आंतरिक उत्पाद" का अर्थ रखने के लिए सहमत हैं तो हाँ, inner अधिक सही गणितीय शब्द है। दूसरी ओर, जब संबंधित फ़ंक्शन नाम के साथ एक सिंटैक्स होता है, तो यह उपयोगकर्ताओं को कम भ्रमित करता है जब नाम सिंटैक्स से मेल खाता है। चूंकि यहां सिंटैक्स एक बिंदु का उपयोग करता है, इसलिए अंगूठे का वह नियम इस ऑपरेशन को dot के रूप में वर्तनी का समर्थन करता है। शायद यह const dot = inner को परिभाषित करने और दोनों को निर्यात करने के लिए एक उचित मामला हो सकता है? तब लोग जो भी नाम पसंद करते हैं उसका उपयोग या विस्तार कर सकते हैं क्योंकि वे एक ही चीज़ हैं। यदि कोई किसी अन्य नाम का उपयोग किसी और चीज़ के लिए करना चाहता है, और दूसरा नाम अपने डिफ़ॉल्ट अर्थ के साथ उपलब्ध रहेगा। बेशक यह एक ही फ़ंक्शन के लिए तीन निर्यात किए गए नाम बना देगा- dot , inner और ⋅ - जो थोड़ा अधिक लगता है।

क्या यह ⋅ प्रतीक को हटाने या इसे <u,v> से बदलने का विकल्प है?

टिप्पणियाँ:

• इससे नीयत साफ हो जाती है। इन दो उदाहरणों की तुलना करें:

<u,v> * M * x

बनाम

u ⋅ v * M * x

• <u,v> सिंटैक्स का मतलब एसोसिएशन है: पहले हम u और v पर काम करते हैं और फिर बाकी एक्सप्रेशन इस प्रकार है।

• यदि किसी उपयोगकर्ता ने <u,v> टाइप करने का प्रयास किया है, तो यह बहुत कम संभावना है कि उसके मन में एक साधारण sum(x[i]*y[i]) हो। प्रतीक ⋅ आंखों से छोड़ना आसान है, और इसके कई अन्य अर्थ हैं। विशेष रूप से, रैखिक बीजगणित में, एक क्षेत्र F के ऊपर एक सदिश स्थान V के लिए, एक अदिश α ∈ F का सदिश v ∈ V के गुणनफल को विभिन्न पाठ्यपुस्तकों में α ⋅ v के रूप में दर्शाया जाता है।

• ⋅ को हटाने या बदलने से कई नामों के निर्यात की समस्या भी समाप्त हो जाएगी। सामान्य आंतरिक उत्पादों के लिए केवल inner और <,> का निर्यात करना होगा, पुनरावर्तनीय योग अर्थशास्त्र से मेल खाने वाले सरणी के लिए डिफ़ॉल्ट कार्यान्वयन के साथ।

• यदि किसी को फ़ील्ड F पर वेक्टर स्पेस V के लिए ऊपर वर्णित स्केलर-बाय-वेक्टर उत्पाद को परिभाषित करने की आवश्यकता है, तो वह इसके लिए ⋅ नोटेशन को परिभाषित करने में सक्षम होगा। फिर वेक्टर स्पेस को अच्छे शॉर्ट सिंटैक्स के साथ पूरी तरह से परिभाषित किया जाएगा, और <u,v> को और परिभाषित करके हिल्बर्ट स्पेस तक बढ़ाया जा सकता है।

हम निश्चित रूप से सिंटैक्स का उपयोग नहीं कर सकते <u,v> ; हम जिस सिंटैक्स का उपयोग कर सकते हैं वह है ⟨u,v⟩ - यूनिकोड कोष्ठकों पर ध्यान दें, संकेतों से कम और बड़ा नहीं, < और > । हमारे पास u'v किसी ऐसी चीज़ के लिए सिंटैक्स के रूप में है जो या तो एक डॉट उत्पाद या एक आंतरिक उत्पाद है? (मुझे यकीन नहीं है कि कौन सा ...)

हाँ, क्षमा करें, इसका यूनिकोड संस्करण। पढ़ना बहुत स्पष्ट होगा। यह इस मुद्दे को कई नामों से भी हल करेगा, और अन्य उद्देश्यों के लिए ⋅ निःशुल्क होगा।

मुझे नहीं लगता कि हम किसी अन्य उद्देश्य के लिए ⋅ का उपयोग करना चाहते हैं—ऐसा लगता है कि यह भ्रमित करने वाला होगा।

बस कल्पना कीजिए कि ऐसा कोड लिखने में सक्षम होना कितना अद्भुत होगा:

⟨α ⋅ u, v⟩ + ⟨β ⋅ w, z⟩

अमूर्त वैक्टर (या प्रकार) के u,v,w,z ∈ V और अदिश α, β ∈ F ।

u'v केवल 1d सरणियों के लिए एक आंतरिक उत्पाद (और एक डॉट उत्पाद, यदि आप संयुग्मित सम्मेलन का पालन करते हैं) है, उदाहरण के लिए मैट्रिस के लिए नहीं। (यह एक और कारण है कि इन्फिक्स डॉट को 1d सरणियों तक सीमित करना व्यर्थ है, क्योंकि हमारे पास उस मामले के लिए पहले से ही एक संक्षिप्त अंकन है।)

स्टीफन, "सही गणितीय शब्द" एक श्रेणी त्रुटि है-गणितीय शुद्धता एक अवधारणा नहीं है जो शब्दावली/नोटेशन पर लागू होती है। ("सही" के लिए "पारंपरिक" को प्रतिस्थापित करें, लेकिन तब चिंता कम जरूरी हो जाती है,)

अधिक उपयोग के मामले: https://stackoverflow.com/questions/50408177/julia-calculate-an-inner-product-using-boolean-algebra

और ⟨,⟩ संकेतन का उपयोग करके बूलियन आंतरिक उत्पादों की औपचारिक व्युत्पत्ति: https://arxiv.org/abs/0902.1290

संपादित करें: कागज के लिए निश्चित लिंक

आप कोण कोष्ठक वाक्य रचना प्रस्ताव के बारे में क्या सोचते हैं? क्या इससे यहां उठाए गए मुद्दों का समाधान होगा?

तो आपका प्रस्ताव वास्तव में क्या है? क्या यह मोटे तौर पर है:

1. dot को inner से हटा दें
2. u⋅v को ⟨u,v⟩ से हटा दें

तो फिर कोई dot फ़ंक्शन नहीं होगा और कोई ⋅ ऑपरेटर नहीं होगा?

क्या वह बदलाव कुछ उचित होगा?

उत्तर देने में देरी के लिए क्षमा करें, मैं इंटरनेट तक सीमित पहुंच वाले सम्मेलन में हूं।

और केवल स्पष्टता और पूर्णता के लिए, यहाँ प्रतिप्रस्ताव क्या है? कुछ मत करो?

प्रस्ताव को और भी स्पष्ट करने के लिए, इसमें अर्थ परिवर्तन शामिल है: सामान्यीकृत आंतरिक उत्पाद।

सावधान: अब हमने इस पर उस बिंदु तक बहस की है जहां एक वास्तविक जोखिम है, यह इसे 0.7-अल्फा में नहीं बनाएगा। इसका मतलब यह नहीं है कि इसे अल्फा के बाद नहीं बदला जा सकता है, लेकिन उसके बाद चीजों को बदलने के लिए बहुत अधिक अनिच्छा होगी।

हां, काश मेरे पास बहुत समय पहले पीआर जमा करने का कौशल होता। ऐसा करना मेरी क्षमता से परे है, भले ही मैं इसे अत्यंत महत्वपूर्ण विशेषता मानता हूं।

यहां तक ​​​​कि ऑपरेटर सिंटैक्स प्रश्न को छूट देते हुए, सिमेंटिक अवधारणाओं के प्रत्येक सेट (वर्तमान dot और vecdot और वर्तमान norm और vecnorm के लिए नाम छायांकन और बहु-चरण बहिष्करण के साथ अभी भी कुछ जटिलता है

dot पक्ष के लिए ऐसा लगता है कि विकल्पों की पूरी जगह (फिर से छूट देने वाले ऑपरेटरों) है:

I. 0.7 में व्यवहार को मानक डिवार्न के बिना एक आंतरिक उत्पाद में बदलकर सरणियों के वैक्टर पर चुपचाप dot को तोड़ दें (हालांकि आप चेतावनी दे सकते हैं कि व्यवहार बदला जा रहा है)। vecdot से dot को 0.7 में भी हटा दें।
द्वितीय. 0.7 में, सभी इनपुट पर vecdot को हटा दें inner ।
III. 0.7 में, इसकी परिभाषा के लिए सरणियों के वैक्टर पर dot , और अन्य इनपुट पर dot और सभी इनपुट पर inner $ पर vecdot को हटा दें।
चतुर्थ। 0.7 में, दोनों dot और vecdot को सरणियों के वैक्टर पर या तो निर्यात न किए गए कार्यों या उनकी परिभाषाओं के लिए, और vecdot को अन्य सभी इनपुट पर dot पर हटा दें। 1.0 में, आंतरिक उत्पाद शब्दार्थ के साथ सरणियों के वैक्टर पर dot जोड़ें।

आदर्श पक्ष के लिए एक पथ के आसपास कुछ आम सहमति है (0.7 में, norm को मैट्रिक्स पर opnorm पर हटा दें और संभावित रूप से vecnorm से innernorm को हटा दें; 1.0 में , मौजूदा vecnorm शब्दार्थ के साथ मैट्रिक्स पर norm जोड़ें, लेकिन इसके परिणामस्वरूप 1.0 में एक अतिरिक्त नाम भी मिलता है (या तो vecnorm या innernorm ); फिर से इससे बचने का एक तरीका यह हो सकता है कि vecnorm को 0.7 में इसकी परिभाषा से हटा दिया जाए या किसी निर्यात किए गए नाम के बजाय Base.vecnorm जैसे अनएक्सपोर्टेड फंक्शन को हटा दिया जाए।

...मेरे विचार से। आशा है कि मैंने चीजों को पहले से ज्यादा मुफीद नहीं बनाया।

क्या कोडबेस से परिचित कोई व्यक्ति परिवर्तन के लिए पीआर जमा कर सकता है?

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

@StefanKarpinski , ध्यान दें कि वे कुछ हद तक युग्मित हैं: उन प्रकारों के लिए जहां आपके पास एक डॉट (आंतरिक) उत्पाद और एक मानदंड दोनों हैं, वे सुसंगत होना चाहिए।

ठीक है, मुझे वास्तव में परवाह नहीं है कि यह किस तरफ जाता है। जो काम करेगा वही तय करेगा।

मेरे पास vecdot को वास्तविक आंतरिक उत्पाद के रूप में व्यवहार करने के लिए एक पीआर ( #25093 ) था (और इसी मानदंड के रूप में vecnorm ), उन्हें पुनरावर्ती बनाकर। यह शुरुआती बिंदु के रूप में उपयोगी हो सकता है कि भविष्य dot और norm कैसा दिखना चाहिए। दुर्भाग्य से, मेरे गिट कौशल की कमी ने मुझे उस पीआर को खराब कर दिया, इसलिए मैंने इसे बंद कर दिया, नए पुनरावृत्ति वाक्यविन्यास के पूरा होने के बाद इसे वापस करने की योजना बना रहा था।

हालांकि, कुछ दिनों पहले दूसरी बार पिता बनने का मतलब है कि मेरे कैलेंडर में वर्तमान में कोई "खाली समय" स्लॉट नहीं है।

अभी कुछ दिन पहले दूसरी बार पिता बने हैं

बधाई हो जूथो! मैं

हाँ, बधाई!

ऐसा लगता है कि dot और inner दोनों होने के विचार के आसपास कुछ आम सहमति बन सकती है, जहां:

1. inner एक सच्चा पुनरावर्ती आंतरिक उत्पाद है
2. dot = dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) संयुग्मित है या नहीं, और इसलिए Vector{<:Number} या Vector{<:Real} $ के लिए $ dot के साथ ओवरलैप होगा

के बारे में:

बहुत से लोग डॉट लिखते हैं जब उनका मतलब आंतरिक होता है, और यह ज्यादातर मामलों में उनके लिए ठीक काम करेगा, लेकिन फिर उनका कोड कुछ अप्रत्याशित होगा यदि इसे मैट्रिक्स की एक सरणी पास की जाती है।

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

मुझे लगता है कि उपरोक्त एक महान परिवर्तन होगा, और बहुत विघटनकारी नहीं होगा क्योंकि अधिकांश मामलों में dot के शब्दार्थ नहीं बदले गए हैं।

ऐसा लगता है कि dot और inner दोनों के विचार के आसपास कुछ आम सहमति बन सकती है।

इसके विपरीत, https://github.com/JuliaLang/julia/issues/25565#issuecomment -390069503 पर चर्चा एक या दूसरे के पक्ष में प्रतीत होती है, लेकिन दोनों नहीं, जैसे कि https://github में निर्धारित की गई है। com/JuliaLang/julia/issues/25565#issuecomment -390388230 और प्रतिक्रियाओं के साथ अच्छी तरह से समर्थित।

शायद inner (और साथ ही dot ) पुनरावर्ती आंतरिक/डॉट/स्केलर उत्पाद होना चाहिए और पुराने व्यवहार को dotc(x,y) = sum(x[i]' * y[i] for i in eachindex(x)) और dotu(x,y) = sum(transpose(x[i]) * y[i] for i in eachindex(x)) जैसे कार्यों में लागू किया जा सकता है। ? dotu और dotc नाम संबंधित BLAS नामों से मेल खाएंगे।

(मैं मानता हूं कि ⟨u,v⟩, ⟨u|v⟩, या (u,v) मनमाने ढंग से हिल्बर्ट रिक्त स्थान पर आंतरिक उत्पादों के लिए अधिक सामान्य नोटेशन हैं-वे वही हैं जो मैं आमतौर पर स्वयं का उपयोग करता हूं-लेकिन वे नोटेशन जूलिया के लिए एक नॉनस्टार्टर हैं . यूनिकोड ब्रैकेट को फ़ंक्शन/मैक्रो कॉल के रूप में पार्स करने की कुछ चर्चा हुई, उदाहरण के लिए #8934 और #8892, लेकिन यह कभी भी कहीं नहीं गया और ऐसा लगता है कि जल्द ही बदलने की संभावना नहीं है।)

@stevengj , जब आपने इस पैराग्राफ को अपने द्वारा पिछली टिप्पणी में जोड़ा, तो आपका मतलब था कि सिंटैक्स ⟨u,v⟩ भाषा में लागू करना कठिन है?

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

क्या आपने #27401 नहीं देखा?

धन्यवाद @jebej और नेतृत्व करने के लिए @ranocha धन्यवाद: दिल:

जब आपने इस अनुच्छेद को पिछली टिप्पणी में स्वयं जोड़ा था, तो आपका मतलब था कि वाक्य रचना ⟨u,v⟩ को भाषा में लागू करना कठिन है?

पार्सर में जोड़ने के लिए तकनीकी रूप से कठिन नहीं है, लेकिन भाषा में कस्टम ब्रैकेट का प्रतिनिधित्व करने के तरीके (और क्या) पर आम सहमति के साथ आना मुश्किल साबित हुआ है। #8934 पर चर्चा देखें, जो 4 साल पहले कहीं नहीं गई थी और तब से पुनर्जीवित नहीं हुई है। (इस तथ्य में जोड़ें कि अलग-अलग क्षेत्रों में लोग कई अलग-अलग चीजों के लिए एक ही ब्रैकेट का उपयोग करते हैं, उदाहरण के लिए u⟩ का उपयोग सांख्यिकीय भौतिकी में औसत औसत के लिए किया जाता है।) # 8892 में उठाया गया एक और मुद्दा, कई अलग-अलग यूनिकोड की दृश्य समानता है कोष्ठक।

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

यदि ⟨args...⟩ anglebrackets ऑपरेटर या कुछ को कॉल करने के लिए एक वैध वाक्यविन्यास है (फ़ंक्शन को कॉल करने के लिए यह वाक्यविन्यास कॉल वास्तव में मुश्किल है क्योंकि हमारे पास कोई उदाहरण नहीं है), तो लोग कर सकते थे वाक्य रचना के लिए वे जो भी अर्थ चाहते हैं, उसमें शामिल हों।

@StefanKarpinski , #8934 में तर्क यह था कि यह एक मैक्रो होना चाहिए। मुझे नहीं लगता कि हम कभी आम सहमति पर आए हैं।

(यदि हम आधार में निर्णय लेते हैं कि anglebrackets(a,b) का अर्थ है inner(a,b) , जो लोगों को "जो कुछ भी वे चाहते हैं उसमें चयन करने से हतोत्साहित करेगा" क्योंकि निर्णय पहले ही किया जा चुका होगा।
यह निश्चित रूप से एक भयानक विकल्प नहीं है, लेकिन जब तक उन्हें पार्स किया जाता है, तब तक इसे बेस में एक अर्थ निर्दिष्ट करना अनावश्यक हो सकता है।)

मुझे उस चर्चा का विवरण याद नहीं है लेकिन मैक्रो बनाना स्पष्ट रूप से मेरे लिए एक बुरा विचार है।

#27401 के साथ मुझे लगता है कि हम आंतरिक उत्पादों को गंभीरता से लेने पर विचार कर सकते हैं।

परंपरागत रूप से, कोई मुद्दा तभी बंद होता है जब संबंधित पीआर का विलय हो जाता है...

ज़रूर, हम इसे खुला छोड़ सकते हैं मुझे लगता है। बस इसे ट्राइएज लेबल से हटाना चाहता था।

क्या इसे बंद कर देना चाहिए क्योंकि #27401 का अब विलय हो गया है?