base_repr: هل padding يحدد طول النص؟

عد الأصفار المضافة

تعرف الوثائق padding بأنه عدد الأصفار المضافة يسارًا. تقبل base_repr عددًا صحيحًا موجبًا أو سالبًا وتعيد str، وتتيح أساسًا من 2 إلى 36. [1] نثبت هنا الأساس 16 ونغير padding وحده.

تقرأ int النص بأساس محدد، وتقبل إشارة وأصفارًا بادئة. للحروف قيم رقمية في الأسس المناسبة. [2] نستعمل int(s,16) لقراءة كل نص ناتج، ونراجع القيمة بمرجع مستقل.

في binary_repr، width طول للنص مع شرط الكفاية؛ وقد يغير كتابة السالب إلى المتمم الثنائي. [3] هذا تعريف للمقارنة فقط؛ لم نشغل binary_repr في التجربة الحالية.

تشغيلنا NumPy 2.3.5 على CPython 3.12.14، بمدخلات Python int مؤلفة بلا وحدات. نحتفظ بالعدد والأساس وpadding والنص والعدد المقروء؛ فلا نستبدل عدد أصفار مضافة بطلب طول كلي.

العدد 93 بثلاثة إعدادات

بدأنا n=93. من القسمة على 16 نحصل على خارج 5 وباقٍ 13؛ نرمز للباقي بالحرف D في مرجعنا، فيكون النص بلا حشو 5D. حسابنا 5×16+13=93.

أعاد np.base_repr(n,base=16,padding=0) النص "5D". مع padding=2 أعاد "005D"، ومع padding=4 أعاد "00005D". نوع النتائج الثلاث str؛ لم تعد الدالة العدد الصحيح نفسه.

حفظ النص الأول خانتين رقميتين، والثاني أربعًا، والثالث ستًا. الطلب 2 أضاف صفرين قبل الخانتين الموجودتين؛ لم يقل إن النتيجة يجب أن تحتوي خانتين فقط. والطلب 4 أضاف أربعة أصفار، لا العدد اللازم لبلوغ أربعة.

أعاد int(s,16) العدد 93 لكل نص من الثلاثة. ونحسب 005D بأوزان الخانات: الصفران لا يضيفان مقدارًا، وتبقى 5×16+13. زيادة طول النص لم تغير القيمة في هذه القراءة.

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

الإشارة ونمو عدد الخانات

للتحكم السالب اخترنا n=-93. أعادت الإعدادات 0 و2 و4 النصوص "-5D" و"-005D" و"-00005D". بقيت الشرطة أمام المقدار المحشو، وقرأ int(s,16) النصوص كلها إلى −93.

النص -005D يحمل أربع خانات رقمية وخمسة محارف إجمالًا لأن الشرطة محرف إضافي. لم تصبح الشرطة صفرًا من الصفرين المطلوبين، ولم تختف عند زيادة padding في هذه الحالات. نعد الخانات والمحارف كلًا على حدة.

اخترنا حدًا عدديًا آخر: 255 ثم 256، مع padding=2 في الحالتين. خرج "00FF" للأول و"00100" للثاني. الأول أربع خانات والثاني خمس، رغم ثبات عدد الأصفار المضافة عند اثنين.

في مرجعنا 15×16+15=255، أما 256 فيساوي 16**2، لذلك يحتاج مقداره 100 ثلاث خانات بدل FF ذي الخانتين. الصفران المضافان سبقا المقدار كاملًا في النصين؛ لا نقتطع خانة منه لفرض طول واحد.

قرأ int(s,16) النصين إلى 255 و256 على الترتيب. هذه الحالة تبين لماذا لا يحدد padding وحده طول كل النتائج: طول المقدار تغير أولًا، ثم أضيف العدد نفسه من الأصفار. ولم ننشئ بايتات أو نختبر تنسيق ملف.

المرجع وحصر التشغيل

اخترنا المقادير الصحيحة من 93 إلى 109: سبعة عشر مقدارًا. مع الموجب والسالب صارت 34 قيمة مختلفة. أضفنا 255 و256 موجبتين، فكان العدد 36 مدخلًا مختلفًا، لا 216 مدخلًا.

لكل مدخل استدعاءات base_repr بثلاثة إعدادات padding: صفر واثنان وأربعة. المجموع 36×3=108 نصوص. قرأنا كل نص باستدعاء int في الأساس 16، فحفظنا 108 أعداد أخرى.

إجمالي الاستدعاءات المسماة 216 ونتائجها 216: 108 نصوص و108 أعداد صحيحة. أطوال النصوص وعد الخانات بيانات مشتقة لفحص النتائج، ولا نعدها مخارج أصلية إضافية أو استدعاءات NumPy جديدة.

قبل أي استدعاء بنى المرجع جميع النصوص المتوقعة بقسمة صحيحة متكررة على 16 واستعمال أبجدية رقمية مستقلة. أضاف الشرطة عند السالب ثم عدد الأصفار المحدد ثم مقدار العدد؛ لم يستعمل base_repr أو binary_repr أو hex أو bin أو format لبناء التوقع.

راجع مرجع ثانٍ كل نص بجمع أوزان الخانات من اليسار: يضرب المجموع السابق في 16 ثم يضيف قيمة الخانة الحالية، ويطبق الإشارة. وافقت النصوص كلها التوقع، ووافقت نتائج int المدخلات.

النطاق أساس 16 ومدخلات Python int غير صفرية، مع padding من القيم الثلاث فقط. لم نفحص الأساس الافتراضي أو أساسًا آخر أو مدخلًا غير صحيح أو حشوًا سالبًا أو غير صحيح أو أنواع NumPy أو الكسور أو المصفوفات أو الأداء أو الذاكرة الفعلية. حفظ الإعداد والنص يمنع الخلط بين العدد المضاف والطول الناتج.