format_float_scientific: هل exp_digits يغير القيمة؟

المعامل والأس

توثق exp_digits حشو الأس بأصفار حتى يبلغ الحد الأدنى المحدد. [1]

الدالة تعيد سلسلة بالترميز العلمي، وتقبل Python float ضمن مدخلاتها. [1] هذا النص هو الناتج الذي نفحصه، وليس ملفًا أو ذاكرة قياس.

يوثق Fraction بناء كسر من بسط ومقام، ويحفظ قيمة float عند الإنشاء منه. [2] استخدمناه لفحص مدخلاتنا الدقيقة وحساب قيمة النص في المرجع.

في الدالة الموضعية يغير fractional نطاق عد precision: بعد النقطة أو أرقام معنوية. [3] هذا تعريف قرأناه للمقارنة؛ تجربتنا الحالية تستخدم الدالة العلمية وexp_digits، ولم نشغل الدالة الموضعية هنا.

ثبتنا precision=2 وunique=False وtrim="k" في NumPy 2.3.5 على CPython 3.12.14. جميع مدخلاتنا Python float موجبة منتهية ومؤلفة بلا وحدات؛ المقارنة تغير exp_digits فقط.

المثال 1024

أنشأنا x=1024.0 من العدد الصحيح 2**10، وتحققنا أن كسره المخزن يساوي 1024 تمامًا. حفظنا بايتاته قبل استدعاء الدالة وبعده، فبقيت ثابتة في المقارنة.

نفذنا np.format_float_scientific(x,precision=2,unique=False,trim="k",exp_digits=1). أعاد النص "1.02e+3" من نوع str. الجزء السابق للحرف e هو المعامل 1.02، والجزء اللاحق يكتب الأس الموجب 3.

مع exp_digits=3 وبقية الخيارات نفسها، كان النص "1.02e+003". بقي المعامل 1.02 نفسه، لكن الجزء الرقمي من الأس أصبح 003، أي ثلاث خانات بدل واحدة. علامة + ليست رقمًا من تلك الخانات.

في حسابنا 003 و3 هما الأس نفسه؛ لذلك كلا النصين يعني 1.02×10**3=1020. وجود الصفرين قبل 3 لم يجعل قوة عشرة أكبر، ولم يضف خانات إلى المعامل.

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

الإشارة والحد الأدنى

اخترنا تحكمًا صغيرًا x=1/64، أي 0.015625 الممثلة بدقة في مدخلنا. أعاد العرض 1 النص "1.56e-2"، وأعاد العرض 3 النص "1.56e-002". ظل العدد المدخل موجبًا؛ السالب هنا إشارة الأس.

النصان يمثلان 1.56×10**(-2)=0.0156. فصل علامة - عن رقمي 002 ضروري عند عد الخانات؛ لا نجعل ظهور العلامة دليلًا على أن المعامل أو المدخل سالب.

للتحكم الكبير اخترنا x=2**40=1099511627776، وهو دقيق في مدخلنا أيضًا. أعاد exp_digits=1 النص "1.10e+12"، وأعاد exp_digits=3 النص "1.10e+012".

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

قيمة النصين الكبيرين هي 1.10×10**12=1100000000000 في حسابنا. اختلافها عن المدخل لا يختفي بكتابة +012 بدل +12. ونحفظ الصفر الأخير في المعامل كما ورد في النص، دون أن نعطيه معنى قياس غير منفذ.

الحصر ونطاق الدليل

أنشأنا 17 مدخلًا من 2**k لكل k صحيح من 10 إلى 26، مع 1024 أولًا. أضفنا تحكمي 1/64 و2**40؛ صار العدد 19 قيمة مختلفة عدديًا وببايتاتها، وكلها ممثلة بدقة من الكسور الأصلية.

لكل قيمة استدعاء عند exp_digits=1 وآخر عند exp_digits=3؛ المجموع 19×2=38 نصًا محفوظًا. بقي المعامل متطابقًا داخل كل زوج، وبقيت قيمة الزوج المحسوبة متساوية، مع ثبات بايتات المدخلات كلها.

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

تأكدنا أن الحالات ليست تعادلًا، ولا يسبب تقريب المعامل فيها انتقالًا إلى 10. بنى المرجع النص من أعداد صحيحة والنقطة وe وإشارة الأس والأصفار المطلوبة؛ لم يستعمل الدالة المختبرة أو Python round أو format لتوليد التوقع.

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

لم نفحص حذف exp_digits أو precision آخر أو unique=True أو بقية trim أو الحشو، ولا الصفر أو مدخلًا سالبًا أو قيمًا خاصة أو أنواع NumPy العائمة الأخرى أو المصفوفات أو الأداء. لم نحلل Dragon4 أو نختبر دقة قياس. احتفظ بإعداد المعامل وعرض الأس والمعنى العددي عند نقل النص.