Uncategorised

Sieger Programmierwettbewerb 2015-16

Der "Fix it."-Termin des diesjährigen Programmierwettbewerbs fand am 18.3. statt. An diesem Abend wurden die eingesandten Fälle aus der "Break it."-Phase veröffentlicht. Für alle Teilnehmenden bestand für einen begrenzten Zeitraum die Möglichkeit das eigene Programm so zu korrigieren, dass es möglichst viele der Fehlerfälle korrekt behandelt. Im Anschluss gab es wie auch während des ersten Termins eine Pizza-Pause, die das Organisations-Team für die Auswertung und eine Umfrage zum Wettbewerskonzept nutzte, um in Anschluss die Sieger zu küren.

Die folgende Tabelle zeigt die Preisgelder aller Teams. Die Bewertung setzt sich hierbei aus den Leistungen der "Build it."- und "Fix it."-Phase (Spalte Build it.) zusammen, in denen effizientes Programmieren belohnt wurde. In der "Break it."-Phase bestand das Ziel in der Erstellung von Eingabedaten, die bei einer möglichst großen Anzahl von Programmen in verschiedenen Fehler-Äquivalenzklassen zu fehlerhaften Ausgaben führte. Das Team mit der besten Leistung wird jeweils mit 100% geführt. Die Tatsache, dass eine gute Platzierung in der Gesamtauswertung auch durch gute Leistungen in nur einer der beiden Kategorien erreicht werden kann, zeigt, dass verschiedene Ansätze zum Erfolg führen können.

Team Build it. Break it. Preisgeld (€)
getrekt 100% 1 84% 2 124
builditbreakit2016 68% 5 100% 1 116
mathedual-wettbewerb-2016 75% 4 53% 3 85
eldorandev 96% 2 15% 6 71
pizza_funghi 50% 8 46% 4 65
programming-contest 62% 7 29% 5 60
buildbreakfix 80% 3 12% 7 58
mpw0xf 75% 4 0% 8 46
break_this 67% 6 0% 8 42
mathedualkrusebengsch 50% 8 0% 8 31
lebu 50% 8 0% 8 31
wettbewerb-16 34% 9 0% 8 21
no_more_names_please 0% 10 0% 8 0

Mit dem "Fix it."-Termin geht der diesjährige Programmierwettbwerb nach neuem Konzept zu Ende. Wie erwartet haben wir an einigen Stellen noch Verbesserungspotential entdeckt (z.B. bei der endgültigen Auswertung oder der Beantwortung von Rückfragen im laufenden Wettbewerb). Unter dem Strich freuen wir uns über das erhaltene positives Feedback sowie die Ankündigungen erneut teilzunehmen. Aus Sicht des Organisations-Teams steht fest, dass das neue Konzept zum einen durch die Vorbereitungsarbeiten im Team und zum anderen durch die Interaktion bei den Veranstaltungsterminen sehr viel Spaß gemacht hat. Wir bedanken uns bei allen Teilnehmenden für ihr Engagement und das Feedback und freuen uns schon auf den nächsten Mathe-dual e.V.-Programmiertwettbewerb mit euch!

Am 26.2.2016 hat am späten Nachmittag bis in den Abend hinein die Build It-Phase des Programmierwettbewerbs 2016 stattgefunden. Mit über 30 Teilnehmenden in mehr als 10 Teams wurde nach der Klärung organisatorischer Fragen der Wettbewerb gestartet und vier Aufgaben zeitlich versetzt ausgegeben. Während der Wettbewerbsphase wurde in zwei Programmiersprachen (Java, C#) versucht innerhalb der kurz bemessenen Zeit korrekte Lösungen zu erstellen. Begleitet wurde das Programm von Fragen, die das Organisationsteam für alle Teilnehmenden beantwortete, sowie reichlich Verpflegung (Getränke und Süßigkeiten), vor der Ausgabe der dritten Aufgabe wurde eine Pizzapause eingelegt. Zum Ende des ersten Teils wurde alle eingesandten Lösungen nach der Abgabe direkt auf Funktionsfähigkeit mit dem Basisbeispiel getestet, um eine Minimalfunktionalität sicherzustellen. Die Teilnehmenden wurden anschließend in die Break it-Phase entlassen und werden am 18.3.2016 wieder für den Fix it-Termin im IT Center erwartet.

Programmieren

Pizza-Pause

 

Der Mathe-dual e.V. hatte für Mittwoch, den 3. April 2024, 16:45 - 18:15 Uhr, in das IT Center der RWTH Aachen zu einem Vortrag über Virtual Reality (VR) eingeladen.

Die Vortragenden vom Lehrstuhl für Hydrologie, dessen Leiter Prof. Nacken Rektoratsbeauftragter für die digitale Transformation in der Lehre, ist stellten zuerst

 

zeigen die MyScore Software zum Avatar-basierten Lehren und Lernen in VR. Sie gehen dabei auf die Hintergründe ein, aus denen sie die Plattform entwickelt haben. Sie machen eine kleine Live-Tour und erklären dann alle nötigen Schritte, die es braucht, um eine solche Anwendung zu realisieren. Dabei wollen sie einerseits das Potenzial der Software für das Lernen an sich beleuchten, aber, speziell für MATSEs, natürlich auch den Bereich der Softwareentwicklung erörtern. Schließlich benötigt man in den verschiedenen Schritten diverse Kompetenzen von der Konzeptionierung über das Design, die 3D-Modellierung bis hin zur effizienten Programmierung und der Verschaltung der verschiedenen Assets in Unity.

Wir freuen uns auf Ihren Besuch!

  • Muss die Programmiersprache wieder Java sein?
    • Nein. Die Sprache kann frei gewählt werden, da Ergebnisse unabhängig von der verwandten Programmiersprache eingeliefert werden.
  • Dürfen nur MATSE teilnehmen oder auch Leute aus anderen Bildungsgängen?
    • Es sollen grundsätzlich MATSE-Auszubildende der aktiven Jahrgänge teilnehmen. Bei Ausnahmen gerne nachfragen.
  • Wie erhält man Zugang zu dem git-repo?
    • Nach dem Kickoff ist eine Teilnahme am Wettbewerb einfach durch eine E-Mail mit folgenden Informationen an Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! möglich:
      • Name für das Team
      • Git-ID, die nach dem Login bei https://git-ce.rwth-aachen.de angezeigt wird. Nach einem Klick links oben auf das Icon wird die ID im erscheinenden Dropdown unter ihrem Namen (@...) angezeigt.
    • Sobald möglich erhalten Sie dann den Zugang zum Repository.
  • Mehrere Fragen:
    • Dürfen Bibliotheken verwendet werden (die bei dem Lösungsansatz unterstützen und nicht die Lösung generieren)?
    • Darf Künstliche Intelligenz verwendet werden zum generieren von Inhalten (z.B. ChatGPT)?
    • Darf man eine eigene KI auf das Problem trainieren, welche die Lösungen dann nach Training berechnet?
      • Antwort zu allen Fragen: Grundsätzlich gibt es da erst einmal keine Einschränkungen. Natürlich heißt das nicht, dass am Ende alles erlaubt ist. Also wenn dadurch ein ungewöhnlich hoher Wettbewerbsvorteil gegenüber den anderen Teams tatsächlich entstanden ist, dann müsste man das im Einzelfall klären.
  • Die Nachbarschaftsbeziehungen sind bei fast allen Testfällen abweichend von der Aufgabenstellung doppelt genannt. Warum ist das so und wie gehe ich damit um?
    • In den meisten Input-Dateien (außer „Deutschlands_Nachbarn.txt“) im git sind die Nachbarschaftsbeziehungen versehentlich doppelt angegeben, also z.B. „D NL“ und „NL D“ damit erfolgt auch die Bewertung am Ende doppelt. Um die (Bonus-)Bewertungen nachträglich nicht zu manipulieren, bleiben die doppelten Bewertungen in diesen Fällen auch erhalten. Die Input-Dateien und die Bewertung bleiben also wie zuvor (abgesehen von der geänderten Bewertungsfunktion selbst).