FAQ (bzw. Fragen, die wahrscheinlich noch kommen werden) === (und Klarstellungen zu Aufgaben) letzte Aktualisierung: 2010-05-25 21:25 1. Hilfe 2. Eingabe und Ausgabe 3. Newline am Ende der letzten Zeile 4. Newlines am Ende der Einreichungen 5. Compilerwarnungen 6. Argumente an den Interpreter 7. Argumente für den Compiler 8. Sprachwahl 9. Klarstellung Aufgabe 1: Leere Zeilen 10. Klarstellung Aufgabe 5: Rundung 11. Externe Programme 12. Klarstellung Aufgabe 4: Ende des Verlaufes 13. Klarstellung Aufgabe 7: Länge der Eingabe 14. Newlines am Ende der Ausgabe -------------------- 1. Hilfe Bei Fragen oder Unklarheiten entweder per Mail oder im IRC melden: irc.euirc.net, Channel #codegolf. 2. Eingabe und Ausgabe Die Eingabe erfolgt grundsätzlich per stdin. Also quasi so als wenn wir die Tests alle von Hand eingeben würden. Tun wir nicht, wir behelfen uns mit sowas: ./programm < test.in > test.out Bzw. für Sachen, die einen Interpreter brauchen (Java, C#, Skriptsprachen, ...): java X < test.in > test.out (Sorry, das ist auf der Webseite kaputt gegangen.) Sowas könnt ihr natürlich auch machen. Aber nicht die Beispielausgaben überschreiben (der Ausgabedateiname sollte dann schon ein anderer sein). Für die Programme heißt das allgemein: Lesen von stdin (nicht aus einer Datei), Schreiben nach stdout (nicht in eine Datei). 3. Newline am Ende der letzten Zeile Unsere Testfälle haben *alle* ein Newline am Ende der letzten Zeile. Euer Code muss keine besonderen Maßnahmen treffen, wenn das fehlen sollte – tut es nämlich nicht. 4. Newlines am Ende der Einreichungen Wir haben beschlossen, überflüssige Newlines am Ende der Einsendungen zu ignorieren. Die Dateigrößen, die auf der Webseite auftauchen sind also potentiell kleiner als die Dateien, die ihr uns schickt. Wir haben uns dazu entschlossen, da viele scheinbar Probleme haben, überflüssige LFs am Ende der Datei zu vermeiden :-) 5. Compilerwarnungen Compiler warnen gern, wenn man Dinge so tut wie man es nicht tun sollte. Solange das Programm trotzdem funktioniert, ist uns das egal. Wenn es uns stattdessen den Computer sprengt, nicht mehr. Aber Compilerwarnungen sind beim Golfen ziemlich irrelevant :-) 6. Argumente an den Interpreter Einige Sprachen mitsamt ihrer Interpreter erlauben bestimmte Argumente, die einem das (Golf)leben einfacher machen. In diesem Falle zählen die Argumente grundsätzlich zur Gesamtlänge dazu, mit ein paar Dingen, die zu beachten sind: Länge = Quelltext + Interpretername + Argumentliste + 3 Überlegung hierbei: Der Quelltext wird ohnehin gezählt. Der Rest emuliert quasi entweder ein Shellskript, welches den Interpreter direkt aufruft perl -ne'...' bzw. den Shebang am Anfang: #!perl -n Im ersten Fall kommt der Overhead von 3 Byte durch das e und die Anführungszeichen (notwendige Escapes vom Code seien hier ignoriert), im zweiten durch #! und den Zeilenumbruch. In obigem Beispiel ergibt sich also Quelltextlänge + "perl" + " -n" + 3 = Quelltextlänge + 10 Wir hoffen, dass das so ungefähr gerecht für verschiedene Sprachen festgelegt ist. Argumente an den Interpreter, die nötig sind, um Code überhaupt erst auszuführen (java -cp ...) werden natürlich nicht gezählt. 7. Argumente für den Compiler Compilerargumente, wie sie vielleicht in Form von -lm für mathematische Funktionen in C nötig sein können, werden grundsätzlich nicht gezählt. Wenn wir hier allerdings etwas finden, was Quellcode spart, statt ihn nur zu ermöglichen, wird das eventuell noch einmal überdacht. Bis dahin bleibt das hier so bestehen. Compileroptionen wie -D als Ersatz für #define und -I als Ersatz für #include werden folgendermaßen gezählt: " -D" + Kram, der danach kommt für ein "-DFoo=Bar" werden also 3 + 7 = 10 zusätzliche Bytes veranschlagt. 8. Sprachwahl Die Sprache ist für jede Aufgabe frei wählbar. Es müssen nicht alle Aufgaben mit der gleichen Sprache gelöst werden. 9. Klarstellung Aufgabe 1: Leere Zeilen Aufgabe 1 sagt es nicht explizit, allerdings haben wir einen Testfall dafür: Leere Zeilen in der Eingabe sind erlaubt und müssen trotzdem mit einer Zahl versehen werden. 10. Klarstellung Aufgabe 5: Rundung Gerundet wird nach normaler kaufmännischer Rundung, also bei einem gebrochenzahligem Anteil < 0.5 wird abgerundet, bei ≥ 0.5 wird aufgerundet. 11. Externe Programme Für normale Programmiersprachen wird sowas wie exec nicht erlaubt. Da Shells im Allgemeinen (mit Ausnahmen) keine sonderlichen Programmierwerkzeuge haben, ist diese Beschränkung hier nicht gegeben und man *darf*, wenn man Shells zur Lösung benutzt, Programme ausführen. 12. Klarstellung Aufgabe 4: Ende des Verlaufes Es gab kleinere Verwirrungen bezüglich der Formulierung »Der Endpunkt des Verlaufes (also der Punkt, ab dem nur noch das letzte Zeichen des Verlaufes auftritt) befindet sich in einem Abstand von 35 vom Mittelpunkt des Verlaufes.« aus der Aufgabenstellung. Gemeint ist hiermit folgendes: * Der gesamte Verlauf (mitsamt dem letzten Zeichen) wird in die 35 Längeneinheiten gemappt. * Nach diesen 35 LE erscheint nur noch das letzte Zeichen. Also erscheint das letzte Zeichen des Verlaufes schon *vor* diesen 35 LE. Das Ganze geht aus den Beispielbildern zwar hervor, die Aufgabe selbst war leider etwas missverständlich formuliert. Hierfür entschuldigen wir uns noch mal. 13. Klarstellung Aufgabe 7: Länge der Eingabe Aufgabe 7 legte keine Obergrenze für die Eingabelänge fest. Dies sei hiermit nachgeholt: Es wird keine Eingabelänge (Nachricht bzw. Schlüssel) größer als 99 Byte geben. 14. Newlines am Ende der Ausgabe Die Ausgabe braucht nicht nach jeder Zeile ein LF (oder CRLF). Wir vergleichen die Ausgabe zeilenweise und für alles, was so in den letzten paar Dekaden erschienen ist, macht ein LF am Ende der letzten Zeile keinen Unterschied.