Math "pow" in Java und C# zurück etwas andere Ergebnisse?

Question

Ich portiere Programm von C# nach Java. Ich habe eine Tatsache konfrontiert, dass

Java

Math.pow(0.392156862745098,1./3.) = 0.7319587495200227 

C#

Math.Pow(0.392156862745098, 1.0/3.0) =0.73195874952002271 

diese letzte Ziffer, um einen ausreichenden Unterschiede führen in weiteren Berechnungen. Gibt es eine Möglichkeit, C# 's Powder zu emulieren?

Thanx

Answer 1

Nur um zu bestätigen, was Chris Shain schrieb, bekomme ich die gleichen Binärwerte:

// Java 
public class Test 
{ 
    public static void main(String[] args) 
    { 
     double input = 0.392156862745098; 
     double pow = Math.pow(input, 1.0/3.0);    
     System.out.println(Double.doubleToLongBits(pow)); 
    } 
} 

// C# 
using System; 

public class Test 
{ 
    static void Main() 
    { 
     double input = 0.392156862745098; 
     double pow = Math.Pow(input, 1.0/3.0);    
     Console.WriteLine(BitConverter.DoubleToInt64Bits(pow)); 
    } 
} 

Ausgabe von beiden: 4604768117848454313

Mit anderen Worten sind die doppelten Werte genau das gleiche Bitmuster und alle Unterschiede, die Sie sehen (vorausgesetzt, Sie erhalten die gleichen Ergebnisse), sind auf Formatierung anstatt auf einen Unterschied im Wert zurückzuführen. By the way, ist der genaue Wert dieses Doppels

0.73195874952002271118800535987247712910175323486328125 

Jetzt lohnt es sich unter Hinweis darauf, dass deutlich seltsame Dinge in Gleitkomma-Arithmetik passieren können, vor allem, wenn Optimierungen ermöglichen 80-Bit-Arithmetik in einigen Situationen, andere aber nicht, usw.

Wie Henk sagt, wenn ein Unterschied in den letzten ein oder zwei Problemen Sie Probleme verursacht, dann ist Ihr Design gebrochen.

Answer 2

Wenn Ihre Berechnungen auf diese Art von Unterschied empfindlich sind, dann werden Sie andere Maßnahmen müssen (ein Redesign).

Answer 3

Sowohl Java als auch C# geben eine IEEE-Gleitkommazahl (speziell eine Doppel) aus Math.Pow zurück. Der Unterschied, den Sie sehen, ist fast sicher auf die Formatierung zurückzuführen, wenn Sie die Zahl als Dezimalzahl anzeigen. Der zugrunde liegende (binäre) Wert ist wahrscheinlich der gleiche, und Ihre Mathe-Probleme liegen woanders.

Answer 4

Gleitkommaarithmetik ist inhärent ungenau. Sie behaupten, dass die C# -Antwort "besser" ist, aber keiner von ihnen ist so genau. Zum Beispiel Wolfram Alpha (die in der Tat sehr viel genauer ist) gibt diese Werte:

http://www.wolframalpha.com/input/?i=Pow%280.392156862745098%2C+1.0+%2F+3.0%29

Wenn eine Einheit Unterschied in der 17. Stelle wird später Berechnungen verursacht schief gehen, dann denke ich, dass es ein Problem mit Ihrem Mathe, nicht mit Java-Implementierung von pow. Sie müssen darüber nachdenken, wie Sie Ihre Berechnungen so umstrukturieren, dass sie sich nicht auf so kleine Unterschiede verlassen.

Answer 5

diese letzte Ziffer führt zu einer ausreichenden Unterschiede in weiteren Berechnungen

das unmöglich ist, weil sind sie die gleiche Anzahl.A double hat nicht genug Präzision, um zwischen 0.7319587495200227 und 0.73195874952002271 zu unterscheiden; sie sind beide vertreten als

0.73195874952002271118800535987247712910175323486328125. 

Der Unterschied die Rundung ist: Java wird mit 16 signifikanten Stellen und C# 17 verwendet Aber das ist nur ein Display Problem.

Answer 6

Siebzehn Ziffern Präzision ist die besten jeder IEEE Gleitkommazahl, unabhängig von der Sprache tun kann:

http://en.wikipedia.org/wiki/Double-precision_floating-point_format