can_cast: هل تفحص أن القيمة الحالية تتسع؟

افصل السياسة والقيمة

منذ الإصدار 2.0 أزيل من can_cast منطق القيمة للمصفوفات بلا محاور. [1]

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

أمثلتنا قيم تعليمية اخترناها وشغّلناها محليًا. نثبت النوع والشكل والإصدار قبل النظر إلى النتيجة؛ لا نحاول إثبات قاعدة واحدة لجميع تحولات الأعداد الصحيحة والعائمة والمركبة.

قارن المدخلين

في NumPy 2.3.5 على CPython 3.12.14 أنشأنا a=np.array(7,dtype=np.uint16) وb=np.array(300,dtype=np.uint16). شكل كل منهما ()؛ توجد قيمة واحدة دون محور، وليست مصفوفة فارغة.

أعاد np.iinfo(np.uint8) الحدين 0 و255، وأعاد np.iinfo(np.uint16) الحدين 0 و65535. نستخدم هذه الملاحظات المسجلة للمقارنة: 7 داخل المجال الأصغر؛ 300 يتجاوز حده الأعلى بمقدار 45.

ثم شغّلنا np.can_cast(a,np.uint8,casting="safe") والاستدعاء نفسه مع b. ظهر False في الحالتين. اختلاف العدد الحالي لم يغيّر جواب هذه السياسة مع زوج النوعين المختار.

أعدنا التحكم بالنوعين مباشرة: np.can_cast(np.uint16,np.uint8,casting="safe") أعطى False، والاتجاه العكسي من uint8 إلى uint16 أعطى True. لا نستخدم هاتين النتيجتين لتوقع أنواع أخرى لم نفحصها.

المقارنة العددية 0≤7≤255 صحيحة، لكنها لم تجعل الاستدعاء الأول يعطي True. وبالمثل، لا تعني False أن القيمة 7 نفسها مستحيلة التمثيل في المجال الأصغر؛ إنها نتيجة الاختبار الذي شغّلناه.

راجع التحويل

astype تحول المصفوفة إلى النوع المطلوب، وتحدد casting قاعدة السماح. [2]

استدعينا a.astype(np.uint8,casting="safe") وb.astype(np.uint8,casting="safe"). ظهر TypeError في الحالتين. لم نحصل على قيمة ناتجة في هذا المسار، حتى مع العدد 7 الذي يدخل المجال العددي الأصغر.

في استدعاءين مستقلين اخترنا casting="unsafe" صراحة؛ أعطى a.astype(np.uint8,casting="unsafe") القيمة 7، وأعطى b.astype(np.uint8,casting="unsafe") القيمة 44. كان نوع الناتجين uint8، وبقي الأصلان من uint16 بالقيمتين 7 و300.

نستطيع مراجعة المثال الثاني حسابيًا: 300=256+44. القيمة الجديدة تختلف عن الأصل بمقدار 256، وليست 255؛ فلم يتحول العدد في مثالنا إلى الحد الأعلى للمجال. لم نشغّل عملية قصّ أو نطلبها.

أما العدد 7 فظهر دون تغير في مسار unsafe. وجود نتيجة محفوظة واحدة لا يلغي المثال الآخر؛ نميز السماح بالتنفيذ من تحقق الحفاظ على الرقم في كل حالة معلنة.

حدد النطاق

كررنا التجربة على 512 عددًا صحيحًا، من 0 إلى 511 شاملًا. في كل مرة أنشأنا مصفوفة uint16 بلا محاور، ثم اختبرنا رفض can_cast مع safe، وظهور TypeError عند astype مع safe، ومساواة ناتج unsafe لباقي قسمة العدد على 256، وبقاء قيمة الأصل ونوعه وشكله.

هذه أربعة فحوص لكل عدد: 512×4=2048. أضفنا خمسة تحكمات: اتجاهي تحويل النوعين مع safe، والسماح مع unsafe، وحدود uint8، وحدود uint16؛ صار الإجمالي 2053، ومرت جميع الفحوص.

يحفظ سجلنا أيضًا الحالات 0 و7 و255 و256 و300 و511. مثلًا، التحويل غير المقيد في هذا التشغيل أعطى 0 للعدد 256، و255 للعدد 511؛ نعلنها ملاحظات لهذا النطاق، لا صيغة تجريبية لكل نوع.

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