دقة الحقائق من خلال writeln/readln في دلفي

Question

يقوم تطبيق عملائي بتصدير واستيراد عدد لا بأس به من المتغيرات من النوع الحقيقي من خلال ملف نصي باستخدام writeln وreadln.لقد حاولت زيادة عرض الحقول المكتوبة بحيث يبدو الكود كما يلي:

writeln(file, exportRealvalue:30); //using excess width of field
....
readln(file, importRealvalue);

عندما أقوم بالتصدير ثم الاستيراد والتصدير مرة أخرى ومقارنة الملفات، أحصل على اختلاف في الرقمين الأخيرين، على سبيل المثال (قد يكون معطلاً على العدد الفعلي للأرقام هنا ولكنك تفهمه):

-1.23456789012E-0002
-1.23456789034E-0002

يُحدث هذا فرقًا فعليًا في التطبيق، لذا يريد العميل معرفة ما يمكنني فعله حيال ذلك.الآن لست متأكدًا من أن الكتابة/القراءة فقط هي التي تفعل ذلك ولكني اعتقدت أنني سأطرح سؤالاً سريعًا قبل أن أغوص في المكدس مرة أخرى.هل أنا بحاجة للذهاب ثنائي في هذا؟

هذا ليس تطبيقًا يتعامل مع العملة أو شيء من هذا القبيل، أنا فقط أكتب وأقرأ القيم من/إلى الملف.أعلم أن النقاط العائمة تكون غريبة بعض الشيء في بعض الأحيان واعتقدت أن أحد الإجراءات الروتينية (writeln/readln) قد يكون له بعض الأعمال المضحكة الجارية.

Answer 1

إذا كنت تريد تحديد دقة حقيقية باستخدام WriteLn، فاستخدم ما يلي:

WriteLn(RealVar:12:3);

يقوم بإخراج قيمة Realvar بما لا يقل عن 12 موضعًا وبدقة 3.

Answer 2

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

من مساعدة دلفي:

الأنواع الحقيقية Win32 الأساسية

                                            | Significant | Size in 
Type     | Range                            | digits      | bytes
---------+----------------------------------+-------------+----------
Real     | -5.0 x 10^–324 .. 1.7 x 10^308   | 15–16       |   8  
Real48   | -2.9 x 10^–39 .. 1.7 x 10^38     | 11-12       |   6   
Single   | -1.5 x 10^–45 .. 3.4 x 10^38     |  7-8        |   4   
Double   | -5.0 x 10^–324 .. 1.7 x 10^308   | 15-16       |   8   
Extended | -3.6 x 10^–4951 .. 1.1 x 10^4932 | 10-20       |  10   
Comp     | -2^63+1 .. 2^63–1                | 10-20       |   8   
Currency | -922337203685477.5808..          |             | 
                    922337203685477.5807    | 10-20       |   8   

ملحوظة:الستة بايت حقيقي48 تم استدعاء النوع حقيقي في الإصدارات السابقة من Object Pascal.إذا كنت تقوم بإعادة ترجمة التعليمات البرمجية التي تستخدم النوع الحقيقي الأقدم المكون من ستة بايت في دلفي، فقد ترغب في تغييره إلى حقيقي48.يمكنك أيضًا استخدام توجيه المترجم {$REALCOMPATIBILITY ON} للتشغيل حقيقي العودة إلى نوع ستة بايت.تنطبق الملاحظات التالية على الأنواع الحقيقية الأساسية.

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

لاحظ أن النطاق أكبر من الأرقام المهمة.لذلك يمكنك الحصول على رقم أكبر ثم يمكن تخزينه بدقة.أوصي بالتقريب إلى الأرقام المهمة لمنع حدوث ذلك.

Answer 3

عند استخدام أنواع الفاصلة العائمة، يجب أن تكون على دراية بقيود الدقة المفروضة على الأنواع المحددة.على سبيل المثال، يحتوي نوع IEEE-754 ذو 4 بايت على حوالي 7.5 أرقام مهمة فقط من الدقة.يحتوي نوع IEEE-754 ذو الثمانية بايت على ضعف عدد الأرقام المهمة تقريبًا.من الواضح أن نوع دلفي الحقيقي يتمتع بدقة تبلغ حوالي 11 رقمًا مهمًا.والنتيجة هي أن أي أرقام إضافية للتنسيق تحددها من المحتمل أن تكون ضوضاء يمكن أن تؤدي إلى تحويلات بين القيم المنسقة ذات الأساس 10 وقيم الفاصلة العائمة ذات الأساس 2.

Answer 4

أولاً، سأحاول معرفة ما إذا كان بإمكاني الحصول على أي مساعدة من استخدام Str مع وسيطات مختلفة أو زيادة دقة الأنواع في تطبيقك.(هل حاولت استخدام الموسعة؟)

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

Answer 5

اعتمادًا على مقدار المعالجة التي يتعين عليك القيام بها، قد يكون البديل هو الاحتفاظ بالأرقام بتنسيق BCD للاحتفاظ بالدقة الأصلية.

Answer 6

من الصعب الإجابة على هذا السؤال دون معرفة نوع ExportRealValue وImportRealValue.وكما ذكر آخرون، فإن الأنواع الحقيقية جميعها لها دقة مختلفة.

تجدر الإشارة إلى أنه، خلافًا لبعض الأفكار، فإن الدقة الموسعة ليست دائمًا أعلى دقة.الممتد هو 10-20 رقمًا مهمًا حيث يكون المضاعفة 15-16.نظرًا لأنك تواجه مشكلة في الشكل العاشر، فربما تستخدمه ممتدًا بالفعل.

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