Eigentlich wollte ich die Größenoptimierung erreichen, aber stattdessen kam eine bessere Laufzeitoptimierung heraus. Es ist unnötig X in Zeile 17 auszugeben, wenn ich den Wert in Zeile 20 wieder brauche. Also lösche ich Zeile 16 und stelle die OUTBOX nach hinten.
134 Schritte!Immer noch zwei Befehle zu viel. Mir ist aber keine Möglichkeit aufgefallen, wie ich das vorhandene Programm weiter kürzen kann.
Geändert von Torin (17. März 2017 um 20:53 Uhr)
Zu deiner Lösung:
Achtung Spoiler:
Haja, die Tücken des Programmierens.Zitat von Torin
Es reicht immer noch nicht. In beiden Kategorien fehlt uns nur eine Einheit!
Beim Multiplikationsworkshop ist das ein typischer Anfängerfehler.
Aber gerade deswegen macht es ja so viel Spass und es ist extrem befriedigend, wenn man erstmal draufkommt.
Hint:
Achtung Spoiler:
Fibonacci. Da hatte ich mal keinen PC bereit und hab das mit Zettel und Bleistift ausgetüftelt.
Kommentare erscheinen zuerst unnötig, aber sobald es komplexer wird oder man ein Programm länger nicht bearbeitet, ist es gut, wenigstens ein paar Hinweise zu haben. Ging mir zumindest so.
Von welchem Level sprichst du?Zu deiner Lösung:
Ich versteh Schritt 2 nicht. Wieso kopierst du die Zahl aus der Inbox auf den Boden? Die ist doch vollkommen irrelevant?Der Sinn aller Level ist es doch die Werte aus der Inbox zu verarbeiten, wie kann diese dann irrelevant sein?
Wenn du dich auf Zeile 14 beziehst: Hier wird nicht auf die Kachel, sondern von der Kachel kopiert. Ansonsten würde der Angestellte eine Null ausgeben.
Von welchem Level sprichst du?
Wenn du dich auf Zeile 14 beziehst: Hier wird nicht auf die Kachel, sondern von der Kachel kopiert. Ansonsten würde der Angestellte eine Null ausgeben.Schritt 2, copyto Y. Die 20 ist ja völlig unerheblich für die Zahlen der Fibonacci-Reihe.
Beim anderen Beispiel hab ich mich in der Zeile verschaut, passt schon.
Die Zahl aus der Inbox muss gespeichert werden, sonst kann man später nicht anhand dieser feststellen bis zu welcher Zahl die Fibonacci-Reihe erstellt werden muss. Vielleicht meinst du man könnte das Programm im Vorraus auf die Werte in der Inbox anpassen, da diese ja sichtbar sind. Doch solch eine Lösung wird nicht akzeptiert, es würden dann sofort neue Werte in der Inbox erscheinen, die das Programm nicht richtig verarbeiten kann.
Ja, an die letzte Zahl hatte ich nicht gedacht.
Wichtig ist der Hinweis, dass es keine leeren Ketten geben wird. Also können wir getrost die erste Inbox aufnehmen und zwischenspeichern. Ab der zweiten Inbox muss dann überprüft werden, ob nun die abschließende Null aufgenommen wurde. Ist dies der Fall, wird der zwischengespeicherte Wert als kleinste Zahl in die Outbox gegeben.
Nun überprüfen wir per Subtraktion, ob die neue Zahl aus der Inbox kleiner ist als die bereits gespeicherte. Zuerst realisiere ich das darüber, dass der Kleinste-Zahl-Kandidat ebenfalls auf den Boden gespeichert wird.
Nachdem das Programm erfolgreich durchläuft und nur einen Befehl von der Größenoptimierung entfernt ist, fällt mir auf, das der Kandidat gar nicht zwischengespeichert werden muss, sondern nach der Subtraktion wieder per Addition hergestellt werden kann. Das spart ein Befehl und neun Schritte, Optimierung abgeschlossen.
Die Aufgabe wird durch Subtraktion gelöst. Erstmal speichere ich beide Zahlen auf den Boden.
Der Rest vom Programm ist schnell fertig. Wir nehmen die erste Zahl in die Hand und ziehen so oft die zweite Zahl ab, bis wir im negativen Bereich landen. Danach wird einmalig die zweite Zahl addiert und wir haben den Restwert, der auch gleich zur Ausgabe landet.
Dann lassen wir den Angestellten loslegen und es scheint alles wie gewünscht zu funktionieren.
Beide Optimierungsziele unterschritten!
Drei Optimierungen stehen derweil noch aus, aber ich mach erstmal weiter.
Fangen wir mit den Beschriftungen und ersten Schritten an. Eine Null aus der Inbox kann gleich zur Outbox weitergeleitet werden, ansonsten müssen wir ein bisschen rechnen. Also muss die eingehende Zahl gespeichert werden und die Summe wird initialisiert.
Solange das Ding - wie es so schön in der Aufgabenstellung benannt wurde - nicht Null beträgt, wird der Wert der Summe aufaddiert und anschließend wird das Ding um Eins vermindert. Am Ende wird die Summe ausgegeben.
Das Programm läuft erfolgreich, muss aber noch optimiert werden.
So entferne ich Zeile 6. Wenn ich BUMP benutze, habe ich den Wert sofort auf der Hand und muss diesen nicht nochmal aufnehmen.
Das allein reicht natürlich noch nicht.
Ich komme zur Erkenntnis, dass die vorgegebene Null gar nicht notwendig ist. Aber sie darf gerne als Gast bleiben.
Also speichern wir den eingehenden Wert auch gleich in die Summe und stellen die Berechnung entsprechend um.
Berechtigungen
Zitieren
