Numpy: BUG: تعمل ترقية timedelta و float في بعض الأحيان

يبدو أن np.multiply يدعم هذا على الأقل.

import numpy as np
print(np.multiply(np.timedelta64(1), 1.2))

أعتقد أن ما ورد أعلاه يجب اعتباره أيضًا خطأ.

أعتقد أن السؤال هو دائمًا ما يكون صحيحًا أنه بالنسبة إلى ufuncs "يتم تنفيذ قواعد الإرسال من خلال السؤال عن متى يمكن إرسال نوع البيانات" بأمان "إلى نوع بيانات آخر" كما هو موضح في الوثائق. يبدو أن هناك استثناءات مثل أعلاه حيث لا يكون الإرسال آمنًا ولكننا جعلنا ufunc للعمل. أعتقد أنه في هذه الحالة ، يجب أن تظل أنواع الترويج تشير إلى نوع ترويج غير صالح (لكل من np.promote_types ("float32" ، "m8") و np.promote_types ("m8" ، "float32")). ما إذا كنا بحاجة إلى الاستمرار في السماح لـ ufunc بالعمل يمكن تحديده على أساس كل حالة على حدة؟

نعم ، علينا أن نميز بوضوح أن np.promote_types يجب أن يكون قاعدة عامة تكون دائمًا معقولة. وهذا هو سبب إعجابي بمصطلح "النوع المشترك". هذا هو على سبيل المثال نوع dtype الذي يمكن استخدامه مع np.concatenate .

يمكن لكل ufunc على حدة أن يقرر تنفيذ عملية معينة باستخدام "نوع dtype المشترك" أو أي منطق آخر. نحن نقوم بذلك على وجه التحديد لـ multedelta64 و timedelta64 ، لذلك فهذه مشكلة منفصلة بالفعل.

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

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