blocks|key|2215208|text|您要做的是打印出PI值的原始位模式并对它们进行比较。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2215209|在Java中，使用http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Double.html#doubleToRawLongBits(double)方法获得应该以二进制形式打印的长值。|offset|length|2215210|Java+5给出：|2215211|PI为3.141592653589793|unordered-list-item|2215212|原始位是4614256656552045848|2215213|二进制是100000000001001001000011111101101010100010001000010110100011000|2215214|在C中，您可以执行double+pi+=+M_PI;+printf("%25lld\n",+pi);来获得相同的64位整数:+4614256656552045848+(谢谢布鲁诺)。|style|CODE|2215215|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Double.html#doubleToRawLongBits(double)^0|0|9|2H|0|0|0|0|0|0|9|13|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@$D|12|E|13|1|14]]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|16|8|@]|9|@]|A|$]]|$1|K|3|L|5|J|7|17|8|@]|9|@]|A|$]]|$1|M|3|N|5|J|7|18|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|19|8|@$D|1A|E|1B|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

What you want to do is print out the raw bit pattern for the PI values and compare them.

In Java use the <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Double.html#doubleToRawLongBits(double)" rel="noreferrer">http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Double.html#doubleToRawLongBits(double)</a> method to get the long value that you should print as binary.

Java 5 gives:

<ul>
<li>PI is 3.141592653589793</li>
<li>Raw bits is 4614256656552045848</li>
<li>Binary is 100000000001001001000011111101101010100010001000010110100011000</li>
</ul>

In C, you can do <code>double pi = M_PI; printf("%lld\n", pi);</code> to obtain the same 64bit integer: 4614256656552045848 (thanks Bruno).

blocks|key|2215236|text|不，他们不是平等的，他们在记忆中有不同的表现形式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2215237|通常，当您想要比较两个浮点值时，您不能使用==+(如果是这样的话，您就不能使用术语'equals')。你应该和epsilon做比较。|2215238|double+eps+=+0.0000001;
if+(Math.abs+(Java_PI+-+Another_Pi)+<=+eps)
++System.out.println+("equals");|code-block|syntax|javascript|2215239|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

No, they aren't equal, they have different presentation in memory.

In general when you want to compare 2 floating point values you mustn't use == (and if so you can't operate with termin 'equals'). You should use comparison with epsilon.

<pre><code>double eps = 0.0000001;
if (Math.abs (Java_PI - Another_Pi) &lt;= eps)
 System.out.println ("equals");
</code></pre>

blocks|key|686262|text|一双只有大约52位的意义，所以我认为这只给你大约15基数10位，这就解释了为什么当你要求20位数时，你有5个零。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|686263|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

a double only has like 52 bits of signficand so i think that only gives you around 15 base 10 digits which would explain why you have 5 zeroes when you ask for 20 digits.

blocks|key|2215293|text|注意以下几点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2215294|这两个数字与小数点16位相同。差不多是48位，是一样的。|2215295|在IEEE+64位浮点数中，所有的位都不是符号或指数。|2215296|#define+M_PI有21位数字，这大约是63位精度，这对于IEEE+80位浮点值是很好的。|offset|length|style|CODE|2215297|我认为您看到的是M_PI值中的位的普通截断。|2215298|entityMap^0|0|0|0|0|C|0|8|4|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@$H|T|I|U|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@$H|W|I|X|J|K]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|O|$]]

Note the following.

The two numbers are the same to 16 decimal places. That's almost 48 bits which are the same.

In an IEEE 64-bit floating-point number, that's all the bits there are that aren't signs or exponents.

The <code>#define M_PI</code> has 21 digits; that's about 63 bits of precision, which is good for an IEEE 80-bit floating-point value.

What I think you're seeing is ordinary truncation of the bits in the <code>M_PI</code> value.

blocks|key|686348|text|即使初始值是相同的，也很难计算相同的值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|686349|浮点计算结果有时因体系结构而异(例如x86/PowerPC+)，从编译器到另一个编译器(例如GCC/MS+C%2B%2B)，甚至使用相同的编译器，但编译选项不同。不总是，但有时(通常在四舍五入时)。通常情况下，这个问题已经足够了，直到太晚才被注意到(想一想，经过多次迭代，还有许多四舍五入的差异)|686350|这使得跨平台多人游戏很难同步计算游戏状态的每一次迭代(每个节点只接收输入，而不是实际的数据结构)。|686351|因此，即使在同一语言(C/C%2B%2B)中，结果也可能不同，从Java到本地主机也可能有所不同。|686352|更新：|686353|我找不到我读过的资料来源，但我找到了一个关于这个问题的孙先生的论文。|686354|就像你自己回答的那样，java.lang.Math.PI和GCC的M_PI可以被管理成具有相同价值的。魔鬼隐藏在这些价值观的使用中。IEEE没有指定数学函数的输出(sin、cos、exp、.)。因此，计算的输出不一定相同。|686355|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.sun.com/source/806-3568/ncg_goldberg.html#3098^0|9|B|0|0|40|0|0|1D|0|0|19|0|0|3|0|0|Y|R|6|0|0|0|33|0^^$0|@$1|2|3|4|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@$9|1H|A|1I|1|1J]]|E|$]]|$1|P|3|Q|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|1N|8|@]|D|@]|E|$]]]|S|$T|$5|U|V|W|E|$X|Y]]]]

It would be very difficult to compute the same value, even if the starting values are the same.

Floating point computation results are sometime different from an architecture to another (think x86/PowerPC for example), from a compiler to another (think GCC/MS C++) and even with the same compiler, but different compilation options. Not always, but sometimes (usually when rounding). Usually just enough for the problem to go unnoticed until too late (think after many many iterations, and many many rounding differences)

This make it quite difficult for cross-platform multi-player games that compute each iteration of the gamestate synchronously (each node only receives the input, not the actual data structures).

Therefore if even in the same language (C/C++) results can be different, from a Java VM to a native host it may also be different.

Update: 

I cannot find the source I read, but I found a <a href="http://docs.sun.com/source/806-3568/ncg_goldberg.html#3098" rel="nofollow noreferrer">paper by Sun</a> on the matter.

Like you answered yourself, java.lang.Math.PI and GCC’s M_PI can be managed to have the same value. The devil hides in the usage of these values. IEEE doesn't specify the output of math functions (sin, cos, exp, ...). Therefore it's the output of the computation that isn't necessarily the same.

blocks|key|876669|text|您可以使用BigDecimal来获得更高的精度，例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|876670|private+static+final+BigDecimal+PI+=+new+BigDecimal(
"3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679"+%2B
++++"8214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196"+%2B
++++"4428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273"+%2B
++++"7245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094"+%2B
++++"3305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912"+%2B
++++"9833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132"+%2B
++++"0005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235"+%2B
++++"4201995611212902196086403441815981362977477130996051870721134999999837297804995105973173281609631859"+%2B
++++"5024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303"+%2B
++++"5982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989"+%2B
++++"3809525720106548586327886593615338182796823030195203530185296899577362259941389124972177528347913151"+%2B
++++"5574857242454150695950829533116861727855889075098381754637464939319255060400927701671139009848824012"+%2B
++++"8583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912"+%2B
++++"9331367702898915210475216205696602405803815019351125338243003558764024749647326391419927260426992279"+%2B
++++"6782354781636009341721641219924586315030286182974555706749838505494588586926995690927210797509302955"+%2B
++++"3211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000"+%2B
++++"8164706001614524919217321721477235014144197356854816136115735255213347574184946843852332390739414333"+%2B
++++"4547762416862518983569485562099219222184272550254256887671790494601653466804988627232791786085784383"+%2B
++++"8279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863"+%2B
++++"0674427862203919494504712371378696095636437191728746776465757396241389086583264599581339047802759009"+%2B
++++"9465764078951269468398352595709825822620522489407726719478268482601476990902640136394437455305068203"+%2B
++++"4962524517493996514314298091906592509372216964615157098583874105978859597729754989301617539284681382"+%2B
++++"6868386894277415599185592524595395943104997252468084598727364469584865383673622262609912460805124388"+%2B
++++"4390451244136549762780797715691435997700129616089441694868555848406353422072225828488648158456028506"+%2B
++++"0168427394522674676788952521385225499546667278239864565961163548862305774564980355936345681743241125"
);

public+static+void+main(String...+args)+throws+InterruptedException+{
++++System.out.println("PI+to+"+%2B+PI.scale()+%2B+"+digits+is+"+%2B+PI);
++++System.out.println("PI%5E2+to+"+%2B+PI.scale()+%2B+"+digits+is+"+%2B+
++++++++++++PI.multiply(PI).setScale(PI.scale(),+BigDecimal.ROUND_HALF_UP));
}|code-block|syntax|javascript|876671|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

You can use BigDecimal for more accuracy like:

<pre><code>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));
}
</code></pre>

blocks|key|876757|text|带回了在fortran中必须得到pi值的记忆。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|876758|由于没有常量库，所以我要么使用4*atan(1)。或acos(-1.)|876759|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Brings back memories of having to get a value for pi in fortran.

Since there were no libraries of constants, I either used
4*atan(1.) or acos(-1.).

I am coding several reference algorithms in both Java and C/C++. Some of these algorithms use &pi;. I would like for the two implementations of each algorithm to produce identical results, without rounding differently. One way to do this that has worked consistently so far is to use a custom-defined <code>pi</code> constant which is exactly the same in both languages, such as 3.14159. However, it strikes me as silly to define pi when there are already high-precision constants defined in both the Java and GCC libraries.

I've spent some time writing quick test programs, looking at documentation for each library, and reading up on floating-point types. But I haven't been able to convince myself that java.lang.Math.PI (or java.lang.StrictMath.PI) is, or is not, equal to M_PI in math.h.

GCC 3.4.4 (cygwin) math.h contains:

<pre><code>#define M_PI 3.14159265358979323846
 ^^^^^
</code></pre>

but this

<pre><code>printf("%.20f", M_PI);
</code></pre>

produces

<pre><code>3.14159265358979311600
 ^^^^^
</code></pre>

which suggests that the last 5 digits cannot be trusted.

Meanwhile, Javadocs say that java.lang.Math.PI is:

<blockquote>
 The <code>double</code> value that is closer than
 any other to pi, the ratio of the
 circumference of a circle to its
 diameter.
</blockquote>

and

<pre><code>public static final double PI 3.141592653589793d
</code></pre>

which omits the questionable last five digits from the constant.

<pre><code>System.out.printf("%.20f\n", Math.PI);
</code></pre>

produces

<pre><code>3.14159265358979300000
 ^^^^^
</code></pre>

If you have some expertise in floating-point data types, can you convince me that these library constants are exactly equal? Or that they are definitely not equal?

Is java.lang.Math.PI equal to GCC's M_PI?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在用Java和C/C++编写几个参考算法。其中一些算法使用π。我希望每种算法的两个实现都能产生相同的结果，而不会有不同的舍入。到目前为止，实现此操作的一种方法是使用自定义的pi常量，这在两种语言中都是完全相同的，比如3.14159。然而，当Java和GCC库中已经定义了高精度常量时，我觉得定义pi是愚蠢的。我花了一...

问java.lang.Math.PI等于GCC的M_PI吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java.lang.Math.PI等于GCC的M_PI吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java.lang.Math.PI等于GCC的M_PI吗？
EN