Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
AuD Übungsblatt 2
Erste Aufgabe Nr. c, kann mir da irgendjemand weiterhelfen? Was um alles in der Welt ist der “Entscheidungsgehalt” bei Aufgabe c? Steh hier irgendwie völlig auf dem Schlauch :huh:
Der Entscheidungsgehalt H ist einfach die Anzahl an Bits die du ->mindestens<- brauchst um eine bestimmte Zahl darzustellen.
Also wenn du die Zahl 5 im Dezimalsystem darstellen musst, nimmst du 3 Bits, weil die Zahl 5 im Binärsystem 101 ist. Würdest du 4 Bits nehmen hättest du ein überflüssiges Bit, also nimmst du nur 3. Und das kann man eben mit dem Logarithmus ziemlich einfach berechnen (aber aufpassen immer aufrunden!)
Hoffe das es jetzt etwas klarer ist
Auf der Folie sind doch Beispiele…
und da es keine halben Bits gibt, wird aufgerundet (das wird durch diese eckigen Klammern um log_2(n) dargestellt), falls das noch unklar war.
Das ist so nicht ganz korrekt. Das hat nämlich nicht immer etwas mit Zahlen am Hut. “Salopp” könnte man sagen: Der Entscheidungsgehalt H ist die Anzahl an Bits du du brauchst um ein Element einer Menge eindeutig zu identifizieren (Jedem element eine Kombination zuweisen).
Wenn du also die Wochentage hast, dann ist das die Menge {Mo, Di, Mi, Do, Fr, Sa, So} Also 7 Elemente. Du brauchst also genug Bits um 7 verschiedene Kombinationen hinzukriegen. Das sind in dem Fall 3.
Bei den Monaten hast du 12 Elemente in der Menge. Somit brauchst du 4 Bit.
hmm, wie stell ich das jetzt bei der Aufgabe an?! Es ist ja nach dem Entscheidungsgehalt eines Geburtsdatums in der Form TT.MM.JJJJ gefragt… Wären 5+4+14=23 bit. Wenn ich vorher allerdings nicht runde würden auch 22 bit langen…
Gut, theoretisch gibts natürlich noch viel mehr Lösungen, hätte dazu schreiben sollen das mein Beispiel dafür gilt, wenn man das Format des Datums unverändert lässt und die Menge der Jahre von 0 bis 9999 geht. Man könnte auch noch Bits einsparen wenn man ein paar Geburtsjahre weg lässt und somit die Menge verkleinert, weil man z.B. davon ausgehen kann das noch niemand im Jahr 3000 geboren wurde… Das Ganze kann man auch noch weiter verfeinern je nachdem in welchem Kontext das Datum genutzt wird…
am Ende Entscheidet ueber Sinn und Zweck des ganzen eh der Einzelfall, der Anwendung, die die Codierung benoetigt.
Wie bei den Geb-Daten. brauch ich sie nur zur Info, kann ich die gane Zahl ohne trennzeichen codieren, und mit nem Makro die Zeichen wieder in einer Tabelle einfuegen.(Weniger Speicher fuer n gegen unendlich).
Brauch ich sie als Rechengrundlage ist vielleicht die konsequente trennung in DD.MM.YYYY geschickter, auch wenn sie mehr platz benoetigt.