# Kommazahl



## javastudent25 (2. Jan 2016)

Hallo Leute
Das hat jetzt vllt. weniger mit Java zu tun, dennoch ist es eine Aufgabe, die sich mir stellt.
Ich habe nicht vor dies zu programmieren, dennoch wüsste ich gerne, was die da von mir überhaupt wollen. Ich blick das irgendwie nicht so ganz.

Aufgabe: Gesucht ist ein neuer Datentyp "small", der Kommazahlen darstellen soll. Für diesen Datentyp sthen insgesamt 8 bits zur Verfügung.
Fragen:
a.) Definieren Sie, wie Sie Kommazahlen codieren wollen. Was bedeuten die einzelnen Bits?

Ich schätze mal ich nehme die Bits her, setze in der Mitte ein Komma und das wars. Links davon stellen die Zahlen vor dem Komma dar. 4 Bit --> max. Zahl 15
rechts davon, die Nachkommastellen 2 hoch -1, -2, -3, -4
insgesamt gibt es halt 2 hoch 8 Kombinationen.
Liege ich richtig?

b.) Nützt man den Datenraum vollständig aus, so hat man 256 Kombinationen zur Verfügung. Wie viele unterschiedliche Zahlen stellt ihre Codierung dar?

Weiss nicht wie man das berechnet ziemlich viele zb 0, .0.75, 0.5, 0.25, 0.... dann kann man noch die Kommazahlen untereinander mit versch. Kombinationen addieren etc. und das gibt wieder eine 0,... Zahl

c.) Welchen Wertebereich stellen sie dar (kleinste/grösste Zahl herausfinden)

Ich denke mal max. 15 und min 0 unsigned..

d.) Welches ist der kleinste Abstand zwischen zwei Zahlen. Welches der grösste

Hmm, der kleinste 2 hoch -4
der Grösste 2 hoch -1

Für Schnelle: Erstellen Sie ein Programm, das Ihnen die Werte aller Codierungen ausgibt.

Dazu gehöre ich wohl nicht 
Dazu müsste ich wissen, wie man das berechnet..

Stimmt das so bisher?


----------



## javastudent25 (2. Jan 2016)

still loking for you help guys  i've no idea if i'm right or not
das bei d.) wenn es heisst zwischen zwei, also beliebigen Zahlen, müsste demnach 15.9375-0 sein
wie rechnet man wenigstens b aus?
meine Idee: 2hoch8 Kombinationen = 2hoch8 Zahlen...
max. Zahl ist dann 15,9375


----------



## kneitzel (3. Jan 2016)

Also die wichtige Frage ist doch wirklich, welche Bedeutung die einzelnen Bits haben sollen. Schau Dir doch einfach einmal IEEE 754 an - dort werfen Gleitkommazahlen definiert: https://de.wikipedia.org/wiki/IEEE_754

Wobei eine 8Bit Fließkommazahl etwas dubios klingt. Da hat man nicht wirklich viel Spielraum für Werte. Aber evtl. ist ja genau das angedacht - da kann man dann alle Werte (256) auch einmal auflisten in einer Tabelle:
- Wert als unsigned Byte (0, 1, 2, ... 255)
- Werte für Exponent und Mantisse
- (gerundeter) Wert im Dezimalsystem

Konrad


----------



## javastudent25 (3. Jan 2016)

ich weiss was IEEE 754 ist.
die zahl 5.2 zB
ist 
5 = 101
0.2 = 0011001100110011...
101,0011001100110011... normalisiert --> 1,010011001100110011 * 2^2 

Vorzeichen 0
Bias = 129
Sprich 0 1000'0001 und 01001100110011001100110 (23Stellen)

Ich weiss nur nicht was die Aufgabe soll und was ich genau machen sollte.


----------



## kneitzel (3. Jan 2016)

Wenn Du IEEE 754 verstanden hast, dann solltest Du doch kein Problem haben, den von Dir gezeigten Prozess genau in die andere Richtung durchzuführen. Und dann solltest Du ja auch wissen, wie Du aus den jeweiligen Bits zu der Zahl kommst. (Steht ansonsten in dem Link unter "Berechnung IEEE754-Gleitkommazahl → Dezimalzahl")

Sprich: Du hast keine Dezimalzahl um dann auf irgend eine Dual-Darstellung mit zig Stellen zu kommen. Sondern Du gibst jetzt irgend ein Format vor bei dem du insgesamt 8 Bit verwendest.

Und vielleicht machst Du Dir tatsächlich einmal den Spass und schreibst die möglichen 256 Werte auf. Das könnte dem Verständnis bestimmt helfen. Zumal Du dann jede Frage durch Ablesen beantworten kannst. 

Konrad


----------



## javastudent25 (3. Jan 2016)

ok das hab ich wohl verschlafen. IEEE 754 ist die Darstellung, die bei Computern generell verwendet wird, aber Informatik ist auch nicht mein täglich Brot.
ok nehmen wir die 8 bits her
dann kann ich zu a.) sagen wenn ich zB habe 1111.1111
1 bit Vorzeichen
nächsten 3 bits Bias
danach Mantisse

wenn ich das jetzt umrechnen will in eine Zahl:
erstes Bit 0 --> positive Zahlen
Bias ist 7
7-127=-120 (Exponent)
1.111100000000000... *2^-120

meine Zahl ist dann also

Summe n=120 bis n=124 von 1/2^n = siehe Bild
damit hätten wir a.)


----------



## javastudent25 (4. Jan 2016)

wie ist das gemeint bei b, nützt man den Raum vollständig aus?
sprich kein Vorzeichenbit?


----------



## kneitzel (4. Jan 2016)

Ich verstehe das so, dass alle Bits benutzt werden. Ansonsten kommt ein Scherzkeks auf die Idee nur jeweils ein Bit nutzen zu wollen


----------



## kneitzel (4. Jan 2016)

Und was Deine Ausführung angeht: Ich denke, dass Du da ein paar Fehler drin hast.
(Ich nutze nun die Begriffe, die auch auf wikipedia verwendet wurden. Du scheinst die auch etwas durcheinander zu werfen)
Du hast als Beispiel genommen:
1 111 1111 (Ich habe es einmal aufgesplittet)
- Das Vorzeichen ist somit 1 und nicht 0 in Deinem Beispiel.
- Der "biased Exponent" ist nun 111 = 7
- Bias ist aber nicht 127 - das war da in einem Beispiel der Fall, bei dem der Exponent mit 8 Bit angegeben wurde. Hier sind es aber nur 3 bit, weshalb der Bias ein anderer ist! Mit dem richtigen Bias wirst Du den korrekten Exponent bekommen.
- Normalisierte Zahl, also kommt noch eine 1 vor das Komma. somit haben wir 1,1111
- Nun wird das Komma um die (Wert des Bias) Stellen nach rechts verschoben und wir erhalten eine neue Zahl, die wir umrechnen können. 
- Nun müssen wir nur noch das Vorzeichen berücksichtigen und schon haben wir wohl die kleinste darstellbare Zahl.

Wenn Du so ein neues Format erstellst, dann musst du sehr exakt die Umwandlungen in beide Richtungen durchgehen um sicher zu sein, dass sich eben keine Fehler eingeschlichen haben. Dazu ist extrem wichtig, dass das Verfahren im Ganzen verstanden wurde.

Konrad


----------



## kneitzel (4. Jan 2016)

Ach ja - noch zwei ganz wichtige Punkte: 
- Es gibt oft noch ein NaN Wert (bzw. zwei). Die hast Du auch noch nicht festgelegt. Daher wäre die Frage, ob Du dies auch definieren willst. Wäre dem so, dann wäre die obrige Zahl evtl. nicht einmal umzurechnen. 
- Die +/- 0 sind auch Werte, die man prinzipiell umrechnen könnte. Wieso es eigentlich keine 0 gibt wirst Du bestimmt auch verstanden haben, oder?

Konrad


----------



## javastudent25 (4. Jan 2016)

kneitzel hat gesagt.:


> Und was Deine Ausführung angeht: Ich denke, dass Du da ein paar Fehler drin hast.
> (Ich nutze nun die Begriffe, die auch auf wikipedia verwendet wurden. Du scheinst die auch etwas durcheinander zu werfen)
> Du hast als Beispiel genommen:
> 1 111 1111 (Ich habe es einmal aufgesplittet)
> ...




Stimmt offensichtlich habe ich ein paar Begriffe wirr durcheinandergeworfen.
Aber bei der Berechnung habe ich auch absichtlich von der 1 111 1111 Darstellung die postive Zahl davon berechnet, sprich 0 111 1111, im Prinzip ist das ja die Selbe Zahl, nur negativ.


----------



## javastudent25 (4. Jan 2016)

kneitzel hat gesagt.:


> Ach ja - noch zwei ganz wichtige Punkte:
> - Es gibt oft noch ein NaN Wert (bzw. zwei). Die hast Du auch noch nicht festgelegt. Daher wäre die Frage, ob Du dies auch definieren willst. Wäre dem so, dann wäre die obrige Zahl evtl. nicht einmal umzurechnen.
> - Die +/- 0 sind auch Werte, die man prinzipiell umrechnen könnte. Wieso es eigentlich keine 0 gibt wirst Du bestimmt auch verstanden haben, oder?
> 
> Konrad


Wie es gibt keine Null?
Die gibt es ja, halt doppelt.. durch das Vorzeichen oder?


----------



## kneitzel (5. Jan 2016)

Welcher Wert wäre denn +0 bzw. -0? Und wenn Du dann die Regeln der Umrechnung anwendest: Auf was für einen Wert kommst Du dann? Oder wo liegt das Problem, wenn Du die Dezimale 0 in eine duale Gleitkommazahl umwandeln willst?

Das mit der 0 ist ein Problem bei der Verfahrensweise. Aber es gibt auch ein generelles Problem der Ungenauigkeit. Das solltest Du erkennen, wenn Du Dein obriges Beispiel mit der 5,2 wieder zurück rechnest. Aber evtl. erkennst Du das Problem ja auch schon bei der Berechnung der dualen Darstellung.

Konrad


----------



## kneitzel (5. Jan 2016)

Aber ja - es gibt +0, -0 und zwei NaN Werte. Aber hier werden einfach entsprechende Werte interpretiert. Eigentlich hätten sie auch einen Wert, aber da man der Meinung war, dass man diese Werte auch darstellen möchte, wurden einfach ein paar Werte entwendet.

So müssten in deiner 8Bit Darstellung die Werte 0 000 0000, 1 000 0000, 0 111 1111 und 1 111 1111 einfach als spezielle Werte interpretiert werden. Das bedeutet dann z.B. dass die 15 und -15 nicht mehr dargestellt werden können. Und was für Werte die +0 bzw -0 bei der Umrechnung eigentlich haben wirst Du bei Deinen Überlegungen zu der vorherigen Antwort von mir ja hoffentlich ermittelt haben.

Und mit so einer Festlegung ist die große Frage, wie man die ganzen Funktionen auf dem neuen Datentypen implementiert. Diese Sonderfälle müssen dann durchaus betrachtet werden. So wirst Du die Operanden bestimmt immer erst auf Sonderfälle prüfen um eben sicher zu gehen, dass Du keine falschen Berechnungen durchführst. So prüfst Du bei einer Multiplikation, ob einer der Operanden 0 ist und gibst dann eine 0 zurück (Vorzeichen ist dann XOR der beiden Vorzeichen). Bei einer Division durch 0 wird NaN ausgegeben und bei einer Division von 0 wird wieder 0 ausgegeben mit Vorzeichen dem XOR Ergebnis der beiden gegebenen Vorzeichen. Operationen mit NaN sind nicht definiert, so dass hier ein NaN ausgegeben wird.
Das was Dir hier vielleicht auffällt: Es gibt keine Exceptions bei diesen Überlegungen. Das ist der Grund, wieso zwei Werte als NaN interpretiert werden. Nicht alle Sprachen unterstützen Exceptions und diese Datentypen gibt es auch auf CPU Ebene und da gibt es keinerlei Exceptions.

Das nur als eine kleine, einfache Ausführung von meiner Seite.


----------



## javastudent25 (6. Jan 2016)

hallo konrad 
vielen Dank fuer die Ausffuehrung.
Das muss ich uebermorgen nochmals durchlesen, wenn ich wieder fit bin. das muss ich naemlich verstehen..


----------

