سؤال

أقوم بترميز العديد من الخوارزميات المرجعية في كل من Java و C/C ++. بعض هذه الخوارزميات تستخدم π. أود أن تنتج تطبيقين لكل خوارزمية مطابق النتائج ، دون التقريب بشكل مختلف. طريقة واحدة للقيام بذلك التي نجحت باستمرار حتى الآن هي استخدام محدد حسب الطلب pi ثابت وهو نفسه بالضبط في كلتا اللغتين ، مثل 3.14159. ومع ذلك ، فإنه يصيبني بسخيفة لتحديد PI عندما تكون هناك بالفعل ثوابت عالية الدقة محددة في كل من مكتبات Java و GCC.

لقد قضيت بعض الوقت في كتابة برامج اختبار سريعة ، والنظر في الوثائق لكل مكتبة ، وقراءة أنواع النقاط العائمة. لكنني لم أتمكن من إقناع نفسي بأن java.lang.math.pi (أو java.lang.strictmath.pi) هو ، أو لا يساوي ، m_pi في Math.H.

GCC 3.4.4 (Cygwin) Math.H يحتوي على:

#define M_PI            3.14159265358979323846
                                         ^^^^^

لكن هذا

printf("%.20f", M_PI);

ينتج عنه

3.14159265358979311600
                 ^^^^^

مما يشير إلى أنه لا يمكن الوثوق بالأرقام الخمسة الأخيرة.

وفي الوقت نفسه ، يقول Javadocs أن java.lang.math.pi هو:

ال double القيمة الأقرب من أي شيء آخر بي, ، نسبة محيط دائرة إلى قطرها.

و

public static final double PI  3.141592653589793d

الذي يحذف أرقام الخمسة الأخيرة المشكوك فيها من الثابت.

System.out.printf("%.20f\n", Math.PI);

ينتج عنه

3.14159265358979300000
                 ^^^^^

إذا كان لديك بعض الخبرة في أنواع البيانات العائمة ، هل يمكنك إقناعي بأن ثوابت المكتبة هذه متساوية تمامًا؟ أو أنها بالتأكيد ليست متساوية؟

هل كانت مفيدة؟

المحلول 4

نعم ، فهي متساوية ، وسيؤمن استخدامها أن تطبيقات GCC و Java من نفس الخوارزمية على قدم المساواة-على الأقل بقدر استخدام استخدام محدد يدويًا pi ثابت.

تحذير واحد ، ألمح من قبل S. لوت, ، هو أن تنفيذ دول مجلس التعاون الخليجي يجب أن يحمل M_PI في double نوع البيانات ، وليس long double, ، لضمان التكافؤ. يبدو أن كل من Java و GCC يستخدمان تمثيل IEEE-754 العشري 64 بت على كل منهما double أنواع البيانات. تمثيل Bytewise (MSB إلى LSB) من قيمة المكتبة ، معبراً عنه ك double, ، يمكن الحصول عليها على النحو التالي (بفضل جيبي):

pi_bytes.c:

#include <math.h>
#include <stdio.h>
int main()
{
   double pi = M_PI;
   printf("%016llx\n", *((uint64_t*)&pi));
}

pi_bytes.java:

class pi_bytes
{
   public static void main(String[] a)
   {
      System.out.printf("%016x\n", Double.doubleToRawLongBits( Math.PI ) );
   }
}

تشغيل كليهما:

$ gcc -lm -o pi_bytes pi_bytes.c && ./pi_bytes
400921fb54442d18

$ javac pi_bytes.java && java pi_bytes
400921fb54442d18

التمثيل الأساسي ل M_PIdouble) و Math.PI متطابقة ، وصولاً إلى أجزاءهم.

† - كما لاحظ ستيف شنب, ، لا يضمن إخراج وظائف الرياضيات مثل SIN و COS و EXP ، إلخ.

نصائح أخرى

لاحظ ما يلي.

الرقمين متماثلان إلى 16 مكانًا عشريًا. هذا ما يقرب من 48 بت هي نفسها.

في رقم IEEE 64 بت الفاصلة ، هذا هو كل البتات التي لا توجد علامات أو أسس.

ال #define M_PI لديه 21 رقمًا ؛ هذا حوالي 63 بت من الدقة ، وهو أمر جيد لقيمة نقطة عائمة 80 بت.

ما أعتقد أنك تراه هو اقتطاع البتات في M_PI القيمة.

ما تريد القيام به هو طباعة نمط بت الخام لقيم PI ومقارنتها.

في جافا استخدم http://java.sun.com/j2se/1.5.0/docs/api/java/lang/double.html#doubletorawlongbits (double) طريقة للحصول على القيمة الطويلة التي يجب عليك طباعتها على أنها ثنائية.

Java 5 يعطي:

  • PI هو 3.141592653589793
  • البتات الخام هي 4614256656552045848
  • Binary هو 100000000001001001000011111110110101010100010001000010110100011000

في C ، يمكنك القيام به double pi = M_PI; printf("%lld\n", pi); للحصول على نفس عدد صحيح 64 بت: 4614256656552045848 (شكرًا برونو).

سيكون من الصعب للغاية حساب نفس القيمة ، حتى لو كانت قيم البداية هي نفسها.

تختلف نتائج حساب النقطة العائمة في وقت ما عن بنية إلى أخرى (فكر في X86/PowerPC على سبيل المثال) ، من برنامج التحويل البرمجي إلى آخر (فكر في GCC/MS C ++) وحتى مع نفس المترجم ، ولكن خيارات التجميع المختلفة. ليس دائما ، ولكن في بعض الأحيان (عادة عند التقريب). عادةً ما تكون المشكلة غير مرغوب فيها حتى فوات الأوان (فكر بعد العديد من التكرارات ، والعديد من الاختلافات الدائرية)

هذا يجعل من الصعب للغاية بالنسبة للألعاب متعددة اللاعبين عبر المنصات التي تحسب كل تكرار من Gamestate بشكل متزامن (كل عقدة تستقبل فقط الإدخال ، وليس هياكل البيانات الفعلية).

لذلك ، إذا كانت نتائج اللغة (C/C ++) نفسها قد تكون مختلفة ، فقد تكون مختلفة أيضًا من Java VM إلى مضيف أصلي.

تحديث:

لا يمكنني العثور على المصدر الذي قرأته ، لكنني وجدت أ ورقة من الشمس في هذا الشأن.

كما أجبت على نفسك يمكن إدارة java.lang.math.pi و m_pi من GCC للحصول على نفس القيمة. يختبئ الشيطان في استخدام هذه القيم. لا تحدد IEEE إخراج وظائف الرياضيات (الخطيئة ، cos ، exp ، ...). لذلك هو إخراج الحساب هذا ليس هو نفسه بالضرورة.

يحتوي المزدوج فقط على 52 بت من العلامات ، لذا أعتقد أن هذا يمنحك فقط حوالي 15 رقمًا من الأساس 10 من شأنه أن يفسر سبب وجود 5 أصفار عندما تطلب 20 رقمًا.

يمكنك استخدام BigDecimal لمزيد من الدقة مثل:

private static final BigDecimal PI = new BigDecimal(
"3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679" +
    "8214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196" +
    "4428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273" +
    "7245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094" +
    "3305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912" +
    "9833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132" +
    "0005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235" +
    "4201995611212902196086403441815981362977477130996051870721134999999837297804995105973173281609631859" +
    "5024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303" +
    "5982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989" +
    "3809525720106548586327886593615338182796823030195203530185296899577362259941389124972177528347913151" +
    "5574857242454150695950829533116861727855889075098381754637464939319255060400927701671139009848824012" +
    "8583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912" +
    "9331367702898915210475216205696602405803815019351125338243003558764024749647326391419927260426992279" +
    "6782354781636009341721641219924586315030286182974555706749838505494588586926995690927210797509302955" +
    "3211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000" +
    "8164706001614524919217321721477235014144197356854816136115735255213347574184946843852332390739414333" +
    "4547762416862518983569485562099219222184272550254256887671790494601653466804988627232791786085784383" +
    "8279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863" +
    "0674427862203919494504712371378696095636437191728746776465757396241389086583264599581339047802759009" +
    "9465764078951269468398352595709825822620522489407726719478268482601476990902640136394437455305068203" +
    "4962524517493996514314298091906592509372216964615157098583874105978859597729754989301617539284681382" +
    "6868386894277415599185592524595395943104997252468084598727364469584865383673622262609912460805124388" +
    "4390451244136549762780797715691435997700129616089441694868555848406353422072225828488648158456028506" +
    "0168427394522674676788952521385225499546667278239864565961163548862305774564980355936345681743241125"
);

public static void main(String... args) throws InterruptedException {
    System.out.println("PI to " + PI.scale() + " digits is " + PI);
    System.out.println("PI^2 to " + PI.scale() + " digits is " + 
            PI.multiply(PI).setScale(PI.scale(), BigDecimal.ROUND_HALF_UP));
}

يعيد ذكريات عن الاضطرار إلى الحصول على قيمة لـ PI في Fortran.

نظرًا لعدم وجود مكتبات للثوابت ، فقد استخدمت إما 4*atan (1.) أو ACOS (-1.).

لا ، فهي ليست متساوية ، لديهم عرض تقديمي مختلف في الذاكرة.

بشكل عام عندما تريد مقارنة قيمتين من النقطة العائمة ، يجب ألا تستخدم == (وإذا كان الأمر كذلك ، فلا يمكنك العمل باستخدام Termin 'Equals'). يجب عليك استخدام المقارنة مع Epsilon.

double eps = 0.0000001;
if (Math.abs (Java_PI - Another_Pi) <= eps)
  System.out.println ("equals");
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top