كانت هناك بالفعل العديد من المقالات حول Habré (
واحد ،
اثنان ،
اثنان ونصف ) مخصصة لتنسيق النقطة العائمة Posit الجديد ، والتي قدمها مؤلفوها على أنها متفوقة على تعويم IEEE 754 القياسي من جميع النواحي. وجد التنسيق الجديد أيضًا أن النقاد (
شخص واحد أو
اثنين ) يزعمون أن عيوب Posit تفوق مزاياها. ولكن ماذا لو كان لدينا بالفعل شكل ثوري جديد ، والنقد ناجم ببساطة عن الحسد وعدم الكفاءة لأولئك الذين ينتقدون؟ حسنًا ، أفضل طريقة لمعرفة ذلك هي أن تأخذ وتحسب نفسك.
مقدمة
يتم توضيح مزايا التنسيق الجديد من خلال أمثلة بسيطة مع إضافة / ضرب أرقام بترتيب مماثل ، مما يؤدي إلى دقة أعلى من رقم واحد أو اثنين. ومع ذلك ، في العمليات الحسابية الحقيقية ، لا يهم زائد / ناقص خطأ واحد في عملية واحدة ، لأننا نحسبها بدقة محدودة على أي حال.
من المهم
تراكم الخطأ نتيجة لتسلسل العمليات ، عندما تبدأ الأخطاء في الأرقام السفلية بعد بعض الوقت في حدوث الخطأ في الأقدمية. هذا هو ما سنحاول تجربته.
تدريب
للاختبار ، أخذت تطبيق Posit بعنوان pathos
من هنا . لتجميعها في Visual Studio ، اضطررنا إلى إضافة السطر #define CLZ (n) __lzcnt (n) في ملف util.h واستبدال 0.f / 0.f في ملف posit.cpp مع std :: numeric_limits <float> :: quiet_NaN (). بالمناسبة ، لم يتم العثور على تطبيقات للوظائف الرياضية الأولية (حسناً ، باستثناء الجذر) في هذه المكتبة - وهذا سبب آخر للاشتباه في حدوث خطأ ما.
اختبار 1. ضرب الأعداد المركبة
يتم استخدام تحويل فورييه ، المحسوب باستخدام الحساب المعقد ، حيثما كان ذلك ممكنًا. في البداية ، أردت اختبار Posit على تحويل فورييه ؛ ولكن نظرًا لأن دقتها تعتمد اعتمادًا كبيرًا على التنفيذ ، يجب عليك مراعاة جميع الخوارزميات الأساسية التي تستهلك وقتًا طويلًا في الاختبار الصحيح ؛ لذلك ، يمكنك أن تبدأ عملية أبسط - ضرب الأرقام المعقدة.
إذا أخذنا متجهًا معينًا وقمنا بتدويره 360 مرة بمقدار 1 درجة ، في النهاية يجب أن نحصل على نفس المتجه الأصلي. في الواقع ، ستكون النتيجة مختلفة بعض الشيء بسبب تراكم الأخطاء - وكلما زاد عدد المنعطفات ، زاد الخطأ. لذلك ، باستخدام هذا الرمز البسيط
complex<T> rot(cos(a), sin(a)); complex<T> vec(length, 0); for (long i = 0; i < count; i++) { vec *= rot; } cout << "error: " << stdev(vec.real() - length, vec.imag()) << endl;
نقوم بتدوير ناقل مع أنواع مختلفة من البيانات ، وسننظر في الخطأ على أنه الانحراف المربعي المتوسط للمتجه الناتج عن الأصل (والذي يمكن تفسيره أيضًا على أنه طول متجه الاختلاف).
أولاً ، خذ متجه الوحدة باعتباره أكثر داعم لـ Posit:
لا يوجد قائد واضح هنا بعد - الميزة هي ضعف ميزة واحدة أو أخرى. زيادة طول المتجه استدارة إلى 1000:
قيم الخطأ متساوية تقريبًا. تفضل - 1،000،000:
هنا يتخلف Posit بالفعل بثقة ، ويبدأ الخطأ المزدوج في الزحف إلى مكانه. لنأخذ طولًا أطول - 10
10 لتقدير ميزات تنسيقات الفاصلة العائمة تمامًا:
هنا الشيء الأكثر إثارة للاهتمام في البداية ، في 4 تكرارات - عندما يعطي تعويم خطأ يتناسب مع مضاعفة ، وبوسيت بالفعل نتيجة غير صحيحة تماما.
اختبار 2. حساب متعدد الحدود الرشيد
نظرًا لعدم وجود وظائف رياضية في المكتبة الأصلية ، فسنحاول القيام بشيء بمفردنا. يتم تقريب العديد من الوظائف بشكل سيء عن طريق التوسع في سلسلة تايلور ، وهي أكثر ملاءمة للحساب من خلال التقريب من قبل كثير الحدود الرشيد. يمكن الحصول على هذا التقريب بطرق مختلفة ، بما في ذلك التحليل بحتة - من خلال
تقريب Padé . علاوة على ذلك ، سنأخذ الأمر للاختبار ، مع وجود معاملات كبيرة بما فيه الكفاية بحيث تخضع أيضًا للتقريب قبل الحساب.
باستخدام Wolfram Mathematica وأمر PadeApproximant [Sin [x] و {x، 0، {11، 11}}]
نحصل على كثير الحدود المعقولة لتقريب الجيب ، والذي يوفر دقة مزدوجة في النطاق من حوالي -2 إلى 2:
عادةً ما
يتم استخدام
مخطط Horner مباشرة لإجراء العمليات الحسابية من أجل التوفير في العمليات الحسابية. في حالتنا (باستخدام HornerForm) سيبدو
template< typename T > T padesin(T x) { T xx = x*x; return (x*(T(363275871831577908403200.) + xx*(-T(54839355237791393068800.) + xx*(T(2120649063015013090560.) + xx*(-T(31712777908498486800.) + xx*(T(203385425766914820.) - T(481959816488503.) * xx)))))) / (T(363275871831577908403200.) + xx*(T(5706623400804924998400.) + xx*(T(44454031219351353600.) + xx* (T(219578286347980560.) + xx*(T(707177798947620.) + T(1230626892363.) * xx))))); }
لنرى:
كما ترون ، يبدو الموقف مع Posit محزنًا - بالكاد يتم طلب رقمين مهمين.
استنتاج
لسوء الحظ ، لم تحدث معجزة وتم إلغاء الثورة. إن ميزة Posit المعروضة على حسابات مفردة ليست أكثر من خدعة ، وسعرها هو انخفاض كارثي في الدقة في الحسابات الحقيقية "الثقيلة". السبب الوحيد المنطقي هو استخدام Posit بدلاً من تعويم IEEE 754 أو النقطة الثابتة وهو التدين. باستخدام التنسيق السحري ، الذي تضمنه دقة الإيمان المقدس لمبدعيها ، يمكن أن يجلب الكثير من العجائب لبرامجك!
PS
شفرة المصدر للتحقق والنقد .
تابع PPS.