so, Einsendeschluss it vorbei und ich habe alle PNs, die bis gestern zur Deadline ankamen, gesammelt und werde nun die Auswertung machen. Geduldet euch ein halbes Stündchen, dann ist es vllt schon so weit.

edit: Ach, ist ja Sonntag, nicht Freitag. Soooorrry, ich bin noch etwas verpennt. :O

Gestern war ich unerwartet verhindert und jetzt is die Zeit ein wenig knapp. Die Ergebnisse werde ich im Laufe der Woche posten, sobald ich die Auswertung habe.
Ich halt mich ja ran.

So, der Wettbewerb ist ausgewertet. Hier mein Resüme der 10 endgültigen Einsendungen:

Die Aufgabenstellung
Für den Wettbewerb sollte eine möglichst kurze und damit effiziente Methode zum Auslesen einer bestimmten Binärstelle entwickelt und umgesetzt werden. Dieses Skript sollte den Syntax binary_check(value,powerof2:real) haben.

Problemlösung
Es gab viele Wege, eine Lösung für das Problem zu finden. Die Grundstruktur sah aber immer so aus:
1. Die Zahl aus einem binären Blickwinkel betrachten
2. Die Zahl auf dieser Ebene analysieren
3. Das Ergebnis der Analyse wiedergeben
Während 3. wohl kein Problem darstellen sollte (return-Statement), und 2. sich aus 1. ergibt, gilt das ganze Augenmerk nur dem ersten Punkt.
Um diesen binären Blickwinkel, wie ich es genannt habe, zu erreichen, war die wohl naheliegendste, die Zahl in Form eines Strings wie "010110" zu konvertieren, und dann die entsprechende Stelle zu untersuchen. Vier der zehn endgültigen Einsendungen gingen nach diesem Schema vor.
Ist der Umweg über einen String aber wirklich nötig? Wohl eher nicht. Zwei bzw. Drei Einsendung analysierten die Zahl mithilfe einer Schleife, um sich über die Anzahl der Stellen im Klaren zu werden, um dann wiederum präzise Auskunft geben zu können. Ein findiger Mathematiker hätte die Anzahl der Stellen allerdings mit dem 2er-Logarithmus bestimmen können (Agnahim hat dies in seinem ersten Anlauf getan). Nichtsdestotrotz blieb die Schleife beliebt, ob in Form eines for- oder while-Statements oder einer Verschachtelung des Skriptes in sich selbst, um sicherzugehen, dass keine höhere Binärstelle für die Bildung der Dezimalzahl verantwortlich ist (256 ist z.B. durch 2 teilbar, dennoch ist die zweite Stelle nicht 1).
Allerdings gibt es mathematische Streiche, die diesen Analysepunkt stark vereinfachen. Agnahim, der insgesamt drei verschiedene Einzeiler einsandte, löste es in seinem ersten Anlauf so:

Wie zuvor beschrieben, gibt log2(arg1) die Anzahl der Binärstellen wieder. Der >>-Operator "verschiebt" die Zahl auf Binärebene nach rechts (<< nach links). Das heißt aus die 1 aus 100(binär) wandert bei 100 >> 2 an erste Stelle, also 001. mod 2 überprüft schließlich, ob das Ergebnis dieser Rechnung eine gerade oder ungerade Zahl ist. Das erkläre ich aber später. Aber ziemlich genial, oder? Naja, ganz nett vielleicht, denn ">>" ist nur ein Binäroperator von vielen, die der GM bietet.
Unzufrieden mit ihren alleinigen Ergebnissen schlossen boxxar und Windapple sich zusammen, gemeinsam eine Lösung auszuarbeiten - da habe ich nichts gegen einzuwenden, schließlich sind sie als Mitglieder des Teams sowieso vom regulären Wettbewerb ausgeschlossen.
Sie lieferten diese Lösung:

Was geht hier ab? & vergleicht zwei Zahlen auf Binärebene. Wenn beide Zahlen an der gleichen Stelle eine 1 haben, so hat auch die Ergebniszahl an dieser Stelle eine 1. bei 10110 und 11101 wäre das Ergebnis z.B. 10100. Da argument1 allerdings eine Zweierpotenz sein muss, hat es nur an einer Stelle eine 1. Somit kann das Ergebnis nur 0 oder eine Folge aus 0 mit einer einzigen 1 sein. Dies wird mit && überprüft. && vergleicht boolesche Werte. Boolesche Werte sind 1 oder 0. Dabei wird jede Zahl außer 0 als true angesehen, die 0 selbst als false. true und false werden im GM durch 1 und 0 repräsentatiert. Dieser Vergleich über && prüft also nach, ob argument0&argument1 true ist, also ungleich 0. Dies ist aus unserer vorherigen Überlegung der Fall, wenn auf Binärebene irgendwo eine 1 vorkommt. Das script gibt somit 1 wieder, wenn (argument0&argument1) ungleich 0 ist. Sehr raffiniert.
Mit seiner dritten Lösung (die zweite folgt am Schluss) zeigte Agnahim allerdings unfreiwillig, dass man sich auch zusehr in das Kaufmanns-Und verlieben kann. Er lieferte dies:

Der erste Teil ist gleich, allerdings verzichtet er auf einen komplizierten booleschen Vergleich und fragt einfach, ob das Ergebnis größer als 0 sei. So simpel kann es dann doch sein.
Neben den Bit-Operatoren gibt es ja aber auch noch die halbwegs "normalen" Operatoren. Interessant sind da div und mod. div teilt ganzzahlig. 5 div 2 wäre z.B. 2 und nicht 2.5. mod gibt den Rest einer solchen Rechnung wieder, also 5 mod 2 wäre 1. mod hat eine unglaubliche Macht. Wenn bei einer Rechnung x mod y das Ergebnis 0 ist, können wir sicher gehen, dass x ein Vielfaches von y ist. Mit x mod 2 lässt sich übrigens untersuchen, ob x eine gerade oder ungerade Zahl ist.
Shoba arbeitete mit diesem Trick und einer interessanten Methode, sich die Bit-Operatoren zu sparen:

Durch die Integer-Division (div) mit der um 1 kleineren Zweierpotenz der zu untersuchenden Stelle verschiebt er wie Agnahim bei seinem ersten Anlauf die Binärstellen nach rechts; allerdings ohne >> zu benutzen. Mathematisch sicherlich sehr gut gedacht, aber ein Blick in die Hilfe-Datei hätte da wohl einige Kopfschmerzen vermieden.
Jetzt kommen wir auch endlich zu dem mod 2, dass bereits bei Agnahims erster Lösung auftauchte:
Warum muss die Zahl dahingehend überprüft werden, ob sie gerade oder ungerade ist? Der Grund dafür lässt sich mit einem Beispiel deutlich machen. Nach dem ersten Teil der Rechnung wäre bei 10(binär) und der Frage nach der ersten Stelle das Ergebnis 2/1, also 2. Obwohl 1 in der Zahl vorkommt (was bei 1 ja immer der Fall ist), ist seine eigene Stelle mit einer 0 versehen.
Gleiches ließe sich bei 100(binär) und 2 beobachten. Allerdings merkt man nach mehreren Testdurchläufen, dass in so einem Fall die Zahl immer zweimal oder öfters vorkommt. bei 10(binär) kommt die 1 zweimal vor, bei 1(binär) würde sie aber nur einmal vorkommen. Bei 110 (also 6) würde sie gleich sechsmal vorkommen. Schon etwas bemerkt? Immer wenn die eigene Stelle nicht 1 ist, dann kommt die Zahl gar nicht oder in einer geraden Anzahl vor (bei 1 wäre das 2,4,6,8 und so weiter). Wäre die eigene Stelle aber (auch) 1, wäre die Anzahl der Vorkommnisse dadurch automatisch ungerade. mod 2 analysiert diesen Aspekt. Wenn die Zahl durch 2 teilbar ist, also gerade ist, wird false wiedergegeben, da die eigene Stelle im Binär dann unmöglich mit einer 1 versehen sein kann. Bei einer Integer-Division mit 2 kann der Rest maximal 1 betragen, also haben wir direkt einen Wiedergabe-fähigen Wert. Das ist jetzt aber wirklich genial.
Wir haben nun bereits Lösungen gesehen, die mit einer Verschiebung (Shoba, Agna1) oder einem Vergleich arbeiteten (Wa+box, Agna3). Jürgen, der als erste einen Einzeiler präsentierte, schaffte es auf diese Variante:

Den ersten Teil kennen wir bereits. Anstatt jetzt aber mit && oder > zu arbeiten hat Jürgen eine dritte Möglichkeit gefunden, die den anderen durchaus ebenbürtig ist: Die Integer-Division. Wie wir bereits wissen, hat das Ergebnis von (argument0 & argument1) nur an einer Stelle eine 1. Dass die gesuchte Zahl mehrfach auftaucht, ist also ausgeschlossen. Entweder sie tritt einmal oder keinmal auf. div kann daher auch nur 0 oder 1 wiedergeben, und liefert damit direkt eine wahr/falsch Aussage, ebenso wie mod 2 bei der Verschiebung.
Nun folgt die letzte Lösung. Sie kann sich nicht damit rühmen, die genialste zu sein, aber sie hat doch eine Besonderheit: Sie verwendet keine Bit-Operatoren oder GM-Funktionen. Es handelt sich um die Musterlösung, die ich beim Eröffnen des Wettbewerbs bereits als Referenz in den Händen hielt (Agnahims zweite Lösung ist identisch mit dieser):

Den letzten Teil kennen wir schon. Daraus können wir folgern, dass der erste Teil eine weitere Form der Verschiebung ist. Die ganzzahlige Division überprüft, wie oft argument1 in argument 0 "hineinpasst". Vorhin haben wir bereits erleutert, wann wir eine gerades und wann ein ungerades Vorkommen von argument1 erwarten können. mod 2 prüft dies dann wie gehabt. Mathematisch gesehen hat diese Lösung, abgesehen von Shobas, am wenigsten mit einer binären Anschauung zu tun, da keine binären Operatoren verwendet werden. Sie hat deshalb ihren ganz gewissen Charme.
Ich hoffe, alle haben diese Ausführungen verstanden. Wenn nicht, fragt. Jetzt aber ersteinmal die Gewinner.

Gewinner
Tja, soviele Einzeiler habe ich ehrlich gesagt nicht erwartet. Wenn man boxxar und WA ausschließt, gibt es drei Gewinner:
Jürgen, Agnahim und Shoba.
Wenn ich diese in eine Reihenfolge bringen müsste, hätte ich meine Schwierigkeiten - außer der Zeilenanzahl habe ich wenige Entscheidungskriterien aufgezählt. Wenn wir diesen Aspekt aber einmal ignorieren, muss ich Jürgen anrechnen, dass er am schnellsten einen Einzeiler präsentierte, den er über die Woche Stück für Stück verfeinerte. Agnahim hingegen lieferte gleich drei Lösungen im Verlauf der Woche, von denen jede aus einer einfachen Sichtweise als "optimal" angesehen werden kann. Shoba fällt nur in sofern hinter den beiden zurück, weil er eine GM-Funktion benutzte (log2).
So einen Vergleich habe ich allerdings nicht anegkündigt und werde ihn deshalb auch nicht offiziell anwenden. In sofern sind diese drei die Gewinner des Wettbewerbs. Ob da noch eine kleine Überraschung rausspringt, muss ich noch mit WIN und Windapple abklären.
Aber auch die Nicht-Einzeiler verdienen ein Lob. Namentlich werde ich sie aber nicht erwähnen, damit keiner auf die Idee kommt, dass andere, die sich entschieden haben, diesen Wettbewerb zu bestreiten, es schließlich nicht geschafft haben. Die anderen können sich nach dieser Dokumentation aber selber in die Kategorien "Konvertierung zu String" oder "Stellenabzählung durch Schleife" zählen. Alle, die ein funktionierendes Skript geschrieben haben, können sich dennoch bedenkenlos als Gewinner betrachten. Vielleicht nicht als Genies in diesem einen Fall, aber als Angehörige einer klar denkenden Minderheit. Glückwunsch auch an die!
Selbstverständlich kann sich jeder, der absichtlich nicht genannt wurde, noch selber zu seiner Lösung bekennen.

Anwendung
Viele haben gefragt, was dieses Skript eigentlich effektiv bringen soll. Ich nehme einfach meine persönliche Anwendung als Beispiel:
Früher oder später reichen die normalen Tasten-Events des GMs nicht mehr aus, komplizierte Bewegungen zu organisieren. Dies passiert ganz schnell, wenn zwei gleichzeitig gedrückte Tasten eine Funktion ausschließen müssen, die eine der beiden Tasten alleine wahrnehmen würde (diagonales Laufen mit einer eigenen Animation als einfaches Beispiel).
Dies lässt sich in einem Step-Event mit keyboard_check einfach bewerkstelligen. Für press und release stehen uns auch Funktionen zur Verfügung.
Jetzt kommt aber der Knackpunkt: Was ist, wenn wir zwei Eingabe-Möglichkeiten haben, also Mehrfachtastenbelegung (durch ein GamePad z.B.)? Dann könnte es passieren, dass eine Taste 2mal hintereinander "pressed" bevor sie "released" wird. Dies kann zu ungewollten Folgen führen. Das Problem ließe sich lösen, indem man zu Beginn eines Steps alle Tasten abfragt und in Variablen speichert, wodurch man ein doppeltes Drücken entschärft (released wird z.B. nur gegeben, wenn die letzte Taste mit der gleichen Funktion losgelassen wird; bei pressed wäre es nur die erste). Nun wiederum müssen wir aber mit kleinen if-Monster kämpfen und vielen Variablen kämpfen, und das bei nur 4 Möglichkeiten pro Tasten-Funktion: Drücken, Halten, Loslassen und Ruhen. Nun bin ich auf die Idee gekommen, ersteinmal nur zwischen gedrückt und nicht gedrückt zu unterscheiden, und dies in einer Variable zu speichern, wobei jeder Tasten-Funktion eine Binärstelle zugewiesen wird. Wenn ich nun diese Variable mit der aus dem letzten Step so vergleiche...

...erhalte ich Informationen über pressed und released. Der Operator ^ liefert im Ergebnis eine 1, wenn die beiden Zahlen sich an dieser Binärstelle unterscheiden. Sonst liefter er 0. Wenn wir diese Mixtur, die also alle Veränderungen aufgezeichnet hat, mit dem jetzigen vergleichen (bitweises und &), dann erhalten wir alle neu hinzugekommenden Tasten, denn die Stellen müssen davor ja 0 gewesen sein, eine Veränderung wäre ja nur nach 1 möglich. Im Umkehrschluss lieftert uns ein ein &-Vergleich mit dem letzten Tastenwert alle Tasten, die seit dem aktuellen Step nicht mehr gedrückt, also losgelassen wurden.
Nach dieser Berechnung der gehaltenen, gedrückten und losgelassen Tasten können wir nun mit binary_check die einzelnen Positionen abfragen, die jeweils einer Tasten-Funktion zugeschrieben sind.
Aber moment, es gibt noch einen Vorteil: Dieser Tastenwert muss nicht unbedingt durch Spielereingaben gebildet werden. Er kann auch aus einer Datei ausgelesen werden oder von einer KI erstellt werden. Damit ließe sich mit nur einer Variable pro Step z.B. ein Replay machen oder eine KI, die Figuren wie ein Spieler steuert, ohne dass deren Code an andere Stelle verändert werden muss. Bei einem Prügelspiel müsste man also nur die Art der Eingabe wählen. Bei CPU generiert der Game Maker anhand von Beobachtungen diesen Tasten-Wert, sonst macht es ein Spieler über Tastatur und Gamepad. Genial? Ich hoffe doch...
Soviel zum möglichen Einsatz. Dies ginge zwar auch mit vielen Variablen, allerdings bietet es so mehr Vorteile: Nur eine Variable und wenige Zeilen Code.

Ich hoffe, ihr könnt damit etwas anfangen. Jetzt ist aus dem Wettbewerb ein Tut für Fortgeschrittene geworden, so soll es sein. Postet fleißig Feedback. Bis zum nächsten Contest.

MewX

Laut den Jux-Computergesetzen lässt sich jedes Programm um eine Zeile kürzen. Dass aus der selben Feder die Theorie stammt, dass jedes Programm mindestens einen Fehler enthält, sei dann man dahingestellt.