real: هل الجزء الحقيقي نسخة مستقلة؟

حدد علاقة البيانات قبل التعديل

تعيد np.real الجزء الحقيقي، ويكون نوع الناتج عائمًا عندما يحتوي المدخل عناصر مركبة. [1] نميز قراءة القيم عن السؤال الذي يهمنا هنا: هل تصل الكتابة إلى المصدر؟

يشارك العرض مخزن البيانات؛ أما النسخة فتكرر البيانات في مخزن آخر، ولا تنعكس تغييراتها على الأصل. [2] نستخدم هذا الفرق لتفسير تجربة صغيرة، لا لحساب ذاكرة جهاز.

تفحص shares_memory اشتراك مصفوفتين، ويحسم طلبها الافتراضي الاشتراك الفعلي. [3] سجلنا النتيجة إلى جانب أثر الكتابة؛ لم نكتف بتساوي الأرقام عند البداية.

تتيح np.copy إنشاء نسخة مصفوفة. [4] نطبقها هنا على float64، ولا ننقل النتيجة إلى استقلال الكائنات داخل مصفوفة object.

استخرج القيم وأنشئ نسخة قبل الكتابة

أنشأنا z=np.array([-4+7j,6-9j,2+5j],dtype=np.complex128)، في NumPy 2.3.5 على CPython 3.12.14. الأعداد مؤلفة بلا وحدة قياس، والأصل مصفوفة عادية متصلة قابلة للكتابة بالشكل (3,).

نفذنا r=np.real(z)، ثم c=np.copy(r) قبل أي تعديل. كان r وc من float64 بالشكل (3,)، وقيم كل منهما [-4,6,2]. بقيت بايتات z ثابتة خلال إنشاء الناتجين وفحص المشاركة.

أعطى np.shares_memory(z,r) القيمة True، ومع c أعطى False. خطوتا z وr كانتا 16 بايتًا، وخطوة c كانت 8. هذه بيانات التشغيل المحدد، وليست قاعدة لكل مدخل تقبله real.

اختلاف نوع r عن complex128 لم يفصل بياناته هنا. ووجود الأرقام نفسها في c لم يجعلها عرضًا مشتركًا؛ نحتاج العلاقة المسجلة ومتابعة التعديل، لا لقطة القيم وحدها.

تابع الكتابة في العرض والنسخة والأصل

كتبنا r[1]=31. صار العنصر ذو الفهرس 1 في z يساوي 31−9j؛ استبدلت الكتابة جزأه الحقيقي 6، وبقي الجزء التخيلي −9. صار r يساوي [-4,31,2]، بينما بقيت c بقيم البداية حينئذ.

كتبنا بعد ذلك c[0]=-20. صارت c تساوي [-20,6,2]، وبقي z يساوي [-4+7j,31-9j,2+5j]، وr يساوي [-4,31,2]. لم تستخدم هذه الكتابة مخزن الأصل في المثال.

ثم أسندنا z[2]=-11+13j. صار الأصل [-4+7j,31-9j,-11+13j]، وقرأنا r القديم نفسه بالقيم [-4,31,-11]. لم نستدع real من جديد لنصنع هذه اللقطة.

بقيت c تساوي [-20,6,2]. لذلك نفصل ثلاث نتائج: كتابة العرض تغير الحقيقي في الأصل، وكتابة النسخة لا تنتقل إليه، وكتابة الأصل تظهر في العرض الذي احتفظنا به. لا نصف المصدر بأنه ثابت بعد التعديلات المعلنة.

مرجع مستقل وحدود التجربة

لكل عدد صحيح q من 0 إلى 16 أنشأنا أصلًا جديدًا بأزواج الجزأين: (-4+q,7+q)، (6+q,-9-q)، (2+q,5+q). عند q=0 نحصل على المثال؛ المدخلات السبعة عشر مختلفة ببايتاتها.

في كل حالة كانت كتابة r[1] بالقيمة 31+q، وكتابة c[0] بالقيمة -20-q، وكتابة z[2] بالزوج (-11-q,13+q). احتفظنا بالأصل والعرض والنسخة أنفسهم خلال اللقطات الثلاث للحالة.

لكل مدخل استدعاء real، واستدعاء copy، وفحصا shares_memory: المجموع 17+17+34=68. الإسنادات المفردة الثلاثة لكل حالة خارج هذا العد. حفظنا 612 قيمة عددية و34 نتيجة مشاركة منطقية، فيكون الإجمالي 646.

بنى مرجع Python أزواجًا وقوائم مستقلة من أعدادنا، ثم استبدل الإحداثي الحقيقي أو عنصر النسخة أو زوج الأصل كما أعلنّا. قارن بايتات الأصل بتعبئة struct لكل زوج؛ لم يستعمل مخرجات NumPy لتوليد التوقعات.

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