mintypecode: هل typeset تضمن سلامة كل المدخلات؟

رمز مختار وسؤال مستقل

تعيد mintypecode رمزًا نصيًا؛ وعند غياب تطابق المدخلات مع typeset تعيد default. [1]

في التنفيذ المقروء تُصفى رموز المدخل أولًا إلى ما يوجد في typeset. [2] نراجع أثر تغيير هذه المجموعة في أمثلتنا.

تختبر can_cast السماح وفق casting؛ وsafe قاعدة حفظ القيم. [3] نستعملها على وصفي نوعين دون تحويل بينهما.

تجربتنا على NumPy 2.3.5 وCPython 3.12.14 في هذا الحاسوب. أثبت سجل أوصاف النوع أن h يمثل int16 وi يمثل int32 وf يمثل float32 وd يمثل float64، مع حجم عنصر 2 و4 و4 و8 بايتات على الترتيب.

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

قائمة أصلية ورمز مستبعد

أعطينا np.mintypecode(["h","i"],typeset="h",default="d"). رجع "h" من builtins.str. بقيت القائمة الأصلية ["h","i"]؛ لم تحذف الدالة عنصرًا منها في الفحص المسجل.

ثم سألنا بصورة مستقلة np.can_cast(np.dtype("h"),np.dtype("h"),casting="safe")، فأعطى True. وسألنا من np.dtype("i") إلى np.dtype("h") مع القاعدة نفسها، فأعطى False. النتيجتان من builtins.bool.

إذن اختيار رمز واحد لم يثبت السماح لكل نوع كان موجودًا في القائمة الأصلية. النوع i بقي جزءًا من السؤال الذي كتبناه، حتى حين لم يبق رمزه داخل مجموعة الاختيار typeset="h".

في مثالنا يمثل i النوع الصحيح ذا 32 بتًا، وh الصحيح ذا 16 بتًا. لا نستبدل False بحكم على رقم صغير بعينه؛ لم ننشئ أي قيمة عددية لكي نعرف هل تدخل في المجال الأصغر.

ولم نحصل على قيمة محولة أوخطأ تحويل. سجلنا جواب سياسة السماح فقط. يجب ألّا نسمي الرمز النصي "h" مصفوفة جديدة أوبيانات أعيد تخزينها.

توسيع المجموعة وتغيير البديل

مع np.mintypecode(["h","i"],typeset="hi",default="d") رجع "i". وعند فحص h إلى i وi إلى i مع safe، ظهرت True وTrue. هذا تحكم يسمح للنوعين الأصليين في النطاق المختار.

لم يحدث الفرق لأننا غيرنا القائمة؛ بقي الرمزان h وi. تغيرت المجموعة المسموح بها من "h" إلى "hi"، فتغير الرمز الذي رجع والفحوص المتعلقة به. نسجل المجموعة مع كل نتيجة.

وبتثبيت typeset="GDFgdf" وdefault="d" رجع "d" للقائمة نفسها. لا يوجد h أوi ضمن أحرف هذه المجموعة المعلنة، فحصلنا على البديل المحدد. فحصا السماح إلى d أعطيا True في التشغيل.

عندما أبقينا GDFgdf وكتبنا default="f" رجع "f". وأعطى can_cast من h إلى f القيمة True، ومن i إلى f القيمة False. بقاء قائمة المدخلات نفسها لم يمنع تغير حكم السماح مع البديل الجديد.

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

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

حصر النداءات وحدود المرجع

أعلنّا ثلاث علامات أصلية h وi وf، وأخذنا المجموعات الجزئية الثماني منها:[] و[h] و[i] و[h,i] و[f] و[h,f] و[i,f] و[h,i,f]. كل قائمة مختلفة عن الأخرى؛ ليست ثماني قيم عددية.

لكل قائمة ست مجموعات typeset: GDFgdf وhi وh وi والنص الفارغ وfhi. ولكل مجموعة بديلان d وf؛ صار لكل قائمة 12 إعدادًا، و8×12=96 نداء mintypecode، جميع مخارجها str.

بعد كل نتيجة سألنا can_cast لكل رمز أصلي إلى الرمز المعاد. تحمل القوائم الثماني في مجموعها 12 ظهورًا للرموز، ومع الإعدادات الاثني عشر صارت 144 سؤالًا و144 إجابة bool مفردة.

المجموع 96+144=240 نداءً و240 سجل عودة، موزعة إلى 96 نصًا و144 قيمة منطقية. إنشاء وصف النوع وقراءة اسمه وفئته وحجم عنصره بيانات مساعدة؛ لا نعدها مخارج أصلية إضافية.

قبل النداءات أعلن المرجع الرموز المطابقة وأولوية f ثم i ثم h في نطاقنا، وإلا البديل المعطى. وأعلن جدولًا مستقلًا لاثني عشر زوجًا بين الأنواع المحددة للتحقق من سياسة السماح. لم يستدعِ mintypecode أوcan_cast أوالملف البعيد لصنع التوقعات.

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

لم نفحص رموزًا أخرى أوفرع الجمع بين F وd أوأنواعًا مركبة أوlongdouble أوأخطاء أوسياسات تحويل أخرى أوترتيب بايتات أوأداءً أوإصدارات أخرى. ولم ننشئ مصفوفات أوأعدادًا أوننفذ astype أوتحويلًا فعليًا. احفظ كل رمز أصلي قبل التصفية، وافحص سياسة السماح بالسؤال المناسب.