intersect1d: هل يزيل assume_unique التكرار؟

الافتراض ليس تنظيفًا

assume_unique=True يفترض تفرد المدخلين؛ التكرارات قد تؤدي إلى نتائج خاطئة. [1]

نريد القيم الموجودة في مدخلين، ونختار حالة فيها تكرار واضح في المدخل الأول ولا توجد أي قيمة مشتركة. سنفعل الخيار عمدًا رغم مخالفة الشرط لكي نقرأ أثره في تشغيل محدد.

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

جميع الأعداد مؤلفة بلا وحدة، والمدخلات مصفوفات int64 أحادية البعد. لا نطلب فهارس أول ظهور أو جميع أزواج المطابقة، ولا نربط أرقامًا بسجلات أشخاص.

قيمة عائدة ليست في الجانب الثاني

شغّلنا NumPy2.3.5 على CPython3.12.14. أنشأنا A=np.array([301,301,304],dtype=np.int64) بالشكل(3,)، وB=np.array([308],dtype=np.int64) بالشكل(1,).

القيم المختلفة في A هي301 و304، والقيمة الوحيدة في B هي308. لا توجد مساواة بين أي قيمة في الأول وقيمة في الثاني؛ تقاطعهما العددي الصحيح خالٍ.

نفذنا np.intersect1d(A,B) بالافتراضي، فرجعت مصفوفة int64 بالشكل(0,) وقيمتها[]. نميز المصفوفة الفارغة من نتيجة[0] التي تحتوي عددًا واحدًا يساوي صفرًا.

ثم نفذنا np.intersect1d(A,B,assume_unique=True). رجعت[301] من int64 بالشكل(1,). العدد301 ظهر في A مرتين، لكنه لم يظهر في B؛ لا يحقق شرط القيمة المشتركة.

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

لا نعد[301] سلوكًا مضمونًا لكل تكرار أو إصدار، ولا نبني عليها طريقة لعد تكرارات A. نسجلها حالة فشل لافتراض غير صحيح على المدخلين المعلنين.

بقيت بايتات A وB كما كانت بعد الطلبين. لم يحذف True إحدى قيم301 من A، ولم يجعل308 مساوية لها؛ المدخلان نفسهما بين المقارنتين.

اختبر مدخلين يحققان الفرض

أنشأنا تحكمين مستقلين C=[301,304] وD=[304,308] من int64، وشكل كل منهما(2,). كل قائمة فيهما متفردة داخليًا، مع قيمة مشتركة واحدة هي304.

أعطت np.intersect1d(C,D) النتيجة[304]، وأعطت np.intersect1d(C,D,assume_unique=True) النتيجة[304] أيضًا. وافق النوع int64 والشكل(1,) في الطلبين.

نراجع الفرض داخل كل مدخل على حدة. وجود304 في C وفي D لا يخالف التفرد الداخلي؛ التقاطع أصلًا يبحث عن قيم تتكرر بين الجانبين، وليس عن تكرار داخل أحدهما.

التحكم لا يثبت أن كل نتيجة مع True صحيحة. إنه يبين اتفاق الطلبين في مدخلين يحققان الفرض، بينما طلب A وB خالفه بسبب ظهور301 مرتين داخل A.

ولا نخلط التحكم بحذف تكرار من A مع إبقاء B نفسها. غيرنا المدخلين إلى حالة ذات مشترك304؛ لذلك نكتب C وD وأعدادهما كاملة قبل عرض النتيجة.

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

افصل التوقع الصحيح من الفشل المسجل

قبل استيراد NumPy، بنى مرجع Python لكل n من301 إلى317 القوائم A=[n,n,n+3] وB=[n+7]، ثم C=[n,n+3] وD=[n+3,n+7]. حسب تقاطع مجموعتين للتوقع الصحيح:[] للأولى، و[n+3] للتحكم.

التوقع[n] للطلب المخالف يصف الفشل الذي نراجعه في هذه الأسرة وإصدار التشغيل. لا نسميه تعريفًا جديدًا للتقاطع أو نتيجة صحيحة للعقد؛ المقارنة الرياضية الصحيحة ما زالت خالية.

في17 حالة نفذنا أربعة نداءات لكل حالة: الافتراضي على A وB، ثم True عليهما رغم التكرار، والافتراضي على C وD، ثم True على التحكمين المتفردين. المجموع68 نداءً أعادت68 مصفوفة.

من المخارج17 مصفوفة فارغة بالافتراضي للمدخلين غير المشتركين، و51 مصفوفة ذات عدد واحد:17 نتيجة مخالفة[n]، و34 نتيجة تحكم[n+3]. عدد العناصر العددية51، لا68.

لم تسجل أخطاء تنفيذ. منها17 طلبًا خالف شرط True عمدًا و17 طلب True على مدخلات متفردة، إضافة إلى34 طلبًا افتراضيًا. نجاح حفظ السجلات لا يعني قبول كل نتيجة كتقاطع صحيح.

بنى المرجع بايتات المدخلات بطريقة struct قبل الاستيراد، وقارناها بمصفوفات التشغيل. بعد التنفيذ، قارنت مراجعة Python مستقلة كل قيمة من مدخل بقيم الآخر في السجلات؛ لم تعد تشغيل intersect1d.

اقتصرنا على int64 والأطوال3 و1 للحالة المخالفة، و2 و2 للتحكم، وأسرة الأعداد المذكورة وإصدار2.3.5. لم نفحص فهارس العائد أو أبعادًا إضافية أو NaN أو أنواعًا أخرى أو مدخلات فارغة أو أداء وذاكرة أو إصدارًا آخر.

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