Längenberechnung in Aufgabe 4.4.c
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.
Übungsblatt 4 - Aufgabe 4
Beim Test der Berechnung der Länge in Aufgabe 4 sollen folgende Werte ausgegeben werden:
checking getNewLen, expected: 0.44010555504198356
checking getNewLen, expected: 0.5574103903339103
checking getNewLen, expected: 0.47781624905004605
Die Berechnung von newlen ist nach Aufgabenstellung irgendeine Funktion von oldlen und lenFactor (außer in Aufgabe f)). Offensichtlich können beim Test unterschiedliche Werte entstehen. Muss man schon bei c) getNextRandomLen() berücksichtigen oder wodurch entstehen diese Unterschiede?
wenn du die drei Zeilen vorher auch noch kopiert haettest, waere dir klar geworden, dass es sich um einen Test mit Zufall (also Teilaufgabe f handelt):
lenFactor = 0.6;
lenRandomness = 0.35;
lenRNG = new Random(4711);
...Teilaufgabe c traue ich euch ohne vorgegebenen Test zu - ihr duerft und solltet euch auch selbst Tests ueberlegen, schreiben und ausprobieren.
Danke, die Tests klappen jetzt bei a)-d) einwandfrei.
Gibt es außerdem eine Möglichkeit, Strings in Bäume umzuwandeln? Ich habe nämlich eine Vermutung, dass mein Aufruf ziemlich ähnlich zum richtigen ist, aber dann nicht funktioniert, da der Baum nicht ganz symmetrisch ist, aber sein soll.
Sehe ich das richtig, dass bei Teilaufgabe f) geprüft wird, ob der eigene zufällig generierte Baum mit dem “offiziellen”, ebenfalls zufällig generierten Baum, identisch ist? Mir ist klar, dass ein Großteil der Variationen bei der winzigen Auflösung verschwindet, trotzdem verwirrt mich das. Zumal die 2 auskommentierten Codeschnipsel darunter beide so aussehen wie sie sollen.
Edit: Ja, ich habe auch einige eigene Tests gemacht, die alle so liefen wie es sein sollte. Zumindest so wie ich denke dass es sein soll. Sah aber plausibel aus.
Nein, ausser du schreibst dir eine. Warum brauchst du die denn? Ist der linke/rechte Baum wie auf dem Aufgabenblatt?
TL;DR: lass dich nicht verwirren.
Du hast keinen echten Zufall, sondern nur einen sogenannten Pseudozufallszahlengenerator. Dieser wird mit einem sogenannten seed initialisiert. Wenn man immer das gleiche seed nimmt, kommt die gleiche Folge an Pseudozufallszahlen raus. Das Verhalten wird dadurch also wieder deterministisch und laesst sich testen.
Sehr schoen - ihr duerft auch eure Tests hier sharen - sofern kein Loesungscode drin vorkommt.
Selbst der erste Baum gibt bei mir im String irgendeinen Fehler aus und ich frage mich, ob das ein Rekursionsfehler ist (falsche Abbruchbedingung, falscher Aufruf?) oder ob da die neuen Winkel falsch berechnet wurden (Symmetrieprobleme).
Alle Tests von a)-d) und f) funktionieren mehr oder weniger. Der linke Baum sieht ähnlich aus wie auf dem Aufgabenblatt, der rechte überhaupt nicht.
So wie ich das verstanden habe, muss man in e) Folgendes machen:
- Test auf Abbruchbedingung
- Zeichnen der Linie nach Berechnung von xNeu und yNeu
- Berechnung der neuen Werte von x, y, len, angle
- Rekursionsaufruf für alle Branches
Ich vermute, der Fehler liege irgendwo in der Abbruchbedingung oder bei der Winkelberechnung, aber wo genau, weiß ich nicht. Und auf Rundungsfehler bei der Winkelberechnung könnte ich das nur testen, wenn ich den richtigen Baum irgendwie ausgeben könnte.
edit: Als String mit Kommata und Leerzeichen bekomme ich Folgendes heraus:
{21, 4, 1, 3, 2, 3, 5, 1, 1, 1, 1, 2, 3, 1, 40, 6, 1, 3, 1, 2, 1, 1, 6, 3, 4, 1, 1, 2, 37, 1, 2, 5, 1, 3, 1, 4, 5, 9, 37, 1, 1, 14, 1, 1, 5, 1, 7, 3, 37, 8, 3, 1, 2, 5, 2, 1, 8, 1, 37, 1, 1, 7, 1, 3, 1, 1, 1, 4, 3, 1, 9, 1, 34, 1, 1, 11, 1, 1, 2, 1, 2, 2, 2, 1, 46, 2, 1, 4, 1, 4, 1, 3, 1, 1, 2, 1, 1, 1, 47, 2, 3, 1, 1, 2, 1, 4, 4, 1, 1, 2, 46, 5, 1, 2, 1, 1, 1, 4, 6, 3, 48, 1, 1, 2, 1, 1, 1, 1, 2, 11, 48, 1, 1, 2, 1, 3, 1, 2, 1, 2, 7, 1, 48, 9, 2, 1, 1, 1, 8, 1, 45, 1, 1, 10, 1, 1, 1, 1, 8, 1, 46, 5, 1, 1, 1, 1, 1, 3, 2, 1, 8, 1, 45, 4, 1, 7, 3, 1, 8, 1, 43, 4, 1, 1, 1, 3, 1, 7, 9, 1, 44, 7, 2, 5, 1, 1, 9, 1, 43, 1, 2, 5, 3, 2, 2, 2, 10, 1, 43, 4, 1, 12, 9, 1, 43, 5, 1, 2, 1, 1, 4, 1, 2, 2, 8, 1, 40, 8, 1, 1, 1, 1, 3, 1, 5, 2, 6, 1, 42, 9, 2, 2, 8, 3, 4, 1, 40, 1, 1, 5, 1, 2, 1, 1, 13, 2, 2, 1, 40, 1, 1, 7, 1, 1, 16, 2, 1, 1, 40, 9, 1, 1, 17, 29, 13, 9, 2, 1, 13, 3, 1, 1, 38, 8, 1, 1, 1, 1, 2, 1, 9, 3, 3, 1, 41, 1, 1, 2, 1, 1, 1, 1, 1, 1, 3, 1, 6, 2, 6, 1, 40, 1, 1, 1, 1, 4, 3, 2, 2, 1, 2, 3, 7, 1, 42, 2, 1, 14, 10, 1, 42, 1, 1, 11, 1, 2, 10, 1, 41, 9, 1, 6, 1, 1, 10, 1, 43, 4, 1, 2, 1, 5, 2, 1, 9, 1, 43, 1, 1, 2, 1, 2, 1, 2, 1, 2, 3, 1, 9, 1, 45, 4, 1, 4, 2, 1, 1, 1, 9, 1, 47, 7, 3, 1, 1, 1, 9, 1, 47, 1, 1, 7, 1, 1, 1, 1, 8, 1, 46, 5, 1, 2, 1, 6, 8, 1, 48, 2, 3, 4, 1, 11, 48, 1, 1, 1, 2, 11, 4, 3, 49, 13, 1, 2, 1, 3, 1, 1, 11, 1, 38, 9, 1, 1, 2, 6, 1, 1, 9, 1, 38, 1, 1, 7, 3, 2, 1, 4, 2, 1, 9, 1, 1, 1, 38, 1, 1, 7, 1, 5, 1, 1, 3, 1, 7, 3, 42, 11, 2, 1, 4, 1, 4, 7, 40, 8, 2, 1, 2, 1, 5, 4, 3, 1, 41, 6, 1, 1, 1, 1, 5, 1, 5, 3, 5, 1, 42, 2, 3, 1, 1, 1, 4, 2, 4, 1, 1, 1, 1, 2, 1, 2, 42, 1, 1, 1, 2, 1, 3, 1, 1, 2, 1, 3, 2, 1, 1, 1, 3, 5, 20}
Das sieht ganz gut aus. Vielleicht zeichnest du auch zu wenige, zu viele Ebenen. Ueberleg dir mal, wieviele Striche insgesamt gezeichnet werden in Abhaengigkeit von branches und steps.
Man muss, so wie ich verstanden habe, branches^i nehmen und über den Index i summieren, wobei i von 0 bis steps läuft.
Für den Fall branches=4, steps=5 funktioniert es weder bei 341 (=1+4+16+64+256) noch bei 1365 (=341+1024) Strichen.
@meisterT, vielleicht eine blöde Frage, aber fragen kostet ja nix. Wäre es möglich, dass $jemand einen “Screenshot” bzw. einfach eine Bitmap der zu vergleichenden Zeichnung hochlädt? Wäre um einiges einfacher für die Fehlersuche wie mit diesem konfusen toString().
Hab meinen Fehler gefunden, war tatsächlich einfach die falsche Anzahl von Strichen. Bei mir funktionierts mit 341.
Dann stimmt bei mir irgendeine Berechnung nicht und ich vermute wie gesagt eine falsche Winkelberechnung. Hast du in jedem Aufruf von angle eine Konstante abgezogen und dann in einer Schleife immer eine andere Konstante mal den Iterationsindex draufaddiert?
Ich hab was abgezogen, ja. Ich bin mir aber nicht ganz sicher was du mit Konstante meinst. Und ja, das draufaddieren kam auch vor.
Abgezogen habe ich die Hälfte des Gesamtwinkels, draufaddiert die Winkeldifferenz.
Das machst du aber in verschiedenen Methoden, oder?
Du berechnest einmalig [m]startAngle[/m] in [m]recursiveArt[/m]. Die Veraenderung des Winkels abhaengig vom [m]startAngle[/m] erfolgt dann in der Methode [m]getNewAngle[/m].
Nachdem du es offenbar jetzt richtig hast: do it!
Es spricht nichts dagegen, fuer die vorhanden Testfaelle Ergebnisse zu teilen, bzw. sich neue Testfaelle auszudenken, die und deren Ergebnisse zu teilen (sofern kein Loesungscode geteilt wird).
Fuer die zwei auskommentierten Testfaelle stehen euch ja schon Bilder der Baeume bereit. Fuer den ansprochenen konfusen String gilt: der ist der rechte Baum in abgespeckter, kleinerer Form.
So oder so funktioniert es nicht. Bedeutet “einmalig” komplett einmalig oder einmalig pro Schleifendurchlauf?
edit: Wahrscheinlich bedeutet das einmal pro Schleifendurchlauf, aber in beiden Fällen funktioniert es nicht.
einmalig meint einmalig pro [m]recursiveArt[/m], d.h. vor deiner Schleife. Der [m]startAngle[/m] veraendert sich ja nicht. Er steht fuer den Winkel des “linkesten” Strichs auf der naechsten Ebene, der Zwischenwinkel ist dann [m]angleDiff[/m]. Auch der muss nur einmalig pro [m]recursiveArt[/m] berechnet werden.
Ich habe es genau so implementiert, aber es funktioniert immer noch nicht. Ich glaube, ich sollte am besten den Codeteil an Sie per PN schicken, denn alles Andere habe ich probiert. Es würde mich nicht wundern, wenn ich irgendeinen Aufgabenteil überlesen habe.
edit: Ich bin den Rechnerübungen gegenüber eher skeptisch, denn ich habe in GdI damals zu viele Plagiatsfälle erlebt. Aber danke für die Tipps.