Ich habe Algorithmus / Berechnung in Java und Unit-Test dafür. Der Komponententest erwartet ein Ergebnis mit einiger Genauigkeit / Delta. Jetzt habe ich den Algo in .NET portiert und möchte den gleichen Komponententest verwenden. Ich arbeite mit doppeltem Datentyp.
Das Problem ist, dass Java strictfp (64Bits) für einige Operationen in der Math-Klasse verwendet. Wo .NET FPU / CPU immer verwendet (80 Bit). .NET ist genauer und schneller. Java ist vorhersehbarer.
Da mein Algorithmus zyklisch ist und die Ergebnisse aus der vorherigen Runde wiederverwendet, wird der Fehler / Unterschied / Mehrgenauigkeit zu groß. Ich verlasse mich nicht auf Geschwindigkeit (für Unit-Test). Und ich bin glücklich, .NET-Präzision in der Produktion zu verwenden, aber ich möchte die Implementierung validieren.
Betrachten Sie dies von JDK
%Vor%Ich suche nach einer Bibliothek oder Technik, um striktes FP in .NET zu verwenden. .
Präventiver Kommentar: Ich verstehe das IEEE 754-Format und die Tatsache, dass die Fließkommazahl keine exakte Dezimalzahl oder Bruchzahl ist. Kein Dezimal, kein BigInt oder BigNumber. Bitte antworte nicht so, danke.
Leider gibt es keine Möglichkeit, die FP-Strenge in C # zu erzwingen, die .Net CLR fehlt einfach die Fähigkeit, Berechnungen mit geringerer Genauigkeit als das Maximum auszuführen, das möglich ist.
Ich denke, es gibt einen Leistungsgewinn dafür - es prüft nicht, ob Sie vielleicht weniger Präzision wollen. Es gibt auch keine Notwendigkeit - .Net läuft nicht in einer virtuellen Maschine und macht sich keine Gedanken über verschiedene Fließkomma-Prozessoren.
Allerdings ist strictfp nicht optional? Könnten Sie Ihren Java-Code ohne den Modifikator strictfp ausführen? Dann sollte es den gleichen Fließkommamechanismus wie .Net
Anstatt also .Net zu zwingen, strictfp zu verwenden und zu überprüfen, dass es die gleichen Werte wie Ihr Java-Code hat, können Sie Java zwingen, strictfp nicht zu verwenden und zu überprüfen, dass es dann mit dem .Net identisch ist Code.
Ich habe dieses Thema Anfang des Jahres intensiv untersucht, um herauszufinden, ob es möglich ist, eine Multiplayer-Simulation auf Gleitkommaarithmetik in .NET aufzubauen. Einige meiner Ergebnisse können für Sie nützlich sein:
Es ist möglich, den "strikten" Modus zu emulieren, indem redundante Umwandlungen eingefügt werden überall , aber das scheint eine spröde, C # -spezifische und langweilige Lösung zu sein.
Der 32-Bit-JIT gibt x87-Befehle aus, aber der 64-Bit-JIT gibt SSE-Befehle aus. Dies gilt sowohl für die Implementierung von Microsoft als auch von Mono. Im Gegensatz zu x87 ist die SSE-Gleitkommarechnung reproduzierbar .
Ich glaube, System.Math ruft einfach die entsprechenden C-Laufzeitfunktionen auf, obwohl ich nicht in der Lage war, in die Assembly zu treten, um dies zu überprüfen (wenn jemand weiß, wie das geht, bitte überprüfen!). Die C-Laufzeit verwendet SSE-Versionen von transzendentalen Funktionen, wenn möglich, außer in einigen wenigen Fällen, insbesondere sqrt (aber das Schreiben eines Wrappers über Instrinsics ist dafür trivial). Aufgrund der Natur von SSE müssen diese reproduzierbar sein. Es ist programmatisch möglich zu bestimmen, ob die C-Laufzeit eher ihre SSE-Implementierung verwendet als x87 .
Für die verbleibenden transzendentalen Funktionen, die in SSE nicht verfügbar sind (fmod, sinh, cosh, tanh), kann es sein, dass sie keine Reproduzierbarkeitsprobleme verursachen, wenn keine weitere Operation an x87 mit ihrem Ergebnis ausgeführt wird.
Kurz gesagt, sollte das Festhalten an der 64-Bit-CLR das Problem für die Arithmetik lösen; Für transzendentale Funktionen sind die meisten bereits in SSE implementiert und ich bin mir nicht einmal sicher, ob das notwendig ist, wenn Sie mit den Ergebnissen keine x87-Arithmetik durchführen.
Tags und Links java .net floating-point