AuD Übungsblatt 2

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:


Vorlesung: Kapitel 1, Punkt 1.3 Daten.
Da wirst du fündig.

http://www2.cs.fau.de/teaching/WS2010/AuD/slides/secure/aud-01.pdf


Naja, das kenn ich schon, war ja auch in der Vorlesung, kann aber irgendwie absolut nichts damit anfangen :-/ . Ein Beispiel wäre echt hilfreich… :slight_smile:


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 :slight_smile:


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.

Grüße,
F


super vielen Dank :slight_smile:


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…


rundest du jedes einzelne oder addierst du die logarithmen und rundest erst dann?

Überleg dir das korrekte anhand der logarithmus rechenregeln


naja … ne andere lösung wäre die anzahl der möglichen tage (grob) auszurechnen … und sich garnicht mit dem datumsformat rumzuschlagen …


23 bit passt schon. mit der formel kommt auch nichts anderes raus.


sicher?


wenn ich die Logarithmen erst addiere und dann runde komm ich auf 22. Das ist ja die Krux dabei :slight_smile: Wär’s egal würde ich mich nicht damit rumschlagen g

Leider weiß ich gerade nicht, was die Logarithmus Rechenregeln an meinem Dilemma ändern würden :frowning:


Dann schreib mal das Datum 31.12.9999 in Binär um, das dürfte dein Problem beantworten :slight_smile:


Nein, das Problem bleibt bestehen. Prinzipiell ist beides richtig, man muss es nur sauber begründen, wie man auf das Ergebnis kommt.


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…


Nein ich gehe schon von der Aufgabenstellung aus, das Problem bleibt trotzdem bestehen. Überlege dir folgendes:

Wieviele verschiedene Daten gibt es insgesamt?

Wieviele verschiedene Tage + wieviele verschiedene Monate + wieviele verschiedene Jahre gibt es insgesamt?

It’s all about encoding.


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.


Na dann wart ich mal ab, wie die offizielle Lesart der Aufgabenstellung ist :slight_smile: Danke an alle!