Das Floating-Point-Format im Detail

Teil 2 von 3 / 8. März 2004 / von aths / Beispiel 3

   Gradual Underflow

Diese Zahl soll gespeichert werden. Wir können nur begrenzt genau speichern, weil die Mantisse auf 10 Bit begrenzt ist. Das ist üblicher, unvermeidlicher Genauigkeitsverlust.

So sollte es normalerweise aussehen: Wir speichern im Exponenten, um wieviele Stellen das Komma verrückt wurde. Dazu suchen wir das erste Auftreten einer binären 1. Diese erste 1 wird nicht mitgespeichert, da "eh klar" ist, dass sich dort eine 1 befindet (der Exponent gibt ja normalerweise an, wo die erste 1 auftritt). Die Mantisse ist bei FP16 auf 10 Binärstellen begrenzt, das haben wir blau umrandet.

Doch einen Exponenten von "-18" kann man mit FP16 nicht darstellen, der kleinste ist -14. Die 4 dazu noch fehlenden Nullen müssen wir selbst in die Mantisse einfügen (14 + 4 = 18). Bei der denormalisierten Mantisse gilt keine führende "1," sondern eine "0,". Das ist unsere erste Null, drei weitere folgen. Leider fallen "hinten" dafür 4 Binärstellen heraus: Wir verlieren Genauigkeit. Im Fehler-Diagramm war auch schön zu sehen, dass im Denorm-Bereich der relative Fehler besonders groß ist.

Die betragsmäßig kleinste FP16-Zahl mit Denorms ist schnell ermittelt: -14 ist der kleinste logische Exponent. Bei der 10-Bit-Mantisse setzen wir nur das letzte Bit, wodurch wir den Exponenten praktisch um 10 weitere Stellen verschieben. 2^-(14+10) = 2^-24 = 1 / 2^24 = 0,0000000596... Bei einer "Round to Nearest"-Methode werden Zahlen kleiner 0,0000000298 auf Null gerundet, womit es dann zum Underflow kommt.

Das ist bei numerischen Anwendungen übrigens ein Problem, wenn es zum Underflow kommt, denn die Null hat grundlegend andere Eigenschaften, als eine Zahl ungleich Null. Im CPU-Bereich kann man dieses Problem durch die Konfiguration der Rundungsregeln in den Griff bekommen können (was allerdings neue Probleme aufwirft). Im Grafik-Bereich muss man mit "round to nearest" leben, und einen Shader schlicht entsprechend gründlich austesten.