issubdtype: هل النوع الأضيق فرع من الأوسع؟

اسمان لسؤالين

تعيد issubdtype إجابة منطقية عن تسلسل الأنواع. [1] وهي لا تنفذ تحويلًا في تجربتنا.

تعيد can_cast إجابة السماح حسب قاعدة casting؛ وتصف الوثائق safe بأنها تسمح بما يحفظ القيم. [2] اخترنا هذه القاعدة صراحة.

توثق NumPy الفئات المجردة integer وsignedinteger وunsignedinteger للأعداد الصحيحة وفَرعيها. [3] نقارن أسماء أنواع ثابتة العرض بهذه الفئات.

نثبت الإصدار والمدخل: مررنا فئات مثل np.int16 وnp.int32، ولم ننشئ أعدادًا من هذين النوعين. لذلك لا نصف النتائج بأنها فحص لعدد صغير داخل عينة أو تجربة لتغيير بياناتها.

اتجاهان بين int16 وint32

شغّلنا np.issubdtype(np.int16,np.int32) فحصلنا على False. ثم بدلنا ترتيب الوسيطين: np.issubdtype(np.int32,np.int16) أعطى False أيضًا. بقي اسم كل نوع مع الإجابة؛ الاتجاه لا يُحذف من سجل السؤال.

وفي نداءين منفصلين استعملنا np.can_cast(np.int16,np.int32,casting="safe") وعكسه. أعطى الأول True والثاني False، وكلاهما من builtins.bool كما في نتيجتي issubdtype.

النوع int32 أوسع في المثال المعلن، لكن ذلك لم يغير False إلى True في سؤال الفرع. ولو استعملنا نتيجة issubdtype الأولى لتقرير السماح بهذا التحويل، لرفضنا اتجاهًا سمح به can_cast في التشغيل.

أعلن مرجعنا مجال int16 من −32768 إلى 32767، ومجال int32 من −2147483648 إلى 2147483647. المجال الثاني يحتوي الأول كاملًا؛ أما الأول فلا يحتوي الثاني. هذه مقارنة مجالين مؤلفين من قوى اثنين، وليست استدعاء iinfo.

لم نستخدم True لإنشاء مصفوفة جديدة أو لادعاء أن تحويلًا حدث. احتفظنا بسؤال السياسة وحده؛ لم نسجل أرقامًا قبل تحويل فعلي وبعده.

الفئة المشتركة والتحكم بالإشارة

أعطى np.issubdtype(np.int16,np.integer) القيمة True، وكذلك int32 مع integer. وبفحص signedinteger أعطى الاثنان True أيضًا، بينما ظهر False لكليهما مع unsignedinteger.

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

سألنا أيضًا int16 مع نفسه. أعادت issubdtype True، وأعاد can_cast مع safe القيمة True. هذا تحكم بالزوج المتطابق داخل الشبكة، ولا يثبت أن كل زوج مختلف سيوافقه.

في تحكم من uint16 إلى int32 ظهرت False من issubdtype وTrue من can_cast مع safe. يعلن مرجع uint16 المجال 0 إلى 65535، وهو داخل مجال int32 المحدد؛ اختلاف فرع الإشارة لم يمنع السماح بهذا الزوج.

أما int16 إلى uint32 فأعطى False في الفحصين. المجال المعلن للثاني يبدأ عند صفر، فلا يحتوي الطرف السالب لمجال الأول. لا نستنتج السماح بمجرد رؤية العدد 32 أكبر من 16 في اسمي النوعين.

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

اختبرنا ثمانية أسماء ثابتة العرض: int8 وint16 وint32 وint64، ثم uint8 وuint16 وuint32 وuint64. اخترنا كل نوع أولًا مع كل نوع ثانيًا؛ صارت 8×8=64 زوجًا مرتبًا تشمل الأزواج المتطابقة.

لكل زوج نداء issubdtype ونداء can_cast مع safe:128 نداءً و128 قيمة منطقية. ثم لكل نوع ثلاثة أسئلة issubdtype إلى integer وsignedinteger وunsignedinteger؛ أضافت 24 نداءً وقيمة. الإجمالي 152 نداءً و152 نتيجة bool مفردة.

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

قبل النداءات أعلن المرجع أسماء الأنواع وفروع الإشارة ومجالاتها بقوى اثنين. توقع علاقة الأنواع المحددة من تطابق الأسماء، والانتماء المجرد من الفرع المعلن، والسماح من احتواء المجال الهدف للمجال المصدر. لم تستدعِ التوقعات issubdtype أوcan_cast أوiinfo أوissubclass.

وافقت النتائج كلها المرجع داخل الأنواع الثمانية. لم نفحص float أوcomplex أوbool أوobject أوفئات مخصصة أوأسماء مرتبطة بالمؤشرات أوترتيب البايتات أوسياسات casting أخرى أوإصدارات أخرى أوأداءً. لم ننفذ astype أوحسابًا قد يفيض أوتحويلًا أوفحص قيمة حالية. سجل سؤال علاقة النوع وسؤال السماح باسميهما.