require: هل ترتيب C يعني أن المصفوفة تملك بياناتها؟

اقرأ الشرط الذي تريد ضمانه

تتيح require طلب C للتجاور بترتيب C، وO لملكية بيانات المصفوفة؛ تنسخ عند الحاجة لتحقيق الشروط المطلوبة. [1] لا نقرأ هذين الحرفين على أنهما الشرط نفسه.

يوضح علم C_CONTIGUOUS أن البيانات تقع في مقطع متجاور بترتيب C. [2] هذا وصف للتخطيط؛ في المثال التالي نسجل ملكية البيانات ومشاركة الذاكرة بصورة مستقلة.

نستعمل NumPy 2.3.5 ونوع int64. نؤلف root=[99,1,7,2,8,77]، ثم view=root[1:5]. الشريحة تختار أربعة عناصر من الفهارس 1 إلى 4، وقيمها [1,7,2,8].

قرأنا view.shape=(4,) وview.flags.c_contiguous=True وview.flags.owndata=False. وجود ترتيب متجاور لم يجعل الشريحة أصلًا مالكًا في التشغيل، ولم نحتج خطوة متباعدة لصناعة هذا المثال.

الأرقام مؤلفة بلا وحدة قياس. نضع 99 و77 حول القيم المختارة لتمييز موضع الشريحة في الأصل؛ لا ننشر عنوان ذاكرة خامًا ولا نحسب حمولة جهاز أو نموذج.

راقب الكتابة بعد طلب C

استدعينا y=np.require(view,requirements=["C"]). بقيت بايتات root ثابتة أثناء الاستدعاء، وكانت قيم y قبل الكتابة [1,7,2,8] ونوعها int64 وشكلها (4,).

أعطى y is view النتيجة True. كان علم C في y صحيحًا، وعلم OWNDATA خطأ. وفحص np.shares_memory(y,root) أعطى True في هذا الزوج المحدد.

كتبنا y[1]=100. أصبح y يساوي [1,100,2,8]، وأصبح root يساوي [99,1,100,2,8,77]. موضع الشريحة 1 يقابل موضع الأصل 2، لا موضعه 1.

إذن تحقيق C في هذا المسار لم يعزل الكتابة عن الأصل. نحفظ الفرق بين مرحلتين: الأصل ثابت خلال إنشاء الناتج، لكنه تغير بعد الكتابة المعلنة عبر الناتج.

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

قارن مع O بأصل جديد

أنشأنا root ثانية بالقيم الست نفسها وشريحة جديدة 1:5. هذا مسار مستقل؛ لم نستعمل الأصل الذي سبق أن تغير إلى 100 كي نفحص حفظ القيم القديمة.

استدعينا z=np.require(view,requirements=["O"]). قرأنا z is view=False، وz.flags.owndata=True، وz.flags.c_contiguous=True. فحص المشاركة مع root أعطى False.

قبل الكتابة كانت z=[1,7,2,8]، وبايتات الأصل ثابتة. بعد z[1]=100 أصبحت z=[1,100,2,8]، بينما بقي root=[99,1,7,2,8,77].

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

في تنفيذ require المقروء للإصدار 2.3.5، تضبط C ترتيب الإنشاء، ثم يفحص المسار الأعلام الباقية ويعيد نسخة إذا غاب علم مطلوب. [3] يدعم ذلك تفسير اختبار O هنا، دون ادعاء أن كل فرع أو نوع اختُبر.

اختبر المالك الموجود أصلًا وحدد النطاق

أنشأنا own=np.array([1,7,2,8],dtype=np.int64)، وهي مالكة لبياناتها. استدعينا require عليها مع O، فأعادت الكائن نفسه، مع بقاء بايتاته ثابتة أثناء الاستدعاء.

الكتابة إلى الناتج عند الموضع 1 غيرت own إلى [1,100,2,8]؛ الناتج والأصل في هذا التحكم كائن واحد. لا يعني طلب O الحصول على كائن مستقل جديد عن كل مدخل مالك.

أضفنا القيم الصفرية والصف الثابت [5,5,5,5] والتركيبات الستة عشر من {−2,3} في أربع خانات. مع المثال صار لدينا 19 مجموعة مختلفة. لكل منها مسارا الشريحة C وO وتحكم مالك O.

نفذنا 57 استدعاء require، و38 فحص مشاركة مساعدًا. سجلنا 456 قيمة عددية في مخرجات ما قبل الكتابة وما بعدها؛ أنشأنا 57 مصفوفة مدخل و38 عرض شريحة، ونفذنا 57 كتابة خارج عد استدعاءات require.

توقع مرجع قوائم Python تغير موضع الأصل 2 في مسار C وحده، وثبات الأصل في مسار O، وحفظ هوية التحكم المالك. لم نستعمل ناتج مسار أصلي مرجعًا لمسار آخر.

نقصر النتيجة على الشرائح المتجاورة الأحادية ذات أربع قيم int64 والشروط المنفصلة المذكورة. لم نفحص خطوات متباعدة أو F أو المحاذاة أو القراءة فقط أو الفئات المشتقة أو نوع object أو تحويل dtype أو like أو استدعاء كود مترجم أو التزامن أو الأداء.