Julia: حالة المنتجات الداخلية في القاعدة

هل يمكنك شرح المزيد عن حالة الاستخدام الخاصة بك ولماذا يعد وجودها في Base بدلاً من مجرد تعريفها في الحزمة الخاصة بك مفيدًا؟ سيكون أفضل مثال ملموس. هل تتوقع عدة تعريفات inner عبر الحزم المحملة في وقت واحد؟

أعتقد أن وجود واجهة رسمية لهذه المساحات الرياضية سيساعد المستخدمين على استغلال نظام الكتابة بشكل أفضل. على سبيل المثال ، أتوقع أن تعمل طرق التجميع على أي مساحة مترية. إذا كان بإمكاني تحديد النوع الخاص بي بمنتج داخلي ، فسأستفيد من Clustering.jl خارج الصندوق (بعد إصلاح الحزمة وفقًا لذلك). يمكن أيضًا تعميم العديد من الخوارزميات الأخرى القائمة على المسافة أو القائمة على الإسقاط.

كمثال ملموس ، صادفت هذا القيد اليوم في محاولة لتعريف هندسة البيانات التركيبية: https://github.com/juliohm/CoDa.jl أنا أفضل التخصص في وظيفة inner المعروفة المعرفة في Base من تحديد واجهتي الخاصة التي لن يعرفها أي شخص آخر.

لماذا لا تقوم بتمديد dot لأنواع مساحات هيلبرت الخاصة بك؟ أنا متأكد من أنه مصمم مع وضع المنتج الداخلي العام في الاعتبار.

مفهوم المنتج النقطي أكثر صرامة من مفهوم المنتج الداخلي. في حين يتم تعريف الأخير للمساحات العامة ، يتم تعريف المنتج النقطي فقط عندما يكون هناك مفهوم لنظام إحداثيات محدد على أساس محدود. دلالات dot(x,y) هي x'*y حيث يمثل x و y إحداثيات الكائنات في عالم ديكارتي. نادرًا ما تذكر الكتب المدرسية الرياضية مصطلح المنتج النقطي لأن المؤلفين عادةً ما يهتمون بمعالجة المواد في مساحات أكثر عمومية (ليس بالضرورة محدودة ولا إقليدية).

لمزيد من التمييز ، في مساحة Hilbert مع المنتج الداخلي <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) يعمل بشكل مثالي.

هل يمكنك توضيح الاعتراضات على هذا التغيير؟

هل يمكنك توضيح الاعتراضات على هذا التغيير؟

نطلب عمومًا قدرًا معقولاً من التبرير لإضافة وظائف عامة جديدة إلى Base ، وهذا هو الاعتراض. يمكن توفير ذلك من خلال حزمة InnerProducts . لماذا يجب أن تكون مدمجة في اللغة نفسها؟ كان هذا هو السؤال الأول الذي طرحهandreasnoack أعلاه - فقد حصل على إجابة غامضة إلى حد ما وهي "أعتقد أن وجود واجهة رسمية لهذه المساحات الرياضية سيساعد المستخدمين على استغلال نظام الكتابة بشكل أفضل". لا يوجد سبب يجعل الواجهة المحددة في الحزمة أقل رسمية من تلك الموجودة في Base. ما الذي لا يقدمه عرض Base.inner والذي لا يقدمه InnerProducts.inner ؟ هذا سؤال حقيقي يمكن أن يكون له إجابة مقنعة ، لكنني لا أعرف ما قد تكون هذه الإجابة ، وهذا هو سبب طرح السؤال.

لا أرى حجة جيدة لتحديد مفهوم رياضي أساسي مثل المنتجات الداخلية في مكان آخر غير موجود في Base. اللغة التي يكون جمهورها الرئيسي هو أهل الحوسبة العلمية سوف يستفيدون من المصطلحات الصحيحة. لماذا يتم تعريف مفهوم norm في Base.LinAlg و inner ، الموجود في نفس المجموعة النموذجية ، يجب تحديده في حزمة؟ إلى جانب هذا التناقض ، تحتوي اللغة بالفعل على dot ، مما يجعلني أتساءل لماذا يجب أن تحتوي على شيء محدد للغاية بدلاً من مفهوم أكثر عمومية؟

هل تريد كل المفاهيم الرياضية الممكنة في اللغة الأساسية؟ عدم وجود شيء محدد في Base لا يجبر الناس على استخدام مصطلحات خاطئة. يتم تصدير الوظيفة norm من LinAlg لأنها معرّفة واستخدامها في LinAlg . مماثل لـ dot . هل تقترح إعادة تسمية dot إلى inner ؟

هل تريد كل المفاهيم الرياضية الممكنة في اللغة الأساسية؟

أنا لم أقل ذلك أبدا.

عدم وجود شيء محدد في Base لا يجبر الناس على استخدام مصطلحات خاطئة.

أنا متأكد من أنها لا تفعل ذلك. الترويج للمصطلحات الخاطئة هي القضية. سيتبنى الأشخاص القادمون من خلفية رياضية أقل استخدام النقطة لأنهم يرونها في Base. استخدام مصطلح "نقطة" المنتج لتمثيل مفهوم المنتج الداخلي غير صحيح. كما أنه يضر بالمجتمع الرياضي الذي يكافح بين الحين والآخر لإصلاح هذه الندوب التي خلفتها المصطلحات الخاطئة. يضطر الطلاب من جيلي باستمرار إلى الرجوع إلى الكتب القديمة للحصول على المصطلحات الصحيحة ، ولا ينبغي أن يكون هذا هو الحال.

هل تقترح إعادة تسمية النقطة إلى داخلية

سيكون ذلك بالفعل تحسنًا كبيرًا في رأيي. راجع جميع الأمثلة التي قدمتها أعلاه حول البيانات الوظيفية والتركيبية. لن يستخدم الأشخاص في هذه المجتمعات المصطلح dot أبدًا في عملهم. "النقطة" هي مصطلح في علوم الكمبيوتر أكثر من أي شيء آخر.

إعادة تسمية dot إلى inner هو اقتراح مختلف تمامًا عن إضافة inner إلى Base بالإضافة إلى dot . هذا أكثر من سؤال حول "المصطلحات الصحيحة" ، والذي سيتعين عليك أنت وأفراد Linalg الآخرين تجزئته ، على الرغم من أنني يبدو أنني أتذكر أننا قمنا بتضمين هذا السؤال مرة واحدة وخلصنا إلى أن dot هو الاسم الصحيح لما تنفذه هذه الوظيفة.

كان هناك القليل من النقاش حول هذا في https://github.com/JuliaLang/julia/issues/22227 و https://github.com/JuliaLang/julia/pull/22220

تعد إعادة تسمية النقطة الداخلية اقتراحًا مختلفًا تمامًا عن إضافة داخلي إلى القاعدة بالإضافة إلى النقطة.

هذا ما اقترحته في رسالتي الأولى في هذا الموضوع:

أود اقتراح إعادة تسمية النقطة الداخلية ، أو ربما توجيه المستخدمين لتعريف الداخلية (س ، ص) كمنتج داخلي عام بين العناصر س وص

أكرر أن المنتج النقطي هو المصطلح غير الصحيح للعملية التي أناقشها هنا. المنتج العددي الداخلي والخارجي ... هذه أشياء رياضية. "المنتج النقطي" هو كائن حسابي: يحصل على تسلسلين من الأرقام وينفذ x1*y1 + x2*y2 + ... xn*yn ، وهي عملية غير مجدية في مساحات رياضية أخرى.

لقد ركزت على الخيار الثاني الذي اقترحته ، والذي يبدو أنه كان يضيف Base.inner مع احتياطي لاستدعاء Base.dot . كلا الخيارين ممكن ، لكن كلاهما يتطلب بعض التبرير: لإضافة عملية جديدة ، يحتاج المرء إلى سبب لعدم وجوده في حزمة فقط (ما كان الجزء الأول من هذه المناقشة يدور حوله) ؛ لإعادة التسمية ، يجب تحديد أن dot هو الاسم الخطأ و inner هو الاسم الصحيح (ما يبدو أن المحادثة قد تحولت إليه).

juliohm ربما يستحق (إعادة) الإشارة إلى أن هناك جهدًا نشطًا حاليًا يحاول تقليص Base والتشجيع على استخدام الحزم. في هذه الحالة ، يبدو أن dot صحيح لجميع الأنواع المشاركة في الجبر الخطي المقدم في جوليا القياسية (على سبيل المثال ، Number و Array - لذا نعم ، هناك معلومة معروفة ، أساس محدود في جميع الحالات - وبالتالي لا أعتقد أننا ارتكبنا خطأ في المصطلحات ، على الرغم من أنه قد تكون هناك خيارات أفضل). أنا لست ضد هذا الاقتراح - لكنني أردت أن أشير إلى هذا لتوضيح سبب تعرضك لبعض المقاومة "الكامنة" للتغيير.

تجدر الإشارة أيضًا إلى أن عددًا لا بأس به من الوافدين الجدد في جوليا قد يكونون على دراية بمنتج نقطي ولكن ليس منتجًا داخليًا (على سبيل المثال ، لقد قاموا ببعض الفيزياء في الجامعة ، لكنهم ليسوا متخصصين في الرياضيات) لذلك هناك أيضًا بعض الأسباب احتفظ بـ dot (ناهيك عن أن لدينا عامل infix يتوافق مع - يمكننا فقط تعيينه إلى inner أفترض لكن هذا أقل وضوحًا قليلاً). ليس لدينا أيضًا دالة outer ، أو مجموعة متنوعة من العمليات الأخرى الممكنة.

وبالتالي ، هناك عبء لتقديم حالة معقولة لكيفية وضع هذا في Base (أو LinAlg ) أفضل تمامًا من وضع هذا في حزمة مستخدم. يبدو أن السبب الرئيسي هو توفير واجهة يمكن مشاركتها وتوسيعها من قبل الآخرين - هل هذا ملخص معقول؟ يبدو الجدل حول السماح للكود العام من Clustering.jl بالعمل مع منتجك الداخلي مقنعًا للغاية. أيضًا ، في السياق الذي يبدو أننا نقوم بتقسيم LinAlg إلى حزمة stdlib - كنت أفكر أنه إذا كنت سأقوم بتأليف حزمة تسمى LinearAlgebra ، فسأكون سعيدًا على الأرجح بتضمين inner وظيفة للآخرين لتمديدها.

شكرا لك andyferris لمشاركة أفكارك. أرى المقاومة بوضوح شديد ، وهو أمر لست متحمسًا له كثيرًا. ومع ذلك ، فإنني أشعر بالفضول حول الكيفية التي يؤدي بها هذا الاقتراح المحدد إلى زيادة التعليمات البرمجية؟ بالنسبة لي ، يبدو أنه تغيير تافه في الكود مع تحسن كبير في التجريد. المثال مع Clustering.jl هو مجرد مثال واحد من أمثلة عديدة ، فكر في أي طريقة قائمة على kernel يمكن إجراؤها للعمل مع أنواع Julia التعسفية التي يوجد لها مفهوم المنتج الداخلي. متعدد المتغيرات Stats.jl لديه الكثير منها.

فيما يتعلق بالتعليق حول تقسيم LinAlg إلى حزمة منفصلة ، أوافق على أنه يبدو مكانًا جيدًا لتغليف المنتجات الرياضية. أفترض أنه سيتم استيراد حزمة LinearAlgebra هذه للمستقبل في جلسة Julia افتراضيًا وبالتالي سيتمكن جميع المستخدمين من الوصول إلى مفهوم inner ، outer ، إلخ. فورا.

نعم ، تم إنشاء جميع المكتبات القياسية جنبًا إلى جنب مع صورة نظام Julia ومتاحة افتراضيًا. على الأقل بالنسبة لسلسلة v1.x ، لن يحتاج أحد إلى كتابة using LinAlg (لا أعتقد أنه سيتم إعادة تسميته LinearAlgbebra ، راجع للشغل ، لقد اختلقت ذلك كمنافس افتراضي) .

للتوضيح ، سيتم تحميله بـ Julia القياسي حتى لا تضطر إلى تثبيت أي شيء ، ولكن لا يزال يتعين عليك كتابة using LinAlg للحصول على الأسماء التي تصدرها.

هذا هو المكان الذي يصبح فيه الأمر غريبًا ، أليس كذلك ، لأننا سنحصل على طرق * وهكذا بدون using LinAlg ؟ (بعبارات أخرى ، LinAlg هو نوع قرصان).

نعم ، هذا هو المكان الذي سنضطر فيه إلى رسم الخط: يجب أن تحدد القاعدة أكبر قدر من وظائف الجبر الخطي حسب الحاجة لجعل LinAlg ليس قرصانًا ، لذلك تم تعريف matmul في Base لأن 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

غير مرحب به في Base؟ أفترض أن هذا هو كل ما هو مطلوب لتحديد أسماء الوظائف بشكل عام لمستخدمي اللغة للتخصص فيها. ضع في اعتبارك أنني أطرح هذه الأسئلة مع الاهتمام الحقيقي لفهم وجهة نظر المطورين الأساسيين. أريد أن أقول هذا قبل أن تدخل المحادثة في الاتجاه الخاطئ مرة أخرى.

من منظور شخص مهتم بالرياضيات بشكل عام ، من غير الطبيعي عدم تصدير هذه المفاهيم افتراضيًا ، وبدلاً من ذلك حددها داخل LinAlg . أعتقد أن LinAlg كتطبيقات لهذه المفاهيم عالية المستوى لأنواع المصفوفات. ربما لا يتطلب عملي بأكمله الجبر الخطي على المصفوفات ، لكن لا يزال بإمكاني الاستفادة من مفهوم المنتج الداخلي عبر الحزم (مثل MultivariateStats.jl، Clustering.jl). أيضًا ، قد لا أرغب في الحصول على LinAlg كتبعية في الحزمة الخاصة بي لأنها ليست كذلك.

إذا كان بإمكاني التأكيد عليه أكثر ، فهناك مفهوم المنتج الداخلي ، وهو مستقل عن المصفوفات. يتم تمثيل هذا المفهوم من خلال العبارة export inner في Base. هناك تنفيذ للمنتجات الداخلية لكائنات تشبه المصفوفة تمثل الإحداثيات inner(x,y) = sum(x.*y) . يمكن تعريف هذه العملية على أنها طريقة احتياطية في القاعدة مثل أعلاه ، إذا لزم الأمر.

مثال آخر لحالة الاستخدام هو طرق كريلوف. إذا كان لديك على سبيل المثال فراغات وظيفية مع منتجات داخلية ، فيمكنك استخدام طرق Krylov لتقريب مشكلة خطية أو مشكلة ذاتية في فضاء فرعي صغير محدود الأبعاد من مساحة الوظيفة ذات الأبعاد اللانهائية.

لدي أيضًا كائنات خاصة بي تشكل مساحة متجه / هلبرت ولكنها ليست جزءًا من <: AbstractArray . من القياس الذي يتضمن أيضًا المصفوفات ذات المساحات المتجهية ذات الترتيب N>1 ويمكن استخدامها كـ "متجهات" في طرق Krylov ، فقد أصبحت أعتمد على استخدام vecdot و vecnorm كونه المفهوم المعمم للمنتج الداخلي والمعيار. لذلك كنت أقوم بتطوير حزمة باستخدام طرق Krylov التي تستخدم وظائف كمعاملين خطيين وحيث يمكن أن يكون 'المتجه من أي نوع ، شريطة أن تدعم الكائنات من هذا النوع vecdot ، vecnorm وعدد قليل أشياء أخرى ( scale! ، zero ، ...). ولكن ربما يكون ذلك إساءة استخدام المقصود من هذه المفاهيم في Base ، لذلك سيكون من الجيد تسوية الواجهة الصحيحة هنا.

الحق - يمكن إعادة تسمية $ # vecdot inner .

(الآن أتساءل بشكل غامض عما إذا كان يجب استدعاء $ # norm فعليًا matrixnorm للمصفوفات التي تتطابق دائمًا مع norm inner . يبدو أنه ربما هناك نوعان مختلفان الأشياء التي تحدث بـ norm مما يسبب بعض الصعوبات في تعميمها)

في الواقع ، بالنسبة للكائنات العامة التي تشبه المتجه ، من المفيد أيضًا الاستعلام عن بُعد فضاء المتجه (على سبيل المثال للتحقق من أن بُعد Krylov لا ينبغي أن يكون أكبر من بُعد المساحة الكاملة في مثال حالة الاستخدام). يوضح مثال المصفوفات المتداخلة أن length ليس هو المفهوم الصحيح هنا ، أي يجب أن يكون هناك بعض المفاهيم العودية للطول لتلك الحالات.

الآن بالنسبة لمثال استخدام المصفوفات المتداخلة كمتجه عام ، فإن vecdot و vecnorm في بعض الحالات لا يمثلان حتى المفهوم الصحيح للمنتج الداخلي والقاعدة ، كما تمت مناقشته في # 25093 ، أي أنهما لا يستدعي بشكل متكرر vecdot و vecnorm . إن تفسيري لهذه الوظائف كمنتج داخلي عام ووظيفة معيارية هو ما أثار # 25093 ، ولكن يبدو أن هذا قد لا يكون كيف تم تصميم هذه الوظائف (لست متأكدًا مما كان من المفترض القيام به بدلاً من ذلك).

لذلك أوافق على أننا بحاجة إلى واجهة متسقة هنا لاستخدامها عبر الحزم ، والتي ستنتمي بالتالي إلى موقع مركزي (ربما ليس في Base ولكن بالتأكيد في مكتبة قياسية ، على سبيل المثال ، يجب على المرء أن يفعل using VectorSpaces ). بالنسبة للتسمية أرى خيارين:

الخيار 1 (تفسيري حتى الآن):
تشير البادئة vec إلى خاصية ذلك الكائن عند تفسيره على أنه متجه عام ، ومن ثم

• تم إصلاح vecdot و vecnorm للمصفوفات المتداخلة (PR # 25093)
• تمت إضافة تعريف جديد veclength

الخيار 2 (ربما يكون أفضل): استخدام أسماء صحيحة رياضيًا بشكل أكبر

• inner
• dimension
• ولكن ماذا تفعل بـ norm ؟

وأخيرًا ، فقط pingingstevengj حيث سيكون لديه بالتأكيد بعض التعليقات المفيدة ؛ اعتذاري إذا كان هذا غير مريح.

الاسم هو الجزء الأقل إثارة للاهتمام من كل هذا. ليس لدي أي مشاكل في استخدام الوظيفة dot للإشارة إلى منتج داخلي عام لمسافات هلبرت العشوائية. لا يقتصر الأمر على عدم وجود معنى آخر معقول لمثال "المنتج النقطي لوظيفتين" ، بل إنه من الشائع جدًا رؤية "المنتج النقطي للوظائف" في الاستخدام غير الرسمي ، لا سيما في الإعدادات التربوية حيث يحاول المرء التأكيد على التشابه مع المتجه ذي الأبعاد المحدودة المساحات.

juliohm ، inner(x,y) = sum(x.*y) ليس حتى منتجًا داخليًا بشكل عام ، لذلك سيكون هذا احتياطيًا رهيبًا جدًا لوضعه في القاعدة.

لكن dot لا يحسب بالفعل المنتج الداخلي الصحيح (في الواقع فشل) للعديد من الكائنات في Base التي تتصرف كمتجهات ، على سبيل المثال المصفوفات ذات المرتبة N>1 أو المصفوفات المتداخلة (المتجهات المتداخلة هي الحالة الوحيدة حيث يعمل بشكل صحيح). علاوة على ذلك ، فإن الاسم العام norm يصبح غامضًا بالنسبة للمصفوفات ، لأنني أتفق مع الخيار الحالي المتمثل في الحصول على هذه العودة للقاعدة المستحثة ، ولكن في بعض الأحيان يكون "معيار المتجه" (معيار Frobenius) مطلوبًا أيضًا.

وبالتالي ، سيكون اقتراحي الأقل تأثيرًا هو التخلي عن الدلالات vecnorm(x) = norm(vec(x)) وبدلاً من ذلك تفسير vecnorm(x) على أنه "لكون x كائنًا من نوع عام يتصرف على أنه فضاء متجه ، احسب معيار المتجه المقابل البالغ x "(ومماثل مع vecdot ). في حين أن هذا يمثل تحولًا في التفسير (وبالتالي في التوثيق) ، فإن التنفيذ الفعلي / الإجراء الفعلي للكائنات في Base لن يكون مختلفًا تمامًا (PR # 25093) وسيؤدي إلى نفس النتيجة لمعظم الحالات (المصفوفات ذات الترتيب N العددية أو النواقل). الدالة veclength(x) التي تُرجع بُعد مساحة المتجه المقابل لـ x ستكمل الواجهة.

يجب أن تتعلم الحزم المخصصة بعد ذلك كيفية تنفيذ هذه الوظائف عندما تحدد أنواعًا جديدة تتصرف كمتجهات.

من الشائع جدًا رؤية "المنتج النقطي للوظائف" في الاستخدام غير الرسمي ، لا سيما في الإعدادات التربوية حيث يحاول المرء التأكيد على التشابه مع المساحات المتجهة ذات الأبعاد المحدودة

من فضلك لا تقل الاسم غير مهم ، لأنه كذلك. سأكرر للمرة رقم n: المنتج الداخلي والمنتج النقطي ليسا نفس الشيء. أي مادة جادة تعرض العمل باستخدام مسافات هيلبرت المجردة لن تستخدم "نقطة" أبدًا. إذا كنت تفضل الوثوق في ويكيبيديا بدلاً من كلماتي ، فإليك التعريفات المنسوخة واللصقة:

منتج داخلي

في الجبر الخطي ، مساحة المنتج الداخلية عبارة عن مساحة متجهية ببنية إضافية تسمى المنتج الداخلي. تربط هذه البنية الإضافية كل زوج من المتجهات في الفراغ بكمية قياسية تُعرف باسم المنتج الداخلي للمتجهات.

المنتج نقطة

في الرياضيات ، المنتج النقطي أو الضرب القياسي هو عملية جبرية تأخذ متتابعين متساويين الطول من الأرقام (عادةً ما تنسق المتجهات) وتعيد رقمًا واحدًا.

هذه المقاومة لتحسين المصطلحات والاتساق الرياضي في اللغة محبطة. بغض النظر عن عدد الحقائق التي أقدمها لك ، بغض النظر عن عدد الأمثلة وحالات الاستخدام ، لا توجد حجة مضادة بخلاف "أنا بخير مع النقطة".

juliohm ، المصطلحات هي مسألة اصطلاح وليس صواب. أوافق على أنه في الاستخدام الرسمي لمساحات هيلبرت ، خاصةً تلك ذات الأبعاد اللانهائية ، فإن مصطلح "المنتج الداخلي" يستخدم بشكل حصري إلى حد كبير. ولكن ، كما قلت ، إذا بحثت في Google عن "وظائف المنتج النقطي" ، فستجد الكثير من الاستخدامات غير الرسمية لتلك المصطلحات أيضًا. إذا قلت "خذ حاصل الضرب النقطي لعنصرين من مساحة هيلبرت هذه" ، فسيعرف كل عالم رياضيات أنك تشير إلى منتج داخلي ، حتى بالنسبة للمساحات اللانهائية الأبعاد ، لذلك لا يوجد خطر حقيقي من الارتباك ، لأنه لا يوجد غيره التعميم القياسي لمصطلح "منتج نقطي". لهذا السبب لا أجد الجدل الإملائي حول "نقطة" مقابل "داخلي" قضية مركزية.

من المهم اتخاذ قرار بشأن الدلالات التي يريدها المرء هنا ، ومجموعة الوظائف التي يجب أن تنفذها الأنواع إذا حددت مساحة هيلبرت جديدة أو مساحة باناخ. حاليًا ، إذا كنت تريد تحديد نوع يمثل مساحة هيلبرت جديدة ، فيجب عليك تحديد dot و norm (نظرًا لأننا نفتقر حاليًا إلى احتياطي لهذا الأخير) ، وأعتقد adjoint إذا كنت تريد التعيين إلى كائن مزدوج المساحة.

كما يقول Jutho ، كل هذا معقد بسبب حالة مصفوفة المصفوفات ، نظرًا لوجود العديد من الأشياء المحتملة التي قد يرغب المرء فيها. نظرًا لعدم وجود أسماء موحدة لجميع الدلالات المحتملة ، فمن الصعب العثور على أسماء / دلالات ترضي الجميع. راجع # 25093 لمناقشة دلالات vecdot . ليس لدي إجابة جيدة هنا ، بنفسي.

بعض الاحتمالات هنا

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) للمصفوفات إلى معيار Frobenius ، والذي من المحتمل أن يكون تغييرًا جذريًا بعيد المدى.

السؤال (الذي تمت مناقشته جزئيًا في # 25093) هو ما إذا كنا بحاجة إلى كل هذه العناصر الثلاثة في Base ، أو إذا كان بإمكاننا التخلص من اثنين (وأيهما ، وماذا نسميهما). اقتراح Jutho ، كما أفهمه ، هو في الأساس حذف الخيار 2 في Base ثم استخدام vecdot و vecnorm للخيار 3. ثم لدينا منتج داخلي حقيقي ، لكن المصطلحات تعتبر فريدة إلى حد ما بالنسبة لجوليا ، وغريبة بعض الشيء على سبيل المثال مسافات هيلبرت اللانهائية الأبعاد. لن تكون هذه نهاية العالم بالطبع.

الاحتمال الآخر (بغض النظر عن ما نفعله بـ 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 . يبدو هذا وكأنه التغيير الأقل إزعاجًا والأكثر قابلية للفهم بالنسبة لي.

(A 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 ليكون المنتج الداخلي الحقيقي والمعيار الذي يجب أن يحدده أي متجه مثل نوع المستخدم ، فعندئذ حتى عند كتابة حزمة باستخدام طرق Krylov على سبيل المثال يجب أن يعمل مع متجه عام تمامًا مثل الأنواع ، فلن يعمل مع الحالة التي يريد فيها المستخدم استخدام المصفوفات المتداخلة أو متعددة الأبعاد كمتجه مثل الكائنات. لذلك ، أود أن أزعم أن vecdot و vecnorm هما المنتج الداخلي العام وقاعدة الكائنات المتجهية. يتناسب هذا أيضًا بشكل جيد مع حقيقة أنه بالنسبة للمصفوفات ، يتوقع معظم الناس بالفعل أن يكون norm هو معيار المصفوفة / المشغل المستحث.

بالنسبة لحالة استخدام فعلية (لإثبات أن هذه ليست حالة استثنائية). تحتوي المصفوفات العشوائية على أكبر قيمة ذاتية (Perron-Frobenius) حيث يمثل المتجه الذاتي المقابل توزيعًا احتماليًا ثابتًا. في التعميم الكمي لها ، يعمم توزيع الاحتمالات على مصفوفة محددة موجبة (مصفوفة الكثافة) وهذه المصفوفة هي النقطة الثابتة (المتجه الذاتي المقابل لأكبر قيمة ذاتية) لخريطة موجبة تمامًا ، أي الخريطة rho -> sum(A[i] rho A[i]^\dagger for i = 1:N) حيث يكون rho مصفوفة الكثافة و A[i] مصفوفة لكل i (تُعرف باسم مشغلي Kraus الذين يمثلون الخريطة الإيجابية تمامًا). بالنسبة لأبعاد المصفوفة الكبيرة ، فإن طريقة Arnoldi مناسبة بشكل مثالي لإيجاد مصفوفة كثافة النقطة الثابتة.

ميولي الشخصية الحالية هي تحديد النقطة لتكون منتجًا داخليًا حقيقيًا (والذي يجب أن يكون متسقًا مع القاعدة) ، وتغييرها إلى مجموع النقاط (x [i] ، y [i]) للمتجهات. أخيرًا ، لنفترض أن أنواع "فضاء هلبرت" الجديدة يجب أن تحدد النقطة والمعيار.

هذا تحسن كبير بالفعل. توثيق dot للحصول على inner دلالات في Base سيسمح على الأقل للمستخدمين بتحديد مساحاتهم الخاصة دون استيراد مكتبات غير ضرورية. لست سعيدًا بشأن التسمية ، ولكن على الأقل ستكون الوظيفة متاحة لمن يحتاجون إليها.

نعم ، أعتقد أنه سيكون من الجيد أن يكون لديك واجهة موثقة للتنفيذ لأنواع "فضاء هيلبرت".

بالطبع ، عند التفكير في هذه الواجهة العامة لمساحات المتجه ، إذا كانت تتضمن norm كما هو مقترح أعلاه ، فيجب أن يكون هذا هو معيار Frobenius للمصفوفات (ويتم تعميمه على المصفوفات عالية الأبعاد ، نظرًا لأن جميع المصفوفات عبارة عن عناصر متجه الفضاء). في هذه الحالة ، سنحتاج إلى دالة "معيار عامل التشغيل" منفصلة للمصفوفات ( matnorm أو opnorm أو شيء ما ، أو وسيطة كلمة رئيسية على norm ...).

andyferris ، يرجى ملاحظة تعليقي الأخير. لا يمكن أن تصبح norm و dot واجهة فضاء هيلبرت العامة ، لأنها لا تعمل حتى على كائنات متجهية في جوليا مثل المصفوفات عالية الأبعاد والمصفوفات المتداخلة. ومن ثم فإن vecdot و vecnorm هما مرشحان "أفضل" (بمعنى أنهما أقل كسرًا) لهذا الغرض.

إحياء هذا الموضوع ، الذي أعتبره وثيق الصلة بنوع الرياضيات الذي أتوقع أن أفعله باللغة في المستقبل القريب. هل هناك إجماع على ما سيتم عمله لتحسين عمومية ودلالات المنتجات الداخلية؟

هذا هو جزء من علم الوجود الخاص بي في الرياضيات المتعلق بالمنتج.
إذا كان يمكن أن يساعد في تحسين الذاكرة / تحقيق الإجماع

• منتج نقطي المرادفات : منتج عددي
• منتج داخلي
• المنتوج الوسيط
• منتج موتر المرادفات : المنتج الخارجي
• منتج إسفين المرادفات : المنتج الخارجي
• منتج الكأس
• منتج ثلاثي

المكافأة: لا توجد حكام ويكيبيديا

في هذه المرحلة ، يبدو اقتراح Jutho في # 25093 أقل تغيير معطّل ، على الرغم من أن المصطلحات vec* غريبة بعض الشيء بالنسبة لي في هذا السياق.

أوافق على أن المصطلحات vec* غريبة. هذا هو السبب في أن إعادة تسمية الوظائف بأسماء قياسية ستكون مفيدة لجميع المستخدمين.

أوافق أيضًا على أن المصطلحات vec* غريبة.

أوافق ، كبديل لـ vecdot ، يمكننا تقديم طريقة جديدة inner ، لكني لا أعرف اسمًا جيدًا "لاستبدال" vecnorm . في الواقع ، لا vecnorm أن المعيار المتجه السيئ هو مصطلح راسخ وواضح للعملية التي نريدها.

تكمن المشكلة الأساسية هنا في المصفوفات والمصفوفات متعددة الأبعاد ، والتي لا تتوافق مع المصفوفات المعتادة norm(A) مع منتج داخلي ، وكذلك مع مصفوفات المصفوفات كما تمت مناقشته أعلاه. بعض توضيح الغموض (على سبيل المثال vec* أو fro* ) مطلوب في هذه الحالات للإشارة إلى المنتج الداخلي المقصود.

يمكن أن يكون لديك دالة inner تكون افتراضية vecdot ، لكن من السخف بعض الشيء أن يكون لديك اسمان لنفس الوظيفة ، ولا تزال هناك مشكلة فيما نسميه القاعدة.

أجد أيضًا اسم vecdot غريبًا ، في الواقع ، لم أكن أعرف حتى أنه موجود وقد صنعت وظيفتي الخاصة له ... يسمى inner .

ما أفهمه هو أنه يمكننا فقط إهمال الشيء الفردي vecdot لصالح inner ، وإعطائه دلالات المنتج الداخلية للمستخدمين لتنفيذ مساحاتهم الخاصة.

بخصوص norm ، الذي لا أعرف. لقد فتحت هذا العدد لمناقشة المنتجات الداخلية ، فربما تكون هناك مشكلة أخرى مناسبة لمناقشة حالة المعايير في Base.

أفترض أنه يمكن أن يكون لدينا inner(x,y) و innernorm(x) = sqrt(inner(x,x)) (مع حالات خاصة محسّنة لتجنب الفائض) بدلاً من vecdot و vecnorm . innernorm غير معتاد إلى حد ما ولكنه واضح بشكل معقول في سياقه.

ممتاز لهذا التغيير. الأسماء inner و innernorm واضحة ومتسقة مع المفاهيم. أتمنى أن يتمكنوا من الوصول إلى Julia v1.0.

يبدو أن inner و innernorm مناسبان لي.

ما زلت أقول ، في رأيي ، أن وظيفتنا norm لا تتناسب بشكل جيد مع وظيفة Julia العامة ونظام الإرسال وما أسميه "الواجهات الواضحة" حيث لا ينبغي أن يتم الإرسال الخيارات الدلالية ، فقط خيارات التنفيذ. أود شخصيًا أن نقول "يعرض norm معيار عنصر مساحة متجه" ، حيث لا تزال المصفوفات والعوامل الخطية عناصر من مسافات المتجهات (يمكنك إضافتها وضربها في عدد قياسي) . يمكن أن يكون لدينا أيضًا على سبيل المثال ، "يعرض opnorm معيار عامل التشغيل لعامل خطي" (أو matnorm أو أيًا كان).

في الوقت الحالي ، لدينا "إرجاع norm معيار عنصر مساحة متجه ، ما لم يكن العنصر أيضًا عامل تشغيل خطي ، وفي هذه الحالة سنمنحك معيار عامل التشغيل بدلاً من ذلك". أنا شخصياً أشعر أن الإرسال لا ينبغي أن يكون مفاجئًا أبدًا.

أي أنني أفضل وظيفة واحدة تقوم دائمًا بعمل معيار متجه ودالة أخرى تقوم دائمًا بعمل معيار عامل التشغيل ، ولا توجد وظيفة تحاول القيام بالأمرين معًا.

أحب ذلك بشكل أفضل andyferris : +1: يمكن أن يكون للمعايير المحددة التي ليست هي المعايير التي يسببها المنتج الداخلي في الفضاء اسم أكثر تحديدًا. الاسم norm يعني بالضبط norm(x) = sqrt(inner(x,x)) ، ويمكن إعادة تعريفه حسب الحاجة لأنواع المستخدمين.

أود شخصيًا أن نقول "يعرض norm معيار عنصر مساحة متجه"

الدالة norm الحالية تتوافق مع هذا التعريف. بالنسبة للمصفوفات ، فإنها تحسب المعيار المستحث (المشغل) ، والذي يعد معيارًا صالحًا تمامًا لمساحة ناقل . (لا يجب أن تحتوي مساحات المتجهات على منتجات أو قواعد داخلية على الإطلاق.)

قد تكون مرتبكًا إلى حد ما بشأن تعريف "القاعدة" إذا كنت تعتقد أن معيار المشغل ليس "معيارًا لمساحة ناقل".

هذا أيضًا تمييز مفيد بين norm و innernorm . إذا قمت بتعريف norm ، فسأقول أنه يعني فقط أن لديك مساحة Banach (أو على الأقل مساحة متجه معيارية). إذا حددت innernorm ، فهذا يعني أن لديك مساحة Hilbert (أو على الأقل مساحة داخلية للمنتج) وأن هذا المعيار يتوافق مع inner .

على سبيل المثال ، التكامل العددي التكيفي (ala quadgk) هو شيء لا يتطلب سوى مساحة متجه معيارية ، وليس مساحة داخلية للمنتج.

بالتأكيد ، آسف ، ربما كنت غير دقيق بعض الشيء في لغتي. من الواضح أن هناك العديد من المعايير الصالحة لمساحة ناقل ، بما في ذلك معايير المشغل المختلفة.

أعتقد أن ما أفهمه هو أنني ربما أفضل اختيار أي معيار يكون أكثر وضوحًا من كونه ضمنيًا؟ وأنك إذا استخدمت نفس الوظيفة (بدون وسيطات الكلمات الرئيسية الإضافية على سبيل المثال) فإنك تحصل على نفس المعيار ، وفي هذه الحالة يبدو الإقليدي خيارًا يمكن الدفاع عنه إلى حد ما مقابل AbstractArray .

هذا أيضًا تمييز مفيد بين norm و innernorm . إذا حددت القاعدة ، فسأقول أنها تعني فقط أن لديك مساحة باناخ (أو على الأقل مساحة متجهية معيارية). إذا حددت innernorm ، فهذا يعني أن لديك مساحة Hilbert (أو على الأقل مساحة داخلية للمنتج) وأن هذا المعيار يتوافق مع inner .

هذا يبدو معقولًا ، لكنني ما زلت أتساءل لماذا إذا كان الكائن يحتوي على innernorm فإنه يحتاج إلى norm مختلف ؟ أود بدلاً من ذلك أن أقترح أن واجهة مساحة Banach تتطلب norm بينما توفر واجهة مساحات المنتج الداخلية كلاً من norm و inner . يمكن بعد ذلك استخدام هذه الوظائف في رمز عام يتوقع كائنات من Banach أو مساحات داخلية للمنتج حسب الاقتضاء (تحرير: مع التفكير في أن الكود الذي يعمل في مساحات Banach سيعمل تلقائيًا أيضًا على مساحات المنتج الداخلي).

أعتقد أنك تقترح أن norm(x) يشير دائمًا إلى نوع من القاعدة الإقليدية ذات العناصر الحكيمة (على سبيل المثال ، معيار Frobenius للمصفوفات) ، أي أساسًا ما يمثله الآن vecnorm نمط الحالة العودية. في هذه الحالة ، قد نقوم أيضًا بإعادة تعريف dot(x,y) ليكون المنتج الداخلي المقابل ( inner يعمل أيضًا ، لكن dot لديه ميزة متغير infix x ⋅ y ).

أنا بخير مع هذا من حيث المبدأ ، ولكن هذا سيكون تغييرًا جذريًا وقد يكون متأخرًا قليلاً قبل 0.7 للحصول على ذلك ...

هل L2 هو تقصير جيد في الأبعاد العالية أيضًا؟
تتحدث هذه المقالة عن المسافة ، ولكنها قد تتعلق بالمعايير أيضًا
https://stats.stackexchange.com/questions/99171/why-is-euclidean-distance-not-a-good-metric-in-high-dimensions

في هذه الحالة ، قد نعيد أيضًا تعريف النقطة (x ، y) لتكون المنتج الداخلي المقابل (يعمل داخليًا أيضًا ، لكن النقطة لها ميزة متغير infix x ⋅ y)

هل يمكننا التخلص من dot بالكامل؟ يجب ألا يكون تدوين اللاحمة مرتبطًا بوجود دالة تسمى dot . ما عليك سوى تحديد infix بالطريقة inner لمصفوفات جوليا. هل هذا ممكن؟

هذا هو ما هو عليه حقًا ، حاصل الضرب النقطي: تدوين مناسب x ⋅ y للمنتجات الداخلية بين متجهات x و y في R ^ n مع الهندسة الإقليدية.

stevengj أعتقد أن هذا ملخص جيد ، نعم.

@ o314 هل L2 تقصير جيد في الأبعاد العالية؟ ربما لا ، لكنني أكره ذلك حقًا إذا كان المعيار الذي اختاره norm(v::AbstractVector) يعتمد على length(v) :) ، فأنا أيضًا لا أرغب في تخمين ما إذا كانت المصفوفة الخاصة بي أو مصفوفة ذات أبعاد أعلى هو "كبير جدًا على L2" - أقترح أنه ربما يجب على المستخدم وضع علامة صريحة على هذا؟

juliohm هذا ممكن بالتأكيد ، على الرغم من أنه كما ذكرنا ، فهذه تغييرات كبيرة نقترحها. (مرة أخرى ، modulo ما يجب فعله في الحالة العودية والمناقشات السابقة حول الاختلافات المحتملة بين inner و dot ).

stevengj ، تفسيري لما يعنيه andyferris هو أنه بسبب كتابة البطة ، من الصعب تحديد ما إذا كان المستخدم يريد تفسير كائن على أنه متجه (واستخدام متجه مقابل p -norm) أو كمعامل (وحساب قيمة p المستحثة). لذلك أعتقد أنه لا يوجد خيار سوى التحديد الواضح للسلوك المطلوب. النهج الحالي غريب بعض الشيء بمعنى أن norm يحاول التخمين ضمنيًا ما إذا كان سيتم اختيار معيار متجه أو معيار مستحث استنادًا إلى المدخلات ، و vecnorm هي طريقة لتحديد ما تريده بشكل صريح معيار المتجه (وهذا أيضًا سبب عدم العثور على vecnorm مثل هذا الاسم السيئ). قد يكون التغيير الأكثر جذرية هو جعل norm دائمًا افتراضيًا لقاعدة المتجه ، وتحديد متى تريد القاعدة المستحثة ، باستخدام وسيطة (كلمة أساسية) أو دالة مختلفة تمامًا.

من ناحية أخرى ، لا أمانع أيضًا في الاسم innernorm ، وهو واضح من حيث أن هذا هو معيار داخلي يعتمد على المنتج (أي دائمًا p=2 في الحالة الإقليدية). أجد صعوبة في الحكم على ما إذا كانت العناصر المخصصة يجب أن يدعم (vec)norm وسيطة اختيارية p كجزء من الواجهة ، لأنه في بعض حالات الاستخدام الخاصة بي ، يكون p=2 فقط سهل لحساب.

هذا هو ما هو عليه حقًا ، حاصل الضرب النقطي: تدوين مناسب x ⋅ y للمنتجات الداخلية بين متجهات x و y في R ^ n مع الهندسة الإقليدية.

أتفق مع هذا ، بمعنى أنني لا أتذكر أنني رأيت على الإطلاق الترميز x ⋅ y في سياق مساحات المتجهات العامة (مثل المعقدة). أعتقد أنه يتم استخدام الترميز الرياضي فقط (x,y) أو رمز Dirac < x | y > في مثل هذه الحالات. في الكهرومغناطيسية ، غالبًا ما يستخدم المرء E ⋅ B للمتجهات في الفضاء الإقليدي ثلاثي الأبعاد ، وحتى إذا استخدم المرء تدوينًا معقدًا (أي الأطوار) ، فإن هذا لا يعني اقترانًا معقدًا. إذا لزم الأمر ، يتم الإشارة إلى الاقتران المعقد صراحةً في مثل هذه الحالات. لذلك لا أمانع إذا أصبح dot sum(x_i * y_i) بدون اقتران معقد أو Hermitian ، و inner أصبح المنتج الداخلي الصحيح لمساحات المنتج الداخلية العامة. لسوء الحظ ، ربما لا يمكن القيام بذلك في دورة إصدار واحدة.

هل L2 هو تقصير جيد في الأبعاد العالية؟ ربما لا ، لكنني أكره ذلك حقًا إذا كان المعيار المختار من قبل القاعدة (v :: AbstractVector) يعتمد على الطول (v) :) لا أرغب أيضًا في تخمين ما إذا كانت المصفوفة الخاصة بي أو المصفوفة ذات الأبعاد الأعلى "كبير جدًا على L2" - أقترح أنه ربما يجب على المستخدم وضع علامة صريحة على هذا؟

أنا أعمل في عالم BIM حيث نتعامل مع 2d و 3 d ، ولكن أيضًا 4d و 5d و 6d قد تكون 7d. نحن لا نذهب أبعد من ذلك أبدا. في أي مرحلة ، نعرف الأبعاد التي نعمل فيها ، وأي الخوارزمية متضمنة. هذا يكفي إلى حد كبير.

لا أستطيع التعبير عن وجهة نظر الأشخاص الذين يعملون في ML ، واسترجاع المعلومات وما إلى ذلك ، هناك ، قد يكون norminf أفضل. المهم في وجهة نظري هو التخمين والاستقرار. لن أصاب بالصدمة على الإطلاق إذا كان الأشخاص في ML يحتاجون إلى تقصير مختلف لأشياءهم. إذا لم يكن هناك لبس. على سبيل المثال. يتم تحديده بشكل صريح وثابت في وقت الترجمة. حتى أنها فاخرة إذا ظلت مستقرة ومتسقة أثناء تطبيق الطحالب.

مستوحى من المصفوفة: متشابه لم يتم تنفيذه بالكامل واختبره.

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

هل يمكننا التخلص من النقطة تماما؟ يجب ألا يكون تدوين اللاحمة مرتبطًا بوجود دالة تسمى النقطة. ما عليك سوى تحديد infix بالطريقة الداخلية لمصفوفات Julia. هل هذا ممكن؟

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

تعني النقطة / vecdot استخدام المتقارن ولتحديد وقت الذهاب إلى BLAS. هذا يجب أن يتم التعامل معه في مكان ما. لكن هذا يجب أن يكون قابلاً للإدارة في مساحة اسم واحدة.

هل L2 هو تقصير جيد في الأبعاد العالية؟ ربما لا

L2 هو أيضًا المعيار الأكثر شيوعًا للمساحات اللانهائية الأبعاد (مثل الوظائف). أعتقد أنه افتراض افتراضي معقول أن نتوقعه لأي مساحة متجهية.

من الواضح أنك تريد أن يكون لديك معايير أخرى متاحة أيضًا. إذا قمنا بإعادة تعريف norm(x) ليكون عنصر L2 حيثما أمكن ، فإن norm(x, p) سيكون عنصرًا Lₚ ، وسنحتاج إلى بعض الوظائف الأخرى (على سبيل المثال opnorm ) من أجل المستحث المقابل / قواعد المشغل.

أتفق مع هذا ، بمعنى أنني لا أتذكر أنني رأيت على الإطلاق الترميز x ⋅ y في سياق المساحات المتجهة العامة (مثل المعقدة).

لقد قدمت العديد من الاستشهادات في موضوع آخر ، IIRC (على سبيل المثال ، تستخدم BLAS dot للمنتج النقطي المعقد ، ويمكنك العثور على مصادر تربوية حتى باستخدام مصطلح المنتجات الداخلية للوظائف). عادة ما يتم تقديم مصطلح "المنتج الداخلي" على أنه "تعميم لمنتج نقطي". لا أعتقد أن أي شخص سيتفاجأ من تدوين dot لمنتج داخلي إقليدي ، ومن الملائم أن يكون لديك مشغل infix.

يمكننا الاحتفاظ بـ dot كما هو وتقديم inner ، بالطبع ، لكن أعتقد أن هذا سيخلق تقسيمًا مربكًا - في الحالات الأكثر شيوعًا ، ستكون الوظائف متكافئة ، ولكن في الحالات الفردية (على سبيل المثال ، مصفوفات المصفوفات) قد تختلف.

ولكن مرة أخرى ، قد يكون الوقت متأخرًا قليلاً لكسر التغييرات ، لذلك قد نضطر إلى اللجوء إلى innernorm و inner . في أي حال ، سيحتاج شخص ما إلى إنشاء علاقات عامة في أسرع وقت ممكن.

إذا كان هناك مقياس معقول لنماذج الإجماع ، فقد أتمكن من تخصيص بعض النطاق الترددي لاستكشاف التنفيذ على نطاق زمني (قصير) ذي صلة ، مع تضمين تغييرات كسر محتملة. إنني أقدر الدافع لتوضيح دلالات هذه العمليات ومنحها أسماء صريحة. أفضل!

أرى خيارين رئيسيين:

• بدون كسر ، يضيف ميزة: inner(x,y) و innernorm(x) . استبدال vecdot و vecnorm ، والعودي لمصفوفات المصفوفات.

• التكسير: قم بتغيير norm(x,p=2) ليكون دائمًا عنصريًا ومتكررًا ، مع استبدال vecnorm ، وإدخال دالة جديدة opnorm للعامل / القاعدة المستحثة. اجعل dot(x,y) المنتج النقطي المقابل ، بدلاً من vecdot . (بديل: إعادة التسمية إلى inner ، لكن من الجيد أن يكون لديك عامل تشغيل infix ، ومن المزعج أن يكون لديك كل من dot و inner .)

إذا كنت أصمم أشياء من الصفر ، فسأفضل 2 ، ولكن قد يكون من الصعب جدًا تغيير معنى norm بصمت.

قد يكون أحد الخيارات الوسيطة هو تحديد inner و innernorm (مع إهمال vecdot و vecnorm ) ، وإيقاف norm(matrix) إلى opnorm . ثم ، في الإصدار 1.0 ، أعد تقديم norm(matrix) = innernorm(matrix) . بهذه الطريقة ، يمكن للأشخاص في النهاية استخدام inner و norm ، ونترك dot كالوحش الغريب الحالي لمتجهات المصفوفات (بالتزامن مع inner لناقلات الأرقام).

أحد الأشياء الغريبة عن innernorm هو أنك تريد طريقة لتحديد معايير L1 أو Linf "elementwise" ، لكن لا يتوافق أي منهما مع منتج داخلي ، لذا فإن تسمية innernorm(x,p) هي تسمية خاطئة إلى حد ما.

أنا أحب خيارك الوسيط.

كما هو مذكور أعلاه ، أحب الاسم innernorm(x) لأنه يتضمن p=2 ولا يجب أن تكون هناك وسيطة ثانية. لدي أشياء لا أعرف إلا كيفية حساب معيار المنتج الداخلي لها. ولكن مع (vec)norm الحالي ، ليس من الواضح بالنسبة لي ما إذا كانت الوسيطة p جزءًا من واجهة Base المفترضة ، وبالتالي لا أعرف ما إذا كنت سأحذف الوسيطة الثانية ، أو سأدعمها ولكن بعد ذلك تحقق صراحة من p != 2 وتنتج خطأ.

لكني أرى مشكلة في عدم وجود أي طريقة غير مهملة لإنجاز vecnorm(matrix, p!=2) خلال المرحلة المتوسطة من اقتراحك.

أنا أيضًا أحب الخيار الوسيط - نريد بالتأكيد أن نمر بدورة مناسبة من الإهمال للمعايير بدلاً من إجراء تغيير فاصل فوري. (بصفتي مستخدمًا ، فإن التغييرات العاجلة تخيفني ، لكني أرى إصلاح الإهمال في الكود الخاص بي للإصدار 1.0 يشبه الاستثمار في رمز نظيف وواضح للمستقبل).

هل سنحتاج بالفعل إلى innernorm أم يمكننا فقط استخدام vecnorm في الوقت الحالي (وإهمال vecnorm لصالح norm لاحقًا)؟

أنا في الواقع لا أرى أي ضجة محتملة في مجرد استبدال dot بـ inner ... أعتقد أيضًا أنه من الواضح بما فيه الكفاية أن المنتج الداخلي من المفترض أن يكون تعميمًا للمنتجات النقطية.

يمكن تنفيذ التغييرات في اثنين من العلاقات العامة المنفصلة:

1. استبدل dot بـ inner واعطه المعنى العام. اختياريًا ، اجعل رمز infix \cdot يشير إلى الداخل بين مصفوفات Julia.
2. مزيد من المناقشة ودورات الإهمال حول المتغيرات المعيارية والمصطلحات.

أفهم أنه يمكن دمج PR 1 قبل Julia 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 ، بشكل مثير للدهشة ، ليست دائمًا منتجًا داخليًا. لكن مصطلحات NumPy في inner و dot كانت غريبة لبعض الوقت.)

أسباب تفضيل الاستمرار في تهجئتها كـ dot :

• من الجيد أن يكون لديك تصحيح إملائي.
• بالنسبة لغير الرياضيين الذين يعملون على مسافات متجهة عادية محدودة الأبعاد ، فإن dot هو اسم مألوف أكثر للمنتج الداخلي الإقليدي. (سوف يتكيف علماء الرياضيات بسهولة مع استخدام الاسم dot لوظيفة المنتج الداخلي في مسافات هلبرت العشوائية - "المنتج النقطي" ليس له أي معنى آخر محتمل لمثل هذه المسافات.)
• سيكون وجود كل من inner و dot أمرًا مربكًا ، نظرًا لأنهما سيتطابقان في بعض الحالات ولكن ربما لا يتطابقان في حالات أخرى (إذا احتفظنا بالمعنى الحالي dot ).
• خارج الجبر الخطي ، يحتوي inner على الكثير من المعاني المحتملة الأخرى في علوم الكمبيوتر ، ومن ثم فإنه من المزعج إلى حد ما تصدير هذا الاسم من Base.

هل يمكنك توضيح معارضتك للاسم الداخلي؟ ما زلت لا أفهم
هذا هو سبب تفضيلك لمعارضة المصطلحات التي يبدو أن الجميع في هذا الموضوع
كى يوافق؟

في الثلاثاء ، 15 مايو ، 2018 ، 5:13 صباحًا ، ستيفن ج. جونسون ، [email protected]
كتب:

(لاحظ أن 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
.

ليست هناك أي من الأسباب مقنعة بالنسبة لي:

>

• من الجيد أن يكون لديك متغير infix.

نعم ، ويمكن أن يظل تدوين اللاحمة موجودًا بغض النظر عن إعادة التسمية إلى
داخلي كما هو موضح أعلاه.

>

• لغير الرياضيين الذين يعملون على الأبعاد المحدودة العادية
  الفراغات المتجهة ، النقطة هي اسم مألوف أكثر للداخل الإقليدي
  المنتوج. (سوف يتكيف علماء الرياضيات بسهولة مع استخدام اسم نقطة لـ
  دالة المنتج الداخلي في مسافات هلبرت العشوائية - "المنتج النقطي" لا يحتوي على
  المعنى المحتمل الآخر لمثل هذه المساحات.)

هذه الحجة ليست جيدة: فلنعلم الناس العاديين الخطأ
المصطلحات لأنهم كسالى ولا يستطيعون تعلم كلمة جديدة مناسبة ،
وإجبار علماء الرياضيات على استخدام المصطلحات الخاطئة ضد إرادتهم.

>

• سيكون وجود كلٍّ من الداخل والنقطة أمرًا مربكًا ، لأنهم سيفعلون ذلك
  يتطابق في بعض الحالات ولكن ربما لا يتطابق في حالات أخرى (إذا احتفظنا بالنقطة الحالية
  المعنى).

لسنا بحاجة إلى كليهما ، تخلص من الاسم الأقل عمومية ، والذي نتفق عليه
نقطة في هذه المرحلة.

>

• خارج الجبر الخطي ، للداخل الكثير من الإمكانات الأخرى
  معاني في علوم الكمبيوتر ، ومن ثم فهي مزعجة إلى حد ما
  تصدير هذا الاسم من Base.

خارج الجبر الخطي يمكنني أن أجد العديد من الاستخدامات للنقطة. المزيد حتى بالنسبة لـ
تدوين نقطي يعني أشياء مختلفة تمامًا.

>

أنا أعيد نشر آخر مشاركة juliohm بتنسيق ثابت.

ليست هناك أي من الأسباب مقنعة بالنسبة لي:

من الجيد أن يكون لديك متغير infix.

نعم ، ويمكن أن يظل تدوين اللاحم موجودًا بغض النظر عن إعادة التسمية إلى داخلي كما هو موضح أعلاه.

بالنسبة لغير الرياضيين الذين يعملون في مساحات شعاعية عادية ذات أبعاد محدودة ، فإن النقطة هي اسم مألوف أكثر للمنتج الداخلي الإقليدي. (سوف يتكيف علماء الرياضيات بسهولة مع استخدام اسم نقطة لوظيفة المنتج الداخلي على مسافات هيلبرت العشوائية - "المنتج النقطي" ليس له أي معنى آخر محتمل لمثل هذه المسافات.)

هذه الحجة ليست جيدة: فلنعلم الناس العاديين المصطلحات الخاطئة لأنهم كسالى ولا يمكنهم تعلم كلمة مناسبة جديدة ، ونجبر علماء الرياضيات على استخدام المصطلحات الخاطئة ضد إرادتهم.

قد يكون وجود كلٍّ من العناصر الداخلية والنقطة أمرًا محيرًا ، حيث أنهما سيتطابقان في بعض الحالات ولكن ربما لا يتطابقان مع حالات أخرى (إذا احتفظنا بالمعنى الحالي للنقطة).

لسنا بحاجة لكليهما ، تخلص من الاسم الأقل عمومية ، والذي نتفق أنه نقطة في هذه المرحلة.

خارج الجبر الخطي ، للداخلي الكثير من المعاني المحتملة الأخرى في علوم الكمبيوتر ، ومن ثم فإنه من المزعج إلى حد ما تصدير هذا الاسم من Base.

خارج الجبر الخطي يمكنني أن أجد العديد من الاستخدامات للنقطة. أكثر من ذلك بالنسبة إلى تدوين النقطة التي تعني أشياء مختلفة تمامًا.

نعم ، ويمكن أن يظل تدوين اللاحم موجودًا بغض النظر عن إعادة التسمية إلى داخلي كما هو موضح أعلاه.

يمكنك بالتأكيد تحديد const ⋅ = inner ، لكن المصطلحات الخاصة بك غير متسقة. اعتقدت أنك لا تحب استخدام "المنتج النقطي" كمنتج داخلي عام؟

يجبر علماء الرياضيات على استخدام المصطلحات الخاطئة ضد إرادتهم

يعرف علماء الرياضيات أن المصطلحات ليست صحيحة ولا خاطئة ، فهي فقط تقليدية أو غير تقليدية (وربما متسقة أو غير متسقة). (ومعظم الناس لا يتخصصون في الرياضيات لأن لديهم شغفًا بالتهجئة الإرشادية.) في تجربتي ، إذا أخبرت علماء الرياضيات أنه في ميكانيكا الكم يُطلق على المتجه "حالة" ، يُطلق على العنصر المساعد "خنجر" ، و المتجه المزدوج يسمى "حمالة الصدر" ، فهي غير مبالية إلى حد كبير. وبالمثل ، لا أعتقد أن أي عالم رياضيات متمرس سيومض أكثر من مرة إذا أخبرته أن المنتج الداخلي في جوليا مكتوب dot(x,y) أو x ⋅ y ، خاصة وأن المصطلحات مفهومة بالفعل على أنها المرادفات في سياقات كثيرة. (أشك في أنك ستجد أي عالم رياضيات لا يعرف على الفور أنك تشير إلى منتج داخلي إذا قلت "خذ المنتج النقطي لوظيفتين في مساحة الوظيفة هذه".)

من ناحية أخرى ، بالنسبة للأشخاص الذين لم يتم تدريبهم على الرياضيات ولم يتعرضوا لمساحات المنتج الداخلي المجردة (أي غالبية المستخدمين) ، فإن تجربتي هي أن المصطلحات غير المألوفة تمثل عقبة أكثر. "كيف آخذ حاصل الضرب النقطي لمتجهين في جوليا؟" سوف تصبح التعليمات.

لا توجد بالفعل صعوبة رياضية هنا يجب حلها بصرف النظر عن اختيار الدلالات. السؤال الإملائي هو مجرد سؤال يتعلق بالراحة والاستخدام.

خارج الجبر الخطي يمكنني أن أجد العديد من الاستخدامات للنقطة. أكثر من ذلك بالنسبة إلى تدوين النقطة التي تعني أشياء مختلفة تمامًا.

باستثناء أن جوليا والعديد من لغات البرمجة الأخرى لديها dot لسنوات ولم تكن مشكلة. inner سيكون كسرًا جديدًا.

في النهاية ، يعد تهجئة هذه الوظيفة (أو أي وظيفة أخرى) أمرًا بسيطًا مقارنةً بالدلالات ومسار الإهمال ، لكنني أعتقد أن نصائح الرصيد لصالح dot .

يمكنك بالتأكيد تحديد const ⋅ = الداخلية ، ولكن المصطلحات الخاصة بك غير متسقة. اعتقدت أنك لا تحب استخدام "المنتج النقطي" كمنتج داخلي عام؟

أعتقد أنك ما زلت لا تفهم ذلك. لا يوجد تناقض في استدعاء النقطة منتج داخلي. إنه منتج داخلي ، وهو منتج محدد للغاية وغير مفيد للكثير منا. ليس أكثر من sum(x.*y) .

إذا انتهى الأمر بالمصطلح dot في Julia حيث يحتوي على دلالات inner ، فستكون هذه كارثة تاريخية يمكنني أن أضمن لك أن الكثيرين سيشعرون بالانزعاج منها. يمكنني أن أتوقع أن يشرح الأساتذة في الفصل أشياء مثل: "كما تعلم ، سنقوم الآن بتعريف المنتج الداخلي لمساحتنا ، ولكن في جوليا قرر شخص ما (stevengj) تسميته نقطة."

سأتأكد من أنني سأقوم بتصوير هذا الموضوع للرجوع إليه في المستقبل إذا حدث ذلك.

أنت الوحيد الذي يصر على stevengj على المصطلحات dot ، لم يبد أي شخص آخر معارضته لها. سيكون من الجيد أن تعيد النظر في هذه الحقيقة قبل اتخاذ قرار.

إنه منتج داخلي ، وهو منتج محدد للغاية وغير مفيد للكثير منا. لا شيء أكثر من مجموع (س. * ص).

إذا كنت تعتقد أن "المنتج النقطي" يمكن أن يشير فقط إلى المنتج الداخلي الإقليدي في ℝⁿ ، فلا يجب عليك تحديد const ⋅ = inner ، يجب عليك تحديد ⋅(x::AbstractVector{<:Real}, y::AbstractVector{<:Real}) = inner(x,y) فقط.

لا يمكنك الحصول على كلتا الطريقتين: إما inner يمكنه استخدام ⋅ كمرادف infix (في هذه الحالة يكون عامل infix "خاطئًا" في لغتك والتسمية غير متسقة) أو لا يحتوي على مرادف infix (باستثناء حالة خاصة واحدة).

يمكنني أن أتوقع أن يشرح الأساتذة في الفصل أشياء مثل: "كما تعلم ، سنقوم الآن بتعريف المنتج الداخلي لمساحتنا ، ولكن في جوليا قرر شخص ما (stevengj) تسميته نقطة."

ها ها ، أنا على استعداد لأخذ حرارة هذا الأستاذ الغاضب الوهمي. على محمل الجد ، أنت بحاجة للنظر حولك أكثر إذا كنت تعتقد أن مصطلح "المنتج النقطي" لا يستخدم إلا في ℝⁿ ، أو أن علماء الرياضيات غاضبون إذا تم استخدام المصطلح في مساحات هيلبرت الأخرى.

ستكون هذه كارثة تاريخية

عنجد؟

يبدو أن هذه المناقشة آخذة في التآكل إلى ما هو أبعد مما يمكن اعتباره بيئة ترحيبية ومدنية وبناءة . تختلف الآراء والخلفيات ، ولكن يرجى الامتناع عن شن هجمات شخصية أو إلقاء اللوم على أي شخص وافترض أن جميع الأطراف تناقش وجهة نظرها بحسن نية.

يمكنني أن أتوقع أن يشرح الأساتذة في الفصل أشياء مثل: "كما تعلم ، سنقوم الآن بتعريف المنتج الداخلي لمساحتنا ، ولكن في جوليا قرر شخص ما (stevengj) تسميته نقطة."

قد يكون من المفيد هنا أيضًا أن نلاحظ أن ستيفن _ هو أستاذ جامعي. :غمزة:

أنا أيضًا على الحياد بشأن إزالة dot لصالح inner . مصطلح dot مستخدم على نطاق واسع ، وعدم وجود الوظيفة في Julia ، عندما يكون في Python و 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) ليكون المعيار 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 لكن ليس المعيار p. استدعاء norm بشكل متكرر هو أيضًا ما يفعله vecnorm الآن ، لذا فهو متسق مع إهمال vecnorm إلى norm .

jebej ، dot على كل من الرئيسي و 0.6 يعمل بالنسبة لي على مصفوفات معقدة: على سبيل المثال ، إرجاع $ dot([3im],[4im]) بشكل صحيح 12+0im .

نقطة أخرى جيدة حول تغيير norm(matrix) ليكون معيار Frobenius هو أنه أرخص كثيرًا. من الشائع استخدام 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

و أكثر من ذلك بكثير...

يمكن للناس أن يتجادلوا بصوت عالٍ مع بعضهم البعض ، ويثيروا العديد من نقاط الخلاف ، ولكن لا يزالون يتوصلون إلى إجماع (وإن لم يكن الإجماع دائمًا) من خلال إقناعهم وموازنة الإيجابيات / السلبيات. (أوافق على أن هناك إيجابيات وسلبيات لكل خيار هنا.) أنا آسف لأن النتيجة التي تبدو (مبدئيًا!) لتكون جيدة هنا ليست النتيجة التي تفضلها ، لكنني لست متأكدًا من طريقة تفكيرك أنا "فرضت" إرادتي.

(لا يعني ذلك أنه تم اتخاذ أي قرار نهائي ، بالطبع - لا توجد علاقات عامة حتى الآن ، ناهيك عن أي شيء مدمج.)

أتمنى فقط أن نتمكن من اتخاذ قرار يعتمد على جمهور اللغة. إذا اختار شخص ما Julia كأداة ، فأنا متأكد من أن الشخص قد سمع على الأقل عن المصطلح inner product. إنه مفهوم شائع جدًا وبعيدًا عن كونه غريبًا. تشمل الأشياء الغريبة "التنادد المستمر" و "نظرية الكم" ، وهي أقل انتشارًا ، وسأعارض تضمين هذا النوع من المصطلحات.

بعد كل شيء ، أريد فقط أن أحصل على لغة هي أفضل لغة للحوسبة العلمية والرياضيات وما إلى ذلك.

juliohm ، استندت جميع الحجج إلى احتياجات من نعتقد أن الجمهور هو ، ونحن جميعًا نحاول جعل لغة جوليا جيدة قدر الإمكان. يمكن للأشخاص العقلاء أن يتوصلوا إلى استنتاجات مختلفة حول المصطلحات ، لأن الرياضيات لا تحدد التهجئة.

أولاً ، كما ذكر أعلاه ، يمكنني بالتأكيد الموافقة على اقتراحstevengj الحالي والتمسك بـ dot كاسم عام للمنتج الداخلي. أيضا ، أنا لا أحب الطريقة التي تسير بها هذه المناقشة وأود بالتأكيد أن يتم اقتباسها بشكل صحيح. juliohm ، الاقتباس الثاني الذي تنسبه إلي ليس لي.

ومع ذلك ، أود أن أذكر ما يلي كغذاء للفكر عند النظر في الإيجابيات والسلبيات. فيما يلي في الغالب سلبيات ، لكنني أتفق مع الإيجابيات التي ذكرهاstevengj. يمكن بسهولة أن تكون هناك حالات استخدام منفصلة لوجود dot يعني فقط sum(x[i]*y[i] for i ...) . في الحالات التي يتم فيها استخدام تدوين النقطة infix في الرياضيات ، يكون هذا هو المعنى عادةً. كمنتج داخلي ، عادةً ما يتم الاحتفاظ بالتدوين النقطي (على الرغم من أنه ليس حصريًا) للمساحات المتجهة الحقيقية. تتضمن حالات الاستخدام الأخرى تمكين أشياء مثل σ ⋅ n مع σ متجه لمصفوفات Pauli و n متجه من الحجميات. كان هذا أحد الدوافع وراء الطريقة التي يتم بها تطبيق dot حاليًا ، كما أشرت لي في موضوع آخر. حقيقة أن BLAS قررت فقط استخدام dot للمتجهات الحقيقية والتمييز بين dotu و dotc للمتجهات المعقدة هي مسألة أخرى يجب مراعاتها. قد يتم الخلط بين الأشخاص الذين لديهم خلفية BLAS سواء ، لديهم متجهات معقدة ، يريدون حساب dot(conj(u),v) أو dot(u,v) عندما يريدون المنتج الداخلي الحقيقي (أي dotc ). علاوة على ذلك ، قد يبحثون عن طريقة للقيام بـ dotu بدون عمل نسخة مترافقة من المتجه في متناول اليد.

Jutho الاقتباس لك ، تم نسخ تعليقك بالكامل أدناه:

أوافق ، كبديل لـ vecdot ، يمكننا تقديم طريقة داخلية جديدة ، لكنني لا أعرف اسمًا جيدًا لـ "استبدال" vecnorm. في الواقع ، لا أجد أن المعيار المتجه السيئ هو مصطلح راسخ وواضح للعملية التي نريدها.

على أي حال ، فإن المقصود بالاقتباس هو إظهار رغبة الكثيرين هنا (على الأقل كفكرة طبيعية أولى) عندما نفكر في هذا الموضوع. إذا غيرت رغبتك بمرور الوقت ، فهذه قصة أخرى. أنا بنفسي لن أخرج مصطلح "نقطة" من رأسي أبدًا أثناء أي عرض باستخدام مساحات هيلبرت. إنه شعور غير طبيعي وغير متوافق مع ما تعلمته.

Jutho : علاوة على ذلك ، قد يبحثون عن طريقة للقيام بـ 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) هو المنتج الداخلي الصالح دائمًا ، مع الاقتران والتكرار ، والذي سيستخدمه الأشخاص في السياقات الفنية العامة.

أنا لا أدافع عن هذا كخيار جيد لاعتماده في لغة جوليا ، لكنني أعتقد أن هذه هي الطريقة المستخدمة في كثير من الأدبيات. عند استخدام infix dot ، يكون إما منتجًا داخليًا في سياق نواقل حقيقية ، أو في بعض الإنشاءات العامة حيث يعني ذلك فقط الانكماش. عندما يكون المقصود من منتج داخلي عام على مساحات متجهية عشوائية ، فإن معظم المؤلفات العلمية (لكنك بالتأكيد قد عرضت أمثلة مضادة) تتحول إلى <u,v> أو <u|v> (حيث لا يزال هناك نقاش في التدوين الأول أي من الحجتين مترافقين).

يمكنني التعايش مع هذا الاقتراح ، لكن يمكنني العيش بشكل جيد مع امتلاك فقط dot كمنتج داخلي عام. في النهاية ، يتعلق الأمر بالحصول على وثائق جيدة ، وأنا أيضًا لا أصدق أن أي شخص قد يتعثر في اختيار "التصميم" هذا.

Jutho ، أوافق على أنه ليس من غير المألوف تحديد dot ليعني الانكماش فقط. بالتأكيد ، يمكن للمرء أن يجد أمثلة في كلا الاتجاهين. على سبيل المثال ، في لغات البرمجة والمكتبات الشعبية:

• غير مقترن: Numpy dot (وغريبًا ، داخلي ) ، Mathematica Dot ، Maxima . ، BLAS dotu

• مقترن: Matlab's dot ، Fortran's DOT_PRODUCT ، Maple's DotProduct ، Petsc VecDot ، Numpy vdot ، BLAS dotc (لاحظ أن نقص التحميل الزائد في Fortran 77 جعل من المستحيل استدعاء هذا dot حتى لو أرادوا) ، نقطة Eigen

من ناحية أخرى ، عادةً ما يتم تقديم المنتج الداخلي المقترن في الكتب المدرسية باعتباره الامتداد "الطبيعي" لمفهوم "المنتج النقطي" إلى ناقلات معقدة - النسخة غير المقترنة هي بمعنى ما امتداد "غير طبيعي" ، من حيث أنها ليست عادةً ما تريد. (ضع في اعتبارك حقيقة أنه من بين اللغات التي توفر وظيفة dot مصاحبة في مكتباتهم القياسية - Matlab و Fortran و Julia و Maple - فقط Maple توفر متغيرًا غير مرتبط ، مما يشير إلى نقص الطلب.) من ناحية أخرى ، فإن وظيفة dotu غير المقترنة ملائمة (كمكمل) في بعض الحالات الخاصة (التي ذكر بعضها أعلاه).

إذا كان لدينا كل من dot و inner ، أظن أن العديد من الأشخاص سينتهي بهم الأمر باستخدام dot بالصدفة عندما يريدون حقًا inner لكودهم نوعي. (أراهن أن Numpy inner غير مقترن بسبب حادث كهذا - لقد قاموا بتطبيقه مع وضع المصفوفات الحقيقية في الاعتبار ، ولم يفكروا في الحالة المعقدة حتى فات الأوان لتغييرها لذا أضافوا المسمى المحرج vdot .) بينما إذا كان لدينا dot و (ربما) dotu ، سيكون من الواضح أن dot هو الخيار الافتراضي و dotu هو متغير الحالة الخاصة.

(أوافق على أن ⟨u,v⟩ ، ⟨u|v⟩ ، أو (u,v) هي رموز أكثر شيوعًا للمنتجات الداخلية على مساحات Hilbert التعسفية - إنها ما أستخدمه عادةً بنفسي - ولكن هذه الرموز هي nonstarter لـ Julia. كان هناك بعض النقاش حول تحليل أقواس Unicode كمكالمات دالة / ماكرو ، على سبيل المثال # 8934 و # 8892 ، لكنها لم تذهب أبدًا إلى أي مكان ويبدو من غير المحتمل أن يتغير هذا قريبًا.)

أتفق تمامًا مع تقييمكstevengj .

أنا أيضا.

أظن أن الوقت قد حان لكي يلعب أحدنا مع أي من التطبيقين في العلاقات العامة ويرى كيف سيظهر.

Jutho لقد رأيت دائمًا المنتج النقطي مع مصفوفات Pauli كاختصار للانكماش على موترات الترتيب الأعلى ... أحد مسافات المتجه حقيقي ، ثلاثي الأبعاد.

أوافق على أن ⟨u أو v⟩ أو ⟨u | v⟩ أو (u ، v) هي أكثر الرموز شيوعًا للمنتجات الداخلية على مساحات هيلبرت التعسفية - إنها ما أستخدمه عادةً بنفسي - لكن هذه الرموز ليست نقطة انطلاق لجوليا.

سيكون من الممكن بالفعل جعل ⟨u,v⟩ يعمل.

@ StefanKarpinski : سيكون من الممكن بالفعل جعل ⟨u ، v⟩ يعمل.

بالتأكيد ، ودعم هذا الترميز الدقيق تم اقتراحه في # 8934 ، لكنه لم يذهب أبدًا إلى أي مكان. (لاحظ أيضًا أن الأقواس الزاوية لها استخدامات شائعة أخرى ، على سبيل المثال ، تشير ⟨u⟩ غالبًا إلى متوسط ​​من نوع ما.) وهي غير قابلة للكسر ويمكن إضافتها في وقت ما ، ولكن لا يبدو من المعقول توقعها في القريب مصطلح. كما أن كتابة \langle<tab> x, y \rangle<tab> بطيئة جدًا ، لذا فهي ليست ملائمة جدًا من وجهة نظر البرمجة لعملية أولية.

ولا يمكننا أن نفرط في التحميل ، أليس كذلك؟

رقم

لا أستطيع أن أقول أنني قرأت كل تعليق على هذا الخيط الضخم ، لكني أريد فقط أن أسلط الضوء على بعض النقاط ، والتي تم ذكر بعضها من قبل:

• يبدو التمييز بين النقطة والداخلية متحذلقًا بشكل مفرط. في الواقع يبدو الأمر غير منطقي بالنسبة لأذني لأنه يوجد في الفرنسية مصطلح واحد فقط - "منتج عددي" - ومن الصعب التفريق بين الأشياء التي تحمل نفس الاسم بالنسبة لي ؛-)
• عندما تكون قادمًا من numpy وتعمل مع مصفوفات معقدة ، فإن اقتران dot افتراضيًا هو أفضل شيء على الإطلاق. لا توجد نقطة قرار هنا ، أردت فقط أن أوضح مدى سعادتي لأنني لم أعد مضطرًا للقيام بهذه conj(dot()) s!
• إن وجود وظيفتين لهما نفس السلوك في معظم الحالات ولكنهما يختلفان أحيانًا هو تصميم سيء ، وقد تسبب في ارتباك وسيؤدي إلى ارتباك ، مع رمز يجب أن يستدعي أحدهما الآخر فعليًا ، وذلك ببساطة لأن المستخدم لا يعرف أفضل. هذا أمر مزعج بشكل خاص مع norm : إذا كنت تقوم بترميز خوارزمية تحسين وتريد التوقف كلما norm(delta x) < eps ، فستكتب norm . ولكن بعد ذلك تريد تحسين كتابة صورة أو شيء ما ، تقوم بتشغيل الكود الخاص بك ، ويتم تشغيله فجأة في شكل SVD لا يمكن القضاء عليه (لأن BLAS) من مصفوفة كبيرة. هذا ليس أكاديميًا ، لقد تسبب في مشاكل في Optim.jl ، ولا شك في الحزم الأخرى أيضًا. لن يعرف أحد أن vecnorm موجود ما لم يكن لديهم سبب محدد للبحث عنه.
• بناءً على النقطة السابقة ، فإن أي حل يدمج dot و vecdot و norm و vecnorm هو حل جيد ، حتى لو كان يزيل القليل من المرونة في حالات مصفوفة المصفوفات. بالنسبة للمعايير ، أود أن أضيف ذلك غالبًا عند العمل مع الأشياء التي يتم تحديد معايير متعددة عليها (مثل المصفوفات) ، فإن ما يريده المستخدم هو الاتصال بـ norm للحصول على معيار ، دون الاهتمام بشكل خاص بأي معيار. غالبًا ما تكون المعايير المستحثة ذات أهمية نظرية وليست عملية بسبب استعصائها الحسابي. كما أنها مخصصة لتفسير المصفوفة ثنائية الأبعاد كعامل تشغيل بدلاً من المصفوفة ثنائية الأبعاد كمخزن (الصورة عبارة عن مصفوفة ثنائية الأبعاد ، ولكنها ليست عاملًا بأي معنى مفيد). من الجيد أن يكون لديك إمكانية حسابهم ، لكنهم لا يستحقون أن يكونوا الافتراضي norm . تعتبر الافتراضات المعقولة والبسيطة والموثقة جيدًا والتي تحتوي على بدائل قابلة للاكتشاف أفضل من محاولة الذكاء (إذا كان المستخدم يريد أن يفعل شيئًا ذكيًا ، دعه يفعل ذلك صراحة).

لذلك ، +1 على stevengj 's

نعم ، أعتقد أنه إذا أجرينا هذا التغيير ، فإننا نحتاج فقط إلى النقطة والمعيار (وهما الآن العمليات الإقليدية العودية على المصفوفات أو مصفوفات المصفوفات من أي بُعد ، على الرغم من أننا نحدد القاعدة أيضًا (س ، ع) لتكون the p-norm) و opnorm ، ولم يعد لديها vecdot أو vecnorm.

قد يكون البديل الأكثر "جوليان" للقاعدة / opnorm هو أن يكون لديك نوع عامل ، والذي يمكن أن يلف مصفوفة ثنائية الأبعاد ، حيث يعمل norm الوضع الطبيعي. يمكن القيام بذلك على مستوى الحزم (العديد منها موجود بالفعل)

أفضل كتابة opnorm(matrix) بدلاً من norm(Operator(matrix)) …

سأقوم بالتناغم من معرض الفول السوداني هنا وأقول إنني أحب إلى أين يذهب هذا - vecnorm و vecdot لطالما أزعجني. إن الحاجة إلى السؤال الصريح عن معيار المشغل - الذي بدا دائمًا متخصصًا إلى حد ما بالنسبة لي - يبدو أكثر عقلانية من الاضطرار إلى طلب معيار أسرع وأسهل في الحساب (على سبيل المثال ، معيار Frobenius). تبدو كتابة opnorm واجهة رائعة لطلب معيار عامل التشغيل المتخصص نسبيًا.

أشعر أيضًا أن التمييز الدقيق بين dot و inner من المحتمل أن يؤدي إلى الارتباك وسوء الاستخدام المستشري. إلقاء محاضرة على المستخدمين حول الوظيفة التي _فرض عليهم _ استخدامها عندما تقوم كلتا الوظيفتين بما يريدونه ويكون من الأسهل عدم نجاح إحداهما بشكل جيد. انطباعي هو أنه من النادر نسبيًا في الكود العام أن يكون 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]) بسيط. من السهل تخطي الرمز ⋅ بالعين ، وله العديد من الدلالات الأخرى. على وجه الخصوص ، في الجبر الخطي ، بالنسبة لمساحة المتجه V فوق الحقل F ، يتم الإشارة إلى ناتج الحجم القياسي α ∈ F مع المتجه v ∈ V α ⋅ v في الكتب المدرسية المختلفة.

• ستؤدي إزالة أو استبدال ⋅ أيضًا إلى التخلص من مشكلة الأسماء المتعددة التي يتم تصديرها. سيتعين على المرء فقط تصدير inner و <,> للمنتجات الداخلية العامة ، مع التنفيذ الافتراضي للمصفوفات التي تتطابق مع دلالات التجميع القابلة للتكرار.

• إذا احتاج المرء إلى تعريف منتج متجه بخط متجه كما هو موضح أعلاه لمساحة متجه V فوق حقل F ، فسيكون قادرًا على تحديد رمز ⋅ له. سيتم بعد ذلك تحديد مساحة المتجه بالكامل باستخدام بناء جملة قصير لطيف ، ويمكن تمديدها إلى مساحة هيلبرت عن طريق تحديد <u,v> .

بالتأكيد لا يمكننا استخدام الصيغة <u,v> ؛ الصيغة التي يمكننا استخدامها هي ⟨u,v⟩ —لاحظ أقواس Unicode ، وليس أقل من وأكبر من العلامات ، < و > . لدينا أيضًا u'v كتركيب لشيء إما منتج نقطي أو منتج داخلي؟ (لست متأكدًا من ...)

نعم ، آسف ، نسخة يونيكود منه. سيكون من الواضح جدا للقراءة. سيؤدي أيضًا إلى حل هذه المشكلة بأسماء متعددة ، و ⋅ مجانًا لأغراض أخرى.

لا أعتقد أننا نريد استخدام ⋅ لأي غرض آخر - يبدو أنه سيكون محيرًا.

فقط تخيل كم سيكون رائعًا أن تكون قادرًا على كتابة رمز يشبه:

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

للمتجهات المجردة (أو الأنواع) u,v,w,z ∈ V و scalars α, β ∈ F .

u'v منتج داخلي (ومنتج نقطي ، إذا اتبعت الاصطلاح المترافق) فقط لمصفوفات 1d ، وليس لمصفوفات على سبيل المثال. (هذا سبب آخر يجعل من غير المجدي حصر نقطة infix في المصفوفات 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 يبدو أن المساحة الكاملة للخيارات (مرة أخرى مع خصم عوامل التشغيل) هي:

1- كسر dot بصمت في متجهات المصفوفات عن طريق تغيير السلوك في 0.7 إلى منتج داخلي بدون تحذير قياسي (على الرغم من أنه يمكنك التحذير من تغيير السلوك). خفض vecdot إلى dot في 0.7 أيضًا.
ثانيًا. في 0.7 ، قم بإهمال vecdot على جميع المدخلات إلى inner .
ثالثا. في 0.7 ، قم بإهمال dot على ناقلات المصفوفات لتعريفها ، و dot على المدخلات الأخرى و vecdot على كل المدخلات إلى inner .
رابعا. في 0.7 ، قم بإهمال كلاً من dot و vecdot على متجهات المصفوفات إما للوظائف غير المُصدرة أو لتعريفاتها ، و vecdot على جميع المدخلات الأخرى إلى dot . في 1.0 ، أضف dot على متجهات المصفوفات ذات دلالات المنتج الداخلية.

بالنسبة للجانب المعياري ، هناك بعض الإجماع حول مسار واحد (في 0.7 ، قم بإهمال norm على المصفوفات إلى opnorm وربما يتم إهمال vecnorm إلى innernorm ؛ في 1.0 ، أضف norm على المصفوفات مع الدلالات الحالية vecnorm ) ، ولكن ينتج عن ذلك أيضًا اسم إضافي في 1.0 (إما vecnorm أو innernorm ) ؛ مرة أخرى ، هناك طريقة لتجنب ذلك قد تتمثل في إهمال vecnorm في 0.7 لتعريفه أو لوظيفة غير مُصدرة مثل Base.vecnorm بدلاً من اسم مُصدَّر.

...أظن. آمل ألا أجعل الأشياء أكثر طراوة مما كانت عليه بالفعل.

هل يمكن لأي شخص على دراية بقاعدة الشفرة تقديم علاقات عامة للتغيير؟

هل يمكننا فصل الأشياء المعيارية التي يبدو أن الجميع يتفقون عليها وإنجاز ذلك على الأقل؟ إن dot مقابل inner بت أكثر إثارة للجدل إلى حد ما ، لكن دعونا لا ندع هذا يعيق الجزء الذي ليس كذلك.

StefanKarpinski ، لاحظ أنهما مرتبطان إلى حد ما: بالنسبة للأنواع التي يكون لديك فيها منتج نقطي (داخلي) وقاعدة ، يجب أن يكونا متسقين.

حسنًا ، أنا لا أهتم حقًا بالطريقة التي يسير بها هذا. من يقوم بالعمل يقرر.

كان لدي PR (# 25093) لأجعل vecdot يتصرف كمنتج داخلي حقيقي (و vecnorm هو المعيار المقابل) ، بجعلهم متكررين. قد يكون هذا مفيدًا كنقطة بداية لكيفية ظهور dot و norm في المستقبل. لسوء الحظ ، فإن افتقاري لمهارات git جعلني أفشل تلك العلاقات العامة ، لذلك أغلقتها ، وأخطط للعودة إليها بعد اكتمال بناء جملة التكرار الجديد.

ومع ذلك ، فكوني أصبح أبًا للمرة الثانية منذ بضعة أيام يعني أنه لا توجد حاليًا فترات "وقت فراغ" في التقويم الخاص بي.

بعد أن أصبح أبًا للمرة الثانية منذ بضعة أيام

مبروك Jutho! 🎉

نعم ، مبروك!

يبدو أنه قد يكون هناك بعض الإجماع حول فكرة وجود كل من dot و inner ، حيث:

1. inner منتج داخلي تكراري حقيقي
2. dot = dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) مترافق أم لا ، وبالتالي سيتداخل مع dot لـ Vector{<:Number} أو Vector{<:Real}

بخصوص:

كثير من الناس يكتبون نقطة عندما يقصدون داخليًا ، وستعمل بشكل جيد بالنسبة لهم في معظم الحالات ، ولكن بعد ذلك ستفعل التعليمات البرمجية الخاصة بهم شيئًا غير متوقع إذا تم تمرير مصفوفة من المصفوفات.

لا أعتقد أن هذا سيكون مشكلة. نظرًا لأن هذه عملية غير شائعة إلى حد ما ، أتوقع أن يحاول الناس على الأقل معرفة ما تفعله و / أو الاطلاع على الوثائق.

أعتقد أن ما ورد أعلاه سيكون تغييرًا كبيرًا ، ولن يكون مزعجًا للغاية لأن دلالات 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) هي رموز أكثر شيوعًا للمنتجات الداخلية على مسافات هيلبرت التعسفية - إنها ما أستخدمه عادةً بنفسي - ولكن هذه الرموز ليست نقطة انطلاق لجوليا . كان هناك بعض النقاش حول تحليل أقواس Unicode كمكالمات دالة / ماكرو ، على سبيل المثال # 8934 و # 8892 ، لكنها لم تذهب إلى أي مكان ، ويبدو من غير المرجح أن يتغير هذا قريبًا.)

stevengj ، عندما أضفت هذه الفقرة إلى تعليق سابق بنفسك ، هل تقصد أن بناء الجملة ⟨u,v⟩ صعب التنفيذ في اللغة؟

أي فرصة لهذه الميزة أن تجعلها إلى Julia v1.0؟ لدي الكثير من الأفكار والحزم التي تعتمد على فكرة المنتجات الداخلية العامة. يرجى إعلامي إذا كان ينبغي علي تقليل توقعاتي. آسف للتذكير المستمر.

هل لم تر # 27401؟

شكرا لك jebej وشكرا لك ranocha لأخذ زمام المبادرة: القلب:

عندما أضفت هذه الفقرة إلى تعليق سابق بنفسك ، هل قصدت أن بناء الجملة ⟨u، v⟩ يصعب تنفيذه في اللغة؟

ليس من الصعب إضافة إلى المحلل اللغوي تقنيًا ، ولكن ثبت أنه من الصعب التوصل إلى إجماع حول كيفية (وما إذا كان) سيتم تمثيل الأقواس المخصصة في اللغة. شاهد المناقشة في # 8934 ، والتي لم تذهب إلى أي مكان منذ 4 سنوات ولم يتم إحياؤها منذ ذلك الحين. (أضف ذلك إلى حقيقة أنه في المجالات المختلفة يستخدم الأشخاص نفس الأقواس للعديد من الأشياء المختلفة ، على سبيل المثال ، يتم استخدام ⟨u⟩ لمعدلات المجموعات في الفيزياء الإحصائية.) هناك قضية أخرى ، أثيرت في # 8892 ، وهي التشابه البصري للعديد من Unicode المختلفة اقواس.

شكرا لك stevengj ، وأنا أقدر التوضيحات. أنا بالفعل متحمس جدًا لأننا سنحصل على منتجات داخلية عامة موحدة عبر الحزم. : 100: ربما يمكن أن يتألق تدوين قوس الزاوية في دورة إصدار أخرى في المستقبل. ليس بنفس القدر من الأهمية ، ولكنه مناسب تمامًا لتكون قادرًا على كتابة كود مشابه للرياضيات في منشوراتنا.

إذا كان ⟨args...⟩ بناء جملة صالحًا لاستدعاء عامل التشغيل anglebrackets أو شيء ما (ما نسميه الوظيفة التي يستدعيها بناء الجملة هذا صعب نوعًا ما نظرًا لأنه ليس لدينا أي سابقة) ، فيمكن للأشخاص اختيار أي معنى يريدونه لبناء الجملة.

StefanKarpinski ، الحجة في # 8934 كانت أنه يجب أن يكون ماكرو. لا أعتقد أننا توصلنا أبدًا إلى توافق في الآراء.

(إذا قررنا في Base أن anglebrackets(a,b) يعني inner(a,b) ، فهذا سيثني الناس عن "اختيار أي معنى يريدونه" لأن القرار قد تم اتخاذه بالفعل.
إنه ليس خيارًا سيئًا ، بالطبع ، ولكن قد يكون من غير الضروري تعيين هذا المعنى في Base طالما تم تحليله.)

لا أتذكر تفاصيل تلك المناقشة ولكن يبدو أن صنع ماكرو فكرة سيئة بالنسبة لي.

مع # 27401 ، أعتقد أنه يمكننا اعتبار المنتجات الداخلية على محمل الجد.

تقليديًا ، يتم إغلاق المشكلة فقط عند دمج العلاقات العامة ذات الصلة ...

بالتأكيد ، يمكننا تركه مفتوحًا على ما أعتقد. أردت فقط إخراجها من بطاقة الفرز.

هل يجب إغلاق هذا لأن # 27401 مدمج الآن؟