21.7    Mathe bitte strikt * 

Bei der Berechnung mit Fließkommazahlen schreibt die Definition des IEEE-754-Standards vor, wie numerische Berechnungen durchgeführt werden. Damit soll die CPU/FPU für float und double mit 32 bzw. 64 Bit rechnen. Auf der PC-Seite kommen Intel und AMD mit internen Rechengenauigkeiten von 80 Bit, also 10 Byte, zum Zuge.[ 279 ](Dieses Dilemma betrifft aber nur 80x86- und andere CISC-Prozessoren. Bei RISC sind 32 Bit und 64 Bit das Übliche. ) Die 80-Bit-Lösung bringt in Java zwei Nachteile mit sich:

• Diese Genauigkeit kann Java bisher nicht nutzen.

• Wegen der starren IEEE-754-Spezifikation kann der Prozessor weniger Optimierungen durchführen, weil er sich immer eng an die Norm halten muss. Das kostet Zeit. Gegebenenfalls sehen aber die mathematischen Ergebnisse auf unterschiedlichen Maschinen anders aus.

 

21.7.1    Strikte Fließkommaberechnungen mit strictfp 

Damit zum einen die Vorgaben der IEEE-Norm erfüllt werden und zum anderen die Geschwindigkeit gewährleistet werden kann, lässt sich der Modifizierer strictfp einsetzen – so geht die JVM bei Operationen strikt nach der IEEE-Norm vor. Wir nennen das FP-strikt. Ohne strictfp (wie es also für die meisten unserer Programme der Fall ist) nimmt die JVM eine interne Optimierung vor. Nach außen bleiben die Datentypen 32 Bit und 64 Bit lang, das heißt: Bei den Konstanten in double und float ändert sich nichts. Zwischenergebnisse bei Fließkommaberechnungen werden aber eventuell mit größerer Genauigkeit berechnet.

Der Modifizierer strictfp lässt sich an unterschiedlichen Stellen einsetzen: an Klassen, Schnittstellen oder Methoden, aber nicht an einzelnen Variablen. Ist ein Typ oder eine Methode strictfp, dann ist alles innerhalb des Typs oder der Methode FP-strikt.

 

21.7.2    Die Klassen Math und StrictMath 

Für strikte mathematische Operationen gibt es eine eigene Klasse: StrictMath. An der Klassendeklaration für StrictMath lässt sich ablesen, dass sich alle Methoden an die IEEE-Norm halten.

Listing 21.15    java.lang.StrictMath.java, StrictMath

public final strictfp class StrictMath {

 // ...

}

Allerdings gibt es nicht zwei Implementierungen der mathematischen Methoden – einmal strikt und genau bzw. einmal nicht strikt, dafür potenziell schneller. Bisher delegiert die Implementierung für Math direkt an StrictMath:

Listing 21.16    java.lang.Math.java, Ausschnitt

public final strictfp class Math {

  ...

  public static double tan( double a ) {

    return StrictMath.tan( a );

    // default impl. delegates to StrictMath

  }

  ...

}

Die Konsequenz ist, dass alle Methoden wie Math.pow(double, double) strikt nach IEEE-Norm rechnen. Das ist zwar aus Sicht der Präzision und Übertragbarkeit der Ergebnisse wünschenswert, aber die Performance ist nicht optimal.