النوافذ المتداخلة: هل كتابة خلية تغيّر خلية واحدة؟

أنشئ النوافذ من الأصل

توثق sliding_window_view عرضًا بنافذة تتحرك على المصفوفة. والكتابة فيه معطلة افتراضيًا؛ قد يظهر موضع التخزين نفسه عدة مرات في العرض. [1] هذه العلاقة هي موضوع مثالنا، لا حساب متوسط متحرك.

نستعمل NumPy 2.3.5 وننشئ x=np.array([3,11,-4,8,2],dtype=np.int64). القيم مؤلفة بلا وحدة قياس. الأصل متصل أحادي البعد، بشكله (5,) وحجم عنصر مقداره ثمانية بايتات.

نستدعي v=sliding_window_view(x,3) دون تحديد axis. نقرأ ثلاث نوافذ: تبدأ الأولى عند فهرس الأصل 0، والثانية عند 1، والثالثة عند 2. كل نافذة تحتوي ثلاثة عناصر.

قيم العرض [[3,11,−4],[11,−4,8],[−4,8,2]] وشكله (3,3). لدينا تسع خلايا منطقية في العرض، لكننا لا نعلن تسع قيم مخزنة مستقلة أو نحسب ذاكرة جهاز.

جرّب العرض الافتراضي

قرأنا v.flags.writeable=False وv.flags.owndata=False. أعطى np.shares_memory(x,v) النتيجة True؛ بقيت بايتات الأصل ثابتة خلال إنشاء العرض وفحصه.

حاولنا v[0,2]=99. رفعت ValueError، وبعد المحاولة بقي الأصل [3,11,−4,8,2]، وبقيت نوافذ العرض بالقيم السابقة. لم نغير العلم يدويًا لتجاوز هذه النتيجة.

خطوة العرض v.strides=(8,8). توثق strides خطوات بالبايت على الأبعاد. [2] في أصلنا المحدد، الانتقال صفًا واحدًا أو عمودًا واحدًا يقدم القراءة عنصرًا أصليًا واحدًا.

نكتب خريطة مثالنا: v[r,c] تقرأ x[r+c]. لذلك (0,2) و(1,1) و(2,0) كلها تقرأ x[2]؛ تجمع الأزواج الثلاثة إلى فهرس الأصل نفسه، لا إلى ثلاثة عناصر مختلفة.

في التنفيذ المقروء للإصدار 2.3.5، تجمع sliding_window_view خطوة الأصل مع خطوة محور النافذة وتستدعي as_strided مع writeable المطلوب؛ يعطل المساعد علم الكتابة عندما يكون الطلب False. [3]

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

اسمح بكتابة واحدة

أنشأنا أصلًا مستقلًا جديدًا بالقيم الخمس نفسها، ثم v=sliding_window_view(x,3,writeable=True). تحققنا من علم الكتابة True ومن الشكل والخطوات والنوع والمشاركة، قبل التعديل.

نفذنا إسنادًا مفردًا واحدًا: v[0,2]=99. صار x=[3,11,99,8,2]. تغير العنصر الأصلي ذو الفهرس 2 وحده؛ لم نصنع ثلاثة تعديلات مستقلة في الأصل.

بعد الكتابة قرأنا v=[[3,11,99],[11,99,8],[99,8,2]]. ظهرت القيمة الجديدة في (0,2) و(1,1) و(2,0)، لأن خريطة القراءة ترد كل هذه الإحداثيات إلى x[2].

المقارنة تمت بين حالات ما قبل الكتابة وما بعدها في المسار نفسه. لم نستعمل الأصل الذي رفض الكتابة في المسار الافتراضي، ولم نقارن عرضًا جديدًا بأصل سبق تعديله خفية.

تكرر العدد −4 قبل التعديل ليس دليلنا الوحيد على المشاركة. الخريطة والمشاركة المسجلة وأثر الإسناد على الأصل وثلاث خلايا هي الأدلة في هذا المثال؛ قد تتساوى قيم مستقلة أيضًا.

حدد نطاق الفحص

أضفنا الأصل الصفري وخمس قيم كلها 5، ثم التركيبات الاثنتين والثلاثين من {−2,3} في خمس خانات. مع المثال صار لدينا 35 مدخلًا مختلفًا.

لكل مدخل أنشأنا أصلين int64 جديدين. أحد العرضين افتراضي والآخر مع writeable=True، وكلاهما بنافذة 3 وشكل (3,3) وخطوتين مقدار كل منهما ثمانية بايتات.

نفذنا 35×2=70 استدعاء sliding_window_view، و70 فحص مشاركة مساعدًا. حصلنا على 35 حالة ValueError من محاولات الكتابة الافتراضية و35 كتابة ناجحة في المسار المسموح.

قيمة الكتابة في الحالة ذات الرقم k هي 99+k. حفظنا 1260 قيمة نافذة و700 قيمة أصل قبل المحاولات وبعدها؛ لا نعد فحوص المشاركة والإسنادات استدعاءات نافذة إضافية.

مرجع Python يبني النوافذ من ثلاث شرائح قائمة بطول ثلاثة. في المسار الافتراضي تبقى القائمة المؤلفة ثابتة؛ في الآخر نستبدل فهرسها 2 وحده ثم نعيد حساب النوافذ. لم نستعمل مخرجات NumPy مرجعًا لها.

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