جاء هذا في https://github.com/pytorch/pytorch/issues/33568. هذا يبدو غريبا:
>>> np.clip([3 + 4.j], -1, 2)
array([2.+0.j])
>>> np.clip([3 + 4.j], -1+1.j, 2+12.j) # imaginary component goes up
array([2.+12.j])
>>> np.clip([1 + 4.j], -1+1.j, 2+12.j) # imaginary component doesn't go up
array([1.+4.j])
الاختبار الوحيد للإدخال المعقد هو أنه لا يخطئ.
يمكن أن يكون السلوك المعقول أحد:
لا أعتقد أن هذه مسألة مهمة للغاية ، ولكن سيكون من الجيد على الأقل أن يتم توثيق السلوك المطلوب هنا.
السلوك الحالي هو جعل x = sorted(x)
مقابل x = [min, clip(arr, min, max), max]
، على ما أعتقد.
أشك في أنه من المفيد كسر الاتساق مع min ، max ، الفرز هنا لاختيار سلوك غير واضح. لا يعني ذلك أننا لا نستطيع فعل ذلك ، ولكن ربما ينبغي علينا أيضًا مناقشة الحد الأدنى / الحد الأقصى وسلوك الفرز ...
وإذا كان هذا يعني أن absmin
و absmax
و abssort
سيكون منطقيًا ويستخدم ذلك بشكل أساسي للقص.
يمكن أن أكون أكثر اقتناعًا بمجرد إعطاء خطأ لمدخلات غير حقيقية.
تحرير: يمكن القول إن القطع المكون يسمح في الواقع بسلوك Erics ، لأنه أكثر صرامة. لكن مجرد ملاحظة ، لست متأكدًا من أنني أشتريها على أنها مفيدة. والسؤال الآخر هو: هل هناك أي نموذج التطبيقي الفعلي لهذا على الإطلاق؟ واحد غير أوضح برمز مختلف؟
قص الأجزاء الحقيقية والخيالية بشكل منفصل
من شأنه أن يكون خياري الاول.
قص القيمة المطلقة ، وليس تغيير المرحلة
قد يكون مفيدًا ولكن تنفيذه أكثر تعقيدًا من مقطع بسيط.
السؤال الآخر هو: هل هناك أي حالة فعلية لهذا الأمر على الإطلاق؟ واحد غير أوضح برمز مختلف؟
هذا سؤال جيد. لست متأكدا. كل ما أعرفه هو أنه لا ينبغي أن يكون غير صحيح بشكل واضح.
أنا قلق بشأن قص الأجزاء الحقيقية والخيالية بشكل منفصل. إذا كان لدينا مصفوفة مرتبة ، على سبيل المثال ، فإن القطع عادةً ما يغير المصفوفة إلى ثلاث مناطق: [min_value، unchanged، max_value]. إذا قمنا بقص الأجزاء الحقيقية والخيالية من مصفوفة معقدة بشكل منفصل ، فلن نمتلك هذه المناطق القابلة للفصل بعد الآن. بدلاً من ذلك ، قد تتغير القيم حتى لو لم تقارن بأقل من الحد الأدنى أو أكبر من الحد الأقصى!
أوصي أيضًا بتعطيل السلوك حتى تكون هناك ثقة بشأن ما يجب أن يفعله قص رقم معقد بالضبط. قد يكون اقتراحي أنه إذا كانت c <min_value قد تم ضبطها على min_value ، وإذا كانت c> max_value مضبوطة على max_value.
mruberry ، وافقت ، على أي حال ، لست متأكدًا من أن أي شخص لديه حتى حالة استخدام لهذا الأمر ، مما min.real <= max.real
و min.imag <= max.imag
بدلاً من min <= max
، فإن الأمور على ما يرام (على الرغم من أننا لا نفعل ذلك حاليًا تأكد من ذلك في NumPy).
أنا أتفق معك أيضًا seberg ؛).
أعتقد أننا سنقوم بتعطيل المدخلات المعقدة في PyTorch (نسميها clamping) في الوقت الحالي. كان سلوكنا غير متسق مع NumPy's ، على أي حال.
بمجرد قراءة هذه المسألة ، أعتقد أنه بالنظر إلى المقارنة المعجمية في numpy ، فإن هذا السلوك منطقي بالفعل. إذا كنا نستبعد المقارنة المعجمية ، فيجب أيضًا اتباع المقطع ، والحد الأقصى ، والدقيقة. أفترض أن هذا كان الإجماع الذي تم التوصل إليه هنا ، لكنني لم أكن متأكدًا تمامًا من التعليقات والعلاقات العامة المرتبطة.
التعليق الأكثر فائدة
mruberry ، وافقت ، على أي حال ، لست متأكدًا من أن أي شخص لديه حتى حالة استخدام لهذا الأمر ، مما
min.real <= max.real
وmin.imag <= max.imag
بدلاً منmin <= max
، فإن الأمور على ما يرام (على الرغم من أننا لا نفعل ذلك حاليًا تأكد من ذلك في NumPy).