Frage zu Floating-point dateintypcodierung. (Sowie carry-flags u. Byte-enable)

lk

Hi.

Ich check nicht, wie genau die Mantisse aussieht:

* Im binärformat hat zB(immer da wo die 1 ist) 1.0 einen stellenwert von 1. 10.0 einen stellenwert von 2, 100 einen von 4, 8,16,32,... . Dagegen hat 0.1 einen stellenwert von 0.5, 0.01 einen von 0.25, 0.001 einen von 0.125 ?! Wenn man nur ganz wenige bits an matisse bereit hat, kann man ja zahlen mit sehr wenig genauigkeit codieren ?! (und wie soll man das überhautpt verschieben?). (--> Bei zahlen Z<1.0)

* Die mantisse muss ja normalisiert sein. WARUM ?! Macht das keine benachteiligungen und bringt gar nichts? Wenn man eine sehr kleine Zahl darstellen will, muss man viele stellen im exponent daran verbraten, die zahl zu normalisieren (0.00..01(e=0) --> 1.0(e=x) ) ?! (kurz: warum müssen zahlen normalisiert sein ?

EDIT * (Ist die mantisse bei zB 1.0 '1000' oder '0001' ?)

EDIT2 * --> http://en.wikipedia.org/wiki/Denormal_number (zu #1)

EDIT3 * --> Siehe unten für zwei weitere fragen zu carry-flags und Byte-enable signalen.

CStoll

Das System funktioniert wie bei der wissenschaftlichen Darstellung von Zahlen - anstatt 1000000000000000000000000000000 schreibt man wesentlich kürzer 1e30 (bzw. 1*10³⁰). Der Unterschied ist nur, daß die Gleitkommadarstellung auf Binärzahlen basiert.

krümelkacker

Ja, 100,0₂ = 2² = 4 und 0,01₂ = 2^-2 = 1/4 = 0,25. Das ist eigentlich nichts besonderes. Statt Zehnerpotenzen sind's eben Zweierpotenzen. Das gilt sowohl für positive als auch negative Potenzen.

Deine Frage bzgl Genauigkeit / Verschieben habe ich nicht verstanden. Kannst Du das umformieren / erklären, was Du damit meinst bzw was genau Du wissen willst?

Bzgl Normalisierung:
100,0₂ * 2² = 10,0₂ * 2³ = 1,0₂ * 2⁴
Normalisiert ist die Darstellung dann, wenn nur eine einzige Ziffer (ungleich 0) vor dem Komma auftaucht. Das praktische bei der Binärdarstellung ist, dass die einzige Ziffer ungleich 0 die 1 ist. Deswegen braucht die führende 1 bei normalisierten Zahlen auch gar nicht mit abgespeichert werden. Warum macht man das jetzt so? Weil man damit eine höhere Genauigkeit erreichen kann. Für quasi jede Float-Zahl gibt es so genau ein eindeutiges Bitmuster, statt mehrere -- zumindest für die Werte, die ungleich 0, Infinity, NaN sind.

lk

@krümel: ..und was ist mit dem abbilden des Z<1.0 bereiches? 0.00..01

otze

1+e-30

krümelkacker

lk schrieb:

@krümel: ..und was ist mit dem abbilden des Z<1.0 bereiches? 0.00..01

Du kannst jede positive Zahl darstellen als
1,restlichemantisse...₂ * 2^exponent,
auch 0,0001₂.

hustbaer

lk schrieb:

* Die mantisse muss ja normalisiert sein. WARUM ?!

Weil's beim Rechnen ungemein hilft, wenn man weiss dass die Zahl immer mit 1, anfängt.

lk

krümelkacker schrieb:

lk schrieb:

@krümel: ..und was ist mit dem abbilden des Z<1.0 bereiches? 0.00..01

Du kannst jede positive Zahl darstellen als
1,restlichemantisse...₂ * 2^exponent,
auch 0,0001₂.

... ?!

@hustbear: also verliert man gezielt an genauigkeit um schneller zu sein. ok.

EDIT: Zwei weitere fragen tuen sich auf. zwar nichtmehr mit float zahlen zu tun, aber...

Byte-enable signale.
### reading
BE3=1 BE2=0 BE1=1 BE0=1
`this: 11 00 22 33

or: 11 22 33 00`

### writing
BE3=1 BE2=0 BE1=1 BE0=1
(writing value=0x112233 onto addr=0x1000)
` addr: +0 +1 +2 +3

before: 0x1000: ** ** ** **

this: 0x1000: 33 ** 22 11

or: 0x1000: 33 22 11 **`

Das carry/overflow flag bei multiplication
Ich habe a=0xee und b=0xef.
c = a*b = 0xde32
Da müsste doch das carry-flag 233 betragen ?!

Michael E.

lk schrieb:

@hustbear: also verliert man gezielt an genauigkeit um schneller zu sein. ok.

Nein, man gewinnt Genauigkeit, indem man weiß, dass vor dem Komma immer eine 1 steht.

lk schrieb:

Da müsste doch das carry-flag 233 betragen ?!

Lies noch mal nach, was ein Flag ist.

krümelkacker

lk schrieb:

krümelkacker schrieb:

lk schrieb:

@krümel: ..und was ist mit dem abbilden des Z<1.0 bereiches? 0.00..01

Du kannst jede positive Zahl darstellen als
1,restlichemantisse...₂ * 2^exponent,
auch 0,0001₂.

... ?!

Du siehst wohl den Wald vor lauter Bäumen nicht. Ich habe doch auch vorher schon Beispiele gebracht. Hier ist noch eins:
0,0001₂ = **1,**0₂ * 2^-4

lk schrieb:

@hustbear: also verliert man gezielt an genauigkeit um schneller zu sein. ok.

Nein. Genauigkeit verliert man nicht. Im Gegenteil. Nochmal zum Mitschreiben: Für jede per float/double darstellbare Zahl (wir ignorieren mal 0, Infinity, NaN) gibt es bei der IEEE-754 Kodierung genau ein Bitmuster, welches diese Zahl beschreibt. Das ist gut so, weil damit möglichst viele verschiedene Zahlen dargestellt werden können und das somit die Genauigkeit erhöht.

Statt z.B. eine 4 in zig verschiedenen Darstellungen speichern zu können...

10000,0[t]2[/t] * 2[h]-2[/h]
 1000,0[t]2[/t] * 2[h]-1[/h]
  100,0[t]2[/t] * 2[h]0[/h]
   10,0[t]2[/t] * 2[h]1[/h]
    1,0[t]2[/t] * 2[h]2[/h]

wird nur eine einzige zugelassen: die mit der Mantisse 1,... (*)! Daher braucht man das führende Mantissenbit auch nicht mitspeichern und kann andere Bitmuster für andere Zahlen verwenden ==> höhere Genauigkeit. Das, was ein float/double typischerweise (IEE-754) nur speichert ist
(1) das Vorzeichen
(2) den Exponenten (impliziert führendes Bit der Mantisse)
(3) die Mantisse ohne führendes Bit

Klar soweit? Mir gehen nämlich langsam die Ideen aus, wie man das noch deutlicher erklären kann...

(*: Das führende Mantissenbit ist bei denormalisierten Zahlen 0. Das ist ein Sonderfall für betragsmäßig extrem kleine Zahlen, der typischerweise (IEEE-754) daran erkannt wird, dass das Bitmuster für den Exponenten nur aus Nullen besteht.)

http://en.wikipedia.org/wiki/Denormal_number ... ? Sagt das nicht aus, man könne nummern denormalisiert abspeichern, um ein wenig mehrere werte zu gewinnen. (beim bereich nahe der null).

? warum ?

krümelkacker

lk_nologin schrieb:

http://en.wikipedia.org/wiki/Denormal_number ... ? Sagt das nicht aus, man könne nummern denormalisiert abspeichern,

Nein. Das hast Du falsch verstanden. Der Punkt ist: Du hast gar keine Wahl, wie eine bestimmte Zahl gespeichert wird. Fast alle Zahlen können nur normalisiert gespeichert werden und ein ganz kleiner Teil kann nur denormalisiert gespeichert werden. Wie geht das? RTFwikipedia!

otze

lk_nologin schrieb:

http://en.wikipedia.org/wiki/Denormal_number ... ? Sagt das nicht aus, man könne nummern denormalisiert abspeichern, um ein wenig mehrere werte zu gewinnen. (beim bereich nahe der null).

? warum ?

Nein, es wird nur für extrem kleine Zahlen eine andere Darstellung gewählt um auch dort gültige Repräsentationen zu haben. Es wäre ja immerhin auch schon die Zahl 0 darstellen zu können, denn ist in der Darstellung 1.xxx*10^y schlicht nicht enthalten. Es gibt dafür aber natürlich andere Zahlen die du für diese Repräsentation aufgibst und nicht mehr exakt darstellen kannst. Du gewinnst also nichts sondern schiebst nur rum.