ascontiguousarray: هل تحفظ عدد المحاور؟

اقرأ شرط عدد المحاور

ascontiguousarray تعيد مصفوفة بترتيب C وبمحور واحد على الأقل؛ لا تحفظ رتبة المدخل بلا محاور. [1]

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

الأعداد مؤلفة بلا وحدة. نسجل القيم قبل الكتابة وبعدها؛ ليست هذه تجربة لحساب استهلاك ذاكرة جهاز أو استقبال نموذج.

مدخل C ومع ذلك زاد محور

أنشأنا a=np.array(7,dtype=np.int64) في NumPy 2.3.5 على CPython 3.12.14. قرأنا a.shape=() وa.ndim=0 وa.size=1، وعلم a.flags.c_contiguous هو True. يوجد عنصر واحد، وليس مدخلًا فارغًا.

ثم نفذنا y=np.ascontiguousarray(a). قرأنا y.tolist()=[7] وy.shape=(1,) وy.ndim=1 وy.size=1؛ النوع int64 وعلم C هو True. بقيت a بقيمة 7 وشكل () وعدد محاور 0.

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

اختبار y is a أعطى False. هذا يثبت اختلاف الكائنين في المثال، ولا يثبت وحده أن القيمة موجودة في مخزنين مستقلين. قرأنا مشاركة البيانات قبل تجربة الكتابة.

حتى هذه اللحظة بقيت بايتات a كما كانت. نميز الحفاظ على بيانات المصدر أثناء التحويل من الحفاظ على شكل الناتج، الذي أصبح (1,) بالفعل.

كائن مختلف وكتابة تظهر في الأصل

shares_memory تفحص مشاركة الذاكرة؛ الاختبار الافتراضي يحسم وجود عنصر مشترك. [2]

شغّلنا np.shares_memory(a,y) دون max_work، فأعادت True على مدخلَي العنصر الواحد. لم نستنتج هذه النتيجة من قيمة 7 المتساوية أو من علم C أو من False في اختبار الهوية.

قبل أي كتابة أنشأنا c=np.array(a,copy=True). سجلنا قيمة 7 ونوع int64 وشكل () وعدد محاور 0. np.shares_memory(a,c) أعادت False، وحفظنا بايتات c قبل الخطوة التالية.

نفذنا y[0]=-4. بعدها قرأنا a.tolist()=-4 وy.tolist()=[-4]، وبقيت c.tolist()=7. ظل شكل a وc هو () وشكل y هو (1,)، وبقي النوع int64 في الثلاثة؛ بايتات c ثابتة.

إذن اختلاف شكل y وهوية كائنها لم يمنعا ظهور الكتابة عبرها في a في هذا التشغيل. أما النسخة الصريحة التي أنشأناها قبل الكتابة فحفظت القيمة القديمة. لا نستعيد 7 من y بعد تغييرها ونقول إننا نسخنا البداية.

الكتابة جزء معلن من التجربة. لا نصف a بأنها بقيت ثابتة في جميع الخطوات؛ ثباتها كان قبل الكتابة، ثم تغيرت قيمتها بعدها دون أن تتغير رتبتها.

تحكم وفحص محدود

أنشأنا للتحكم a1=np.array([7],dtype=np.int64)، ثم y1=np.ascontiguousarray(a1). قرأنا y1 is a1=True وshares_memory(a1,y1)=True؛ الشكل (1,) والنوع int64 وعلم C هو True.

نسخنا a1 صراحة قبل الكتابة، ثم كتبنا y1[0]=-4. قرأنا [−4] في a1 وy1 و[7] في النسخة المستقلة. هذا التحكم يبدأ بمحور موجود؛ لا نبدل تعريف المدخل بلا محاور كي نعلن أن العملية حافظت رتبته.

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

المرجع لا يستدعي تحويل مصفوفة أو فحص مشاركة NumPy. الهوية وعلم C والمشاركة وشكل الكائنات هي ملاحظات تنفيذ نفحصها مباشرة، وليست شيئًا يثبته نموذج الخلية وحده.

عددنا قيم البداية من −8 إلى 8 وقيم الكتابة من −8 إلى 8: لدينا 17×17=289 زوجًا. تشمل الشبكة الكتابة بالقيمة القديمة نفسها؛ لذلك نفحص الهوية والمشاركة مستقلين عن ملاحظة تغير العدد.

لكل زوج خمسة فحوص: القيم والنوع والأشكال والأعداد قبل الكتابة؛ وعلم C؛ والهوية مع المشاركة؛ والنسخة الصريحة وقيمتها وشكلها وعدم تداخلها؛ والكتابة إلى الخلية المشتركة مع ثبات بايتات النسخة. أضفنا خمسة للمثال بلا محاور وخمسة للتحكم الأحادي: 289×5+10=1455، ومرت كلها.

نقصر النتيجة على مصفوفات int64 عادية قابلة للكتابة ولها عنصر واحد. استبعدنا الأنواع والأطوال والتخطيطات والخطوات الأخرى، ومدخل Python المفرد والفئات المشتقة وlike وتغيير dtype والقراءة فقط والمصفوفات الفارغة؛ لم نفحص الأداء أو حمولة الذاكرة.

احفظ الشكل الذي طلبه المسار التالي، وأثبت المشاركة قبل الكتابة إن كانت تهم المهمة. ترتيب C لا يجيب وحده عن عدد المحاور أو استقلال القيمة.