Numpy: BUG: تعمل وظائف np.vectorize () مرتين على العنصر الأول (كما يظهر عندما تعدل الوظيفة كائنًا قابل للتغيير)

لقد قمت للتو بتحرير المنشور الخاص بي باختبار جديد يبدو أنه يؤكد أن التحقق من نوع العنصر الأول هو سبب المشكلة

أبسط حالة الاختبار:

a = np.array([1, 2, 3])
def f(x):
    print('got', x)
    return x
fv = np.vectorize(f)
y = fv(a)

يعطي:

got 1
got 1
got 2
got 3

"إذا لم يتم تحديد أنواع otypes ، فسيتم استخدام استدعاء للدالة مع الوسيطة الأولى لتحديد عدد المخرجات. سيتم تخزين نتائج هذه الاستدعاء مؤقتًا إذا كانت ذاكرة التخزين المؤقت True لمنع استدعاء الوظيفة مرتين. ومع ذلك ، للتنفيذ ذاكرة التخزين المؤقت ، يجب تغليف الوظيفة الأصلية مما يؤدي إلى إبطاء المكالمات اللاحقة ، لذلك لا تفعل ذلك إلا إذا كانت وظيفتك باهظة الثمن. "
https://docs.scipy.org/doc/numpy/reference/generated/numpy.vectorize.html

لذلك فهو سلوك موثق جيدًا ، لكنه يبدو غير بديهي. لذلك ربما يكون هذا تحسينًا أكثر من كونه إصلاحًا للأخطاء.

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

على سبيل المثال ، في numpy/lib/function_base.py في وظيفة فئة vectorize _get_ufunc_and_otypes() ، أعتقد بسذاجة أنه يمكنك تعديل هذه الأسطر:

inputs = [arg.flat[0] for arg in args]
outputs = func(*inputs)

إلى:

#earlier
import copy

...

inputs = copy.deepcopy([arg.flat[0] for arg in args])
outputs = func(*inputs)

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

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

أعتقد أنه بالنسبة للعمليات المتجهية على مصفوفات كائنات كبيرة جدًا ، فقد يكون الأمر أكثر كثافة من الناحية الحسابية لإنشاء نسخة عميقة من العنصر الأول أكثر من تكلفة تطبيق الوظيفة. لذلك قد يكون من الجيد أن يكون لديك هذه الوظيفة إذا لم يحدد المستخدم otype ، ولكن بعد ذلك قل في الوثائق أن الأداء قد يأخذ نجاحًا ما لم يتم تحديد otype لمصفوفات كبيرة شاء. @ eric-wieser ما رأيك؟

copy.deepcopy() غير آمن على العديد من المدخلات ، لذلك للأسف هذا ليس خيارًا قابلاً للتطبيق.

الطريقة الوحيدة لإصلاح ذلك هي إعادة كتابة جوهر vectorize ، والذي يستخدم حاليًا numpy.frompyfunc لإنشاء ufunc فعليًا. يجب إنشاء حلقة داخلية بديلة ، على غرار ما نستخدمه لـ np.apply_along_axis . لسوء الحظ ، لتجنب تدهور الأداء ، أعتقد أننا سنحتاج إلى تنفيذ الحلقة في لغة C (مثل frompyfunc في ufunc it builds).