Numpy: np.floor_divide يسقط الجزء التخيلي بصمت

تم إنشاؤها على ١ أبريل ٢٠١٩  ·  13تعليقات  ·  مصدر: numpy/numpy

مثال على إعادة إنتاج الكود:

import numpy as np
a = np.arange(10) + 1j* np.arange(10)
a
# array([0.+0.j, 1.+1.j, 2.+2.j, 3.+3.j, 4.+4.j, 5.+5.j, 6.+6.j, 7.+7.j,
#           8.+8.j, 9.+9.j])
a / 2
# array([0. +0.j , 0.5+0.5j, 1. +1.j , 1.5+1.5j, 2. +2.j , 2.5+2.5j,
#          3. +3.j , 3.5+3.5j, 4. +4.j , 4.5+4.5j])
a // 2
# array([0.+0.j, 0.+0.j, 1.+0.j, 1.+0.j, 2.+0.j, 2.+0.j, 3.+0.j, 3.+0.j,
#          4.+0.j, 4.+0.j])

هل هناك سبب خاص لهذا السلوك؟ أتوقع أن أقوم بتقسيم الجزء التخيلي والمعقد.

رسالة خطأ:

لم يتم إلقاء أي خطأ أو تحذير ، ولا حتى هذا الجزء التخيلي يضيع.

معلومات إصدار Numpy / Python:

1.16.1
3.6.7 (افتراضي ، 22 أكتوبر 2018 ، 11:32:17)
[GCC 8.2.0]

00 - Bug 15 - Discussion numpy.ufunc

ال 13 كومينتر

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

أيضا ،
`>>> (1. + 1.j) // 2

Traceback (أحدث مكالمة أخيرة):
ملف ""، السطر 1 ، في
TypeError: لا يمكن أخذ أرضية لرقم مركب

وبالمثل ، يجب أن تظهر TypeError .
أنا جديد في فتح المصدر. وأود أن تفعل ذلك. هل يستطيع أحد أن يرشدني؟

لا يمكن لـ Numpy أخذ أرضية الأعداد المركبة ، لذا بدلاً من إعطاء خطأ ، فإنه يسقط الجزء التخيلي ببساطة.

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

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

نعم ، أعتقد أننا يجب أن نلقي خطأ TypeError.
هل يمكنني العمل عليها؟

أنا شخصياً أفضل حتى (2 + 2j) // 2 = (1 + 1j) ، على الرغم من أنها ليست صحيحة رياضياً تمامًا.

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

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

"في مواجهة الغموض ، ارفض إغراء التخمين". يقترح أنه يجب أن يكون TypeError .

@ kaivu1999 - لمعالجة هذا الأمر ، من الأفضل إزالة الأنواع المعقدة حتى التي يتم إنشاؤها في floor_divide ufunc (لاحظ أن divmod و remainder و modf موافق بالفعل). ابحث في core/src/umath/loops.c.src ، في العناصر التالية للسطر 2321 (من المحتمل فقط إزالة الأسطر 2480-2500).

mhvk نعم ، يجب عليك أيضًا ضبط numpy/core/code_generators/generate_umath.py ، ولكن إذا أردنا الإهمال أولاً ، فسيتعين عليك إنشاء محلل نوع مخصص على الأرجح (اللمسات الإضافية numpy/core/src/umath/ufunc_type_resolution.c ).

seberg - يبدو أن السلوك الحالي يجب اعتباره خطأً فقط ، وأنه من أجل الاتساق مع remainder و divmod ، يجب أن نبدأ في إثارة خطأ.

ما إذا كنا نريد سلوكًا مختلفًا سيبدو مناقشة منفصلة.

نعم ، أنا في ذلك.
لقد قمت بتغيير الكود ، والآن يظهر:
">>> أ // 2

Traceback (أحدث مكالمة أخيرة):
ملف ""، السطر 1 ، في
TypeError: ufunc 'floor_divide' غير مدعوم لأنواع الإدخال ، ولا يمكن إجبار المدخلات بأمان على أي أنواع مدعومة وفقًا لقاعدة الصب '' آمن ''
"
هل يجب علي إنشاء طلب السحب؟

@ kaivu1999 سيكون طلب السحب بداية جيدة. يرجى التأكد من وضع Fixes #13236 في التعليق الأول ، والذي سيشير إلى المشكلة والعلاقات العامة.

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات