take_along_axis: هل يجب أن يتساوى عدد الصفوف؟

افصل محور الاختيار عن الصفوف

الأبعاد غير المختارة في take_along_axis تحتاج إلى توافق البث، لا إلى التساوي دائمًا. [1]

نختار محور الأعمدة axis=1 في مصفوفات من بعدين. نريد أن نعرف هل يستطيع صف مصدر واحد خدمة ثلاث قوائم فهارس، دون تحويله أولًا إلى ثلاثة صفوف صريحة.

عدد الفهارس داخل كل قائمة يحدد عدد الاختيارات التي نطلبها؛ هنا نطلب عمودين من مصدر يحوي أربعة أعمدة. أما عدد صفوف الفهارس فيحدد ثلاث بطاقات طلب نريد قراءتها.

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

اتبع ثلاث بطاقات من مصدر واحد

شغّلنا NumPy2.3.5 على CPython3.12.14. أنشأنا A=np.array([[261,-263,266,-268]],dtype=np.int64) بالشكل(1,4)، وI=np.array([[3,0],[1,3],[2,2]],dtype=np.int64) بالشكل(3,2).

نفذنا O=np.take_along_axis(A,I,axis=1). رجعت مصفوفة من int64 بالشكل(3,2)، وقيمها [[-268,261],[-263,-268],[266,266]]. عدد صفوف المصدر واحد، وعدد صفوف الناتج ثلاثة؛ نجح الطلب رغم اختلافهما.

بطاقة الفهارس الأولى [3,0] تقرأ العمود3 من صف المصدر ثم العمود0:−268 ثم261. البطاقة الثانية [1,3] تقرأ−263 ثم−268. البطاقة الثالثة [2,2] تقرأ266 مرتين.

نكتب العلاقة في مرجعنا: O[r,j]=A[0,I[r,j]]. عند r=2 نعود أيضًا إلى صف المصدر0؛ لا نحاول قراءة صف ثالث غير موجود في A. الرقم r يحدد بطاقة الطلب، وليس صفًا أصليًا جديدًا.

الفهرس2 المتكرر في البطاقة الأخيرة لا يولد قيمة محسوبة أو مشاهدة إضافية. لدينا إحالتان إلى العمود نفسه ضمن ترتيب اختيارات معلن؛ نسجل سبب ظهور العدد266 مرتين.

بقيت بايتات A وI كما كانت بعد الاستدعاء. هذا فحص للمدخلين في تشغيلنا؛ لم نفحص مشاركة الذاكرة أو مقدار التخصيص أو نجرب الكتابة عبر الناتج.

قارن الصفوف الصريحة وعدم التوافق

أنشأنا E من ثلاثة صفوف متطابقة، كل منها [261,-263,266,-268]، بالشكل(3,4). نفذنا take_along_axis مع E وI وaxis=1، فرجعت القيم الست السابقة نفسها والنوع والشكل نفسيهما.

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

ثم أنشأنا B بصفين: [[261,-263,266,-268],[271,-253,276,-258]]، بالشكل(2,4). أبقينا I ذات الصفوف الثلاثة، وaxis=1. رفع الطلب IndexError، ولم يرجع مصفوفة مكتملة.

في مقارنة الصفوف هذه،1 مقابل3 نجح، و3 مقابل3 نجح، و2 مقابل3 رفض. ليست قاعدة المثال أن كل اختلاف في عدد الصفوف مقبول؛ راجع أي بعد مفرد وأي طول يحتاج إلى المطابقة.

ظهرت رسالة عدم توافق أشكال مصفوفات الفهرسة في الخطأ الفعلي. نسجل نوع الخطأ كما وقع في الإصدار المختبر؛ لا نسميه ValueError اعتمادًا على تخمين سابق.

بقيت بايتات المصدرين الصريحين والفهارس ثابتة في الحالات المحفوظة. لم نثبت قاعدة عامة لكل مدخل غير صالح أو صنف مشتق أو فهرس خارج الحدود.

اقرأ السجل وحدوده

قبل استيراد NumPy، بنى مرجع Python لكل n من261 إلى277 الصف [n,-n-2,n+5,-n-7] والبطاقات الثلاث نفسها. قرأ كل فهرس مباشرة من قائمة الصف، وبنى ثلاث نسخ صريحة لتحكم القيم.

لدينا17 حالة. في كل حالة نفذنا ثلاثة طلبات: مصدر مفرد، وثلاثة صفوف متطابقة، ومصدر غير متوافق من صفين. المرحلة المصححة تضم51 محاولة:34 مصفوفة عائدة، كل منها ستة أعداد، أي204 عناصر عددية محفوظة، و17 خطأIndexError.

فحصنا القيم والشكل والنوع، وقارنا بايتات كل مصدر والفهارس قبل الطلب وبعده. أنشأنا68 مصفوفة مدخلات منفصلة؛ لا نضم نداءات إنشائها إلى51 نداء اختيار. الفهارس ثابتة المحتوى بين الحالات، وليست17 بطاقة مختلفة.

سبقت هذه المرحلة محاولة بالقيمة n=241 توقفت عند الطلب الثالث: نجح الطلبان الأولان وفحوصهما، ثم وقع IndexError غير ملتقط لأن التوقع كان ValueError. حفظنا المحاولة، وصححنا نوع الخطأ في مرحلة جديدة بقيم مختلفة.

إجمالي المرحلتين54 محاولة و36 مصفوفة عائدة و18 خطأ. تحققت12 قيمة في المرحلة الأولى بالعبارات التأكيدية قبل توقفها؛ لم نحفظ لها سجلات عودة خامًا. لذلك نميزها من204 قيم مسجلة في المرحلة المصححة، ولا ندعي أن البداية اجتازت المرحلة كاملة.

اقتصرنا على int64 والأشكال(1,4) و(3,4) و(2,4)، وفهارس(3,2) ضمن0 إلى3، ومحور1. لم نفحص محاور أخرى أو فهارس سالبة أو خارجة أو الفراغ أو أنواعًا أخرى أو ذاكرة أو أداء أو إصدارات أخرى.

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