Является ли java.lang.Math.PI равным M_PI GCC?

Question

Я кодирую несколько эталонных алгоритмов как в 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 
       ^^^^^ 

что говорит о том, что последние 5 цифр нельзя доверять ,

В то же время, Javadocs сказать, что это java.lang.Math.PI:

double значение, которое находится ближе, чем любой другой к пи, отношение окружности к ее диаметр.

и

public static final double PI 3.141592653589793d 

который опускает сомнительные последние пять цифр от константы.

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

производит

3.14159265358979300000 
       ^^^^^ 

Если у вас есть некоторый опыт в типы данных с плавающей точкой, вы можете убедить меня, что эти библиотеки констант в точности равны? Или что они определенно не равны?

Answer 1

Да, они равны, и их использование будет гарантировать, что GCC и Java реализаций одного и того же алгоритма на той же основе – по крайней мере столько же, сколько с помощью ручной определяется pi константа будет ^{& кинжалом;}.

Одно предостережение, намекнул S. Lott, что реализация GCC должен иметь M_PI в типе double данных, а не long double, чтобы обеспечить эквивалентность. Как Java, так и GCC, похоже, используют 64-разрядное десятичное представление IEEE-754 для своих соответствующих типов данных double. Представление побайтно (СЗБ к МЗБ) значения библиотеки, выраженные как double, может быть получена следующим образом (благодаря JeeBee):

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 

Основополагающий Rep resentations от M_PI (как double) и Math.PI идентичны, вплоть до их бит.

& dagger; – Как отмечалось в Steve Schnepp, выход математических функций, таких как sin, cos, exp и т. Д., Не гарантируется одинаковым, даже если входы в эти вычисления побито идентичны.

Answer 2

Что вы хотите сделать, это распечатать исходный бит-шаблон для значений PI и сравнить их.

В Java используйте метод http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Double.html#doubleToRawLongBits(double), чтобы получить длинное значение, которое вы должны печатать как двоичный.

Java 5 дает:

• ПИ 3.141592653589793
• Сырых бит являются 4614256656552045848
• Двоич- 100000000001001001000011111101101010100010001000010110100011000

В C, вы можете сделать double pi = M_PI; printf("%lld\n", pi); получить то же 64-битное целое число: 4614256656552045848 (спасибо Бруна).

Answer 3

Нет, они не равны, они имеют различное представление в памяти.

В общем, если вы хотите сравнить 2 значения с плавающей запятой, вы не должны использовать == (и если вы не можете работать с termin 'equals'). Вы должны использовать сравнение с epsilon.

double eps = 0.0000001; 
if (Math.abs (Java_PI - Another_Pi) <= eps) 
    System.out.println ("equals"); 

Answer 4

двойной имеет только как 52 бит signficand, так что я думаю, что только дает около 15 основания 10 цифр, которые бы объяснить, почему у вас есть 5 нулей, когда вы просите 20 цифр.

Answer 5

Обратите внимание на следующее.

Два номера совпадают с 16 знаками после запятой. Это почти 48 бит, которые одинаковы.

В 64-разрядном номере с плавающей запятой IEEE это все биты, которые не являются признаками или показателями.

#define M_PI имеет 21 цифру; это около 63 бит точности, что хорошо для 80-битового значения IEEE с плавающей запятой.

Я думаю, что вы видите обычное усечение бит в значении M_PI.

Answer 6

Было бы очень сложно вычислить то же значение, , даже если начальные значения одинаковы.

Результаты вычислений с плавающей точкой иногда отличаются от архитектуры к другой (например, x86/PowerPC), от компилятора к другому (думаю, GCC/MS C++) и даже с тем же компилятором, но с разными параметрами компиляции. Не всегда, но иногда (обычно при округлении). Обычно достаточно для того, чтобы проблема оставалась незамеченной до слишком позднего времени (думаю, что после многих итераций и многих многих закругляющих различий)

Это довольно сложно для кросс-платформенных многопользовательских игр, которые вычисляют каждую итерацию игры gamestate синхронно (каждый узел получает только вход, а не фактические структуры данных).

Следовательно, если даже на одном языке (C/C++) результаты могут быть разными: от виртуальной машины Java до родного хоста он также может быть другим.

Update:

Я не могу найти источник, я прочитал, но я нашел paper by Sun по этому вопросу.

Как вы сами на себя ответили, java.lang.Math.PI и M_PI GCC можно управлять одинаковым значением. Дьявол скрывается в использовании этих значений. IEEE не определяет вывод математических функций (sin, cos, exp, ...). Поэтому вывод вычислений, что не обязательно то же самое.

Answer 7

Вы можете использовать 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)); 
} 

Answer 8

навевает воспоминания того, чтобы получить значение пи в Fortran.

Поскольку не было библиотек констант, я либо использовал 4 * atan (1.), Либо acos (-1.).