PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Konvertierung FP16 -> FP32 und reverse


aths
2003-12-09, 09:48:19
Was ist die gültige Methode?

Angenommen ich habe eine normalisierte Mantisse von

01 1100 0011

Bei FP32 hat man 23 Bit dafür. Die ersten Stellen sind klar:

01 1100 0011

Doch wie geht es weiter? Mit 0 auffüllen, oder so lange das Muster von vorne wiederholen, bis die Stellen voll sind? Demzufolge:

011 1000 0110 1110 0001 1011

Wenn man "wieder von vorne" auffüllt, wird dann gerundet oder abgeschnitten? Wäre die 24. Stelle durch die "Auffüll-Methode" eine 1, wird die restliche Mantisse dann aufgerundet?




Wenn man aus FP32 dann FP16 macht, wird die Mantisse dann einfach abgeschnitten, oder gerundet? Falls gerundet wird, und man den Sonderfall einer Mantisse hat, die durchweg aus 1 besteht, müsste man sie ja Nullen und dafür den Exponenten inkrementieren. Wird das berücksichtigt?



edit: Mit etwas Nachdenken meine ich nun, dass beim Expandieren der Mantisse in ein größeres Format das Auffüllen mit Nullen eigentlich nicht falsch sein kann. Oder habe ich da was übersehen?

zeckensack
2003-12-09, 18:02:11
IMO sollte man bei Vergrößerung (der Präzision) mit Nullen auffüllen, und umgekehrt runden.

Das ganze ist im von dir genannten Extremfall erst nach einer Konvertierung von FP16=>FP32 reversibel, dafür liefert die Konvertierung in ein höher aufgelöstes Format exakt die gleiche Zahl.

Die andere Alternative wäre Wiederholung des Bitmusters und Abschneiden. Dieses Verfahren ist nach dem ersten Konvertieren in das geringer aufgelöste Format reversibel.

Was genau jetzt gemacht wird, oder gar 'richtig' ist ... keine Ahnung :grübel:

Jedoch sollte man nicht Bitmuster wiederholen und runden. Dann würde man riskieren, daß bei wiederholter Konvertierung (FP32=>FP16=>FP32=>FP16=>FP32 ...) die Zahl immer größer wird.

aths
2003-12-10, 05:28:04
Hmm hmm hmmmm: Ich hab jetzt selbst einen Gedankenknoten. Was sind mögliche Vorteile beim Wiederholen der Bits im Gegensatz zum Auffüllen mit 0? Wenn die Mantisse so normiert wäre, dass 11111111... = 1,0 entspräche (mit führender 1,0 dann = 2,0) dann sollte man wohl in jedem Fall mit Wiederholung auffüllen, anstatt mit 0. Aber so?

Bei FP32->FP16 würde man mit Bit-abschneiden ja die Zahl tendenziell kleiner machen, und dann bei FP16->FP32 durch Auffüllen per Wiederholung wieder vergrößern.

Alternativ könnte man bei FP32->FP16 die Mantisse runden, und bei FP16->FP32 mit 0 auffüllen. Was ist nun "richtiger"? Nach meinem Gefühl die zweite Variante.


Ich möchte mal, wenn sich die Zeit findet, eine FP16-Klasse schreiben. Gerechnet wird aber mit FP32 (à la CineFX.) Da muss ständig konvertiert werden, die Konvertierung sollte möglichst "stabil" sein, der Rundungsfehler minimal.

Per Konstruktor soll man Anzahl der Bits für den Exponenten und den Bias für den Exponenten angeben können. Denormalisierte Mantissen werden grundsätzlich unterstützt. Nach außen "kommuniziert" wird über float. Ich weiß noch nicht, was sinniger ist: Bei jeder Zuweisung intern ein float zu halten, was aber künstlich ungenau gemacht wurde, so dass es exakt der FP16-Zahl entspricht, und die FP16-Zahl als Bitfolge nur auf Anfrage (extra zusammengebastelt) auszugeben. Oder in der Tat ein bitweises FP16 draus machen, und vor jeder Operation neu zu einem float zu basteln. Ich müsste noch prüfen, ob man jedes denkbare FP16-Format (z.B. s13e2, oder s2e13) mit denormalisierter Mantisse noch exakt als float speichern kann.

Hm hm, ist überhaupt jede s2e13-Zahl als float darstellbar? Wohl nicht :( Muss ich wohl die FP16-Typen auf einige vordefinierte Formate beschränken... da wäre FP16-Standard mit s10e5 und Bias von -15, und FP16 à la aths mit s11e4 und Bias von -7, und und FP16 à la aths reloaded mit s10e5 und Bias von -21.

ScottManDeath
2003-12-10, 15:13:05
im cgshaders.org forum hat mal einer vom nvidia demo team deren fp16tofp32 /reverse code gepostet, ich hab gesucht, bis jetzt noch nicht gefunden.......

ich würde eher eine konverterklasse bauen die nur arrays von float32 in alle formate konvertiert und umgekehrt falls das ganze nicht nur "proof that possible" sein soll

aths
2003-12-11, 08:25:29
Wäre toll, wenn du die offizielle Variante findest :)

Meine Klasse soll Objekte ermöglichen, mit denen man direkt rechnen kann. Zunächst wird das etwa so aussehen:

fp16 a,b,c;

a.setvalue(3.1f);
b.setvalue(4.12f);

c.setvalue(a.getvalue()+b.getvalue());

Später will ich die ganzen Operatoren überladen, so dass direkt möglich wird:

fp16 a=3.1f, b=4.12f, c=a+b;