Wettbewerb (für Anfänger und Fortgeschrittene) ?

**Mars**

Moin,
Wie der Titel schon lautet möchte ich wissen wie viele Menschen, Roboter (oder was ihr alle seid) interesse an einem (kleinen) Wettbewerb haben. Eines vorweg: Es geht hier um den Spaß an der Angelegenheit, es gibt kein Preisgeld und auch kein 2t (oder 3t) klassiges Banner zum in die Signatur kleben.

Thema:
~~Trockener Matheunterricht mit Differentialgleichungen~~. Ein Skript welches ein "Spiel" möglichst effizient spielt. (sogesehen ein Bot, in unserem Fall ist dieser aber eher mit einem Sudokulöser vergleichbar, daher gibt es keine Probleme ;)).
Das Spiel hat einen extrem einfachen Aufbau (sowohl optisch, als auch intern) und kann von jedem problemlos verstanden und gelöst werden. Es handelt sich um nebeneinander liegende Rechtecke unterschiedlicher Farbe (bei uns gibt es 7 Farben = 3 Grundfarben + 3 Mischfarben + Grau) die im Spielverlauf alle grau werden sollen. Das oberste linke Rechteck ist grau, der Rest bunt. Nun wählt man eine der 6 übrigen Farben (nummeriert von 0 bis 5) die das graue Rechteck berührt, um alle an graue Rechtecke anschließenden Farbflächen grau zu färben.

Ich glaube je mehr ich hier erkläre, desto unverständlicher wird es. Daher gibts im Anhang einen Ordner der das Spiel, und ein paar Testdateien enthält.
In der Gray.au3 (superkreativer Name) kann man in Zeile 6 auf Handbetrieb schalten, damit man das Spiel auch mal als Mensch spielen kann.
Mit der GrayContest.au3 (obacht, AutoSolve wieder auf True setzen) kann man sich einen kleinen Eindruck verschaffen wie der Vergleich (in etwa) aussehen wird.

Die beiden BeispielAIs (wenn man diese komplexen Dinger denn so nennen darf) zeigen was beim Wettbewerb von Teilnehmern erwartet wird (ps: wer diese beiden nicht schlägt möge sich einschiffen lassen)

Regelwerk:
Ich habe mir selbst schon einiges überlegt, insgesamt gilt natürlich die Mentalität.
- Es wird irgendein Zeitlimit geben um den nächsten Zug zu berechnen.
- COM, ASM, Dlls -> verboten (also keine VBS Objekte zum Geschwindigkeitcheaten)
- Das Hauptskript darf nicht verändert werden. Für den Wettbewerb werden alle Dateien außer die Einsendungen durch die Originale ersetzt
- usw.

Einen Zeitraum habe ich nicht vorgesehen, schlage aber vor irgendeine Novemberwoche zu nehmen. (selbstverständlich ist es jedem Selbst überlassen wann er etwas tut. Es gibt also keinen "Beginn", sondern nur einen Einsendeschluss)

Edit: 02.11.2014 - Version 0.2 (die alte war 0.1)
Update der Beispieldatei: Neuer Algorithmus (Knotenbasiert statt Arraybasiert)
- In vielen Fällen deutlich schneller als der alte
- Hoffentlich dieses mal auch vollständig korrekt (der alte hat öfters mal Farben nicht "gesehen" und daher falsch gearbeitet)

Edit: 06.11.2014 - Version 0.3
- Array kann nicht mehr ByRef bearbeitet werden
- Zeitmessung eingebaut
- Contestskript etwas angepasst
- Alle Globalen Variablen beginnen nun mit _gr_ oder _wb_, damit es keine Kollisionen gibt.
- OBACHT: Da alle Skripte includet werden ist es ratsam die Funktionen/Variablen irgendwie benennen, sodass Kollisionen verhindert werden. (z.B. wenn ich Käsekuchen73 heiße nenne beginnen alle funktionen/vars mit _k73_).
- Zur Namensgebung der Lösungsfunktion: Diese darf man frei benennen (muss mit korrektem Namen registriert werden). Denkt euch was Kreatives aus (mein "Kampfskript" heißt dann Marsterplan64 oder so ähnlich )

lg
Mars

**UEZ**

Wie willst du bewerten, wenn die Farben zufällig erzeugt werden?

Gruß,
UEZ

**Mars**

Ich habe mir schon gedacht, dass diese Frage kommt
Hier geht es um Wahrscheinlichkeiten. Um eine faire Bewertung zu haben müssten alle Teilnehmer die gleichen Farben bekommen. Für zufällige Farben stellt sich erst bei einem großen Stichprobenumfang ein Anständiges Ergebnis heraus.

Ich habe also 2 Möglichkeiten:
1. Viele Durchläufe (würde ich bevorzugen, da rennt der Rechner eben eine Weile)
2. Viele Durchläufe + Gleiche Farben

Ich bevorzuge Variante 1, da jeder Algorithmus (abgesehen von BruteForce) bei einigen Zufälligen Farben unterschiedlich abschneiden wird. Man hat also sowieso einen Zufall mit im Spiel. Und man sieht ja bereits bei einer Hand voll Versuche den Großen Unterschied zwischen AI1 und AI2, also denke ich, dass man bei einer Großen Anzahl Runden auch ziemlich genau sagen kann wie "gut" ein Algorithmus ist. Falls natürlich mehrere Kandidaten sehr dicht beieinander liegen (hierfür ist die StdA) werden diese nochmal gesondert betrachtet (mit mehr Durchläufen). Sollten sie dann immernoch gleichauf ein wäre es unfair den "besseren" zufällig zu bestimmen indem man beiden die gleichen 10.000 Muster vorgibt, denn villeicht wäre bei anderen 10.000 Mustern der andere vorne. In dem Fall werden sich mehrere Leute einen Platz teilen.

**UEZ**

Das habe ich mir auch gedacht, wollte aber nochmals nachfragen, damit das klar ist.

Gruß,
UEZ

**Andy**

Habe schon einige Runden "von Hand" gespielt, und natürlich schon angefangen zu "botten"

Genau wie beim Sudoku-Löser bei dem es "gute" und "böse" Sudokus gibt, ist das hier natürlich auch so!
Daher würde ich, damit alle Teilnehmer wirklich gleiche Voraussetzungen haben, auch jedem Teilnehmer eine bestimmte Anzahl Rätsel vorgeben, die der Lösungsalgorithmus dann knacken muss. Ich denke, 30 bis 50 sollten reichen.

@Mars,
beim "von Hand" spielen habe ich festgestellt, dass ab und zu zusammenhängende Farben nicht vollständig "eingegraut" werden. Bspw. wurden in einem Fall ein "Winkel" von 3 waagrechten und drei senkrechten, also 5 zusammenhängenden Flächen nicht vollständig grau. Die 3 Waagrechten wurden grau, die beiden Senkrechten blieben farbig. Seltsamerweise wurde beim nächsten Zug mit dieser Farbe wieder nicht beide, sondern auch nur ein Feld eingegraut.
Das ist mir öfter mit verschiedenen zusammenhängenden Feldern aufgefallen. Absicht ist das nicht, oder?

//EDIT
Bin zzt. bei einem 16x16 Feld bei einem Schnitt von 33 Zügen, fast so gut wie "von Hand" (nur minimal besser)
Aber die "Streuung" ist viel zu hoch, Züge von 28/29 wechseln sich mit >40 ab. Übrigens ist das bei "von Hand" ebenso!

**Mars**

Hatte den Fehler auch gerade. Interessant
Und hab ihn auch im Code gefunden. Dazu muss aber ein mittelgroßer Teil neugeschrieben werden. Das Problem ist, dass ich keine Rekursion verwenden wollte damit der Rechenaufwand beim _Apply klein bleibt. Das wirft aber das Problem auf, dass in manchen (seltenen, aber immer wieder auftretenden) Situationen Farben nicht entdeckt werden, da sie zum Zeitpunkt an dem sie überprüft werden keine Grauen nachbarn haben.
Habe aber keine Lust auf Rekursion, deshalb wird morgen eine iterative Methode gebaut. Muss den Code allgemein noch aufräumen, wir haben hier ja erstmal nur ein "konzept"

Edit: Für annähernd Zufallsverteilte Variablen gibts die Signifikanzniveauabschätzung. Soll heißen man kann den Mittelwert beliebig genau bestimmen wenn man beliebig viele Versuche hat.

Yjuq

Klingt interessant. Hab ja sowieso eine Vorliebe für solche Art an Aufgabenstellungen & Algorithmen. Klar, ich mach da auch mit. Aber jetzt erst mal Schule.

Gesendet von meinem HTC Desire HD A9191 mit Tapatalk 2

General Kaboom

Warum nicht einfach WIRKLICH ein Sudoku-Löser...dieses Spiel würde ich zumindest auf Anhieb verstehen
Naja zugegeben, morgens um 8 ist nicht gerade die Blütezeit meines Verstands

**Andy**

Zitat von General Kaboom

Warum nicht einfach WIRKLICH ein Sudoku-Löser..

Weil wir das schon hatten? µIt-März 2009
Übrigens eines meiner Lieblingsbeispiele für ASM-Programme. Ein Sudoku-Löser incl Ein- und Ausgabe in 62 (zweiundsechzig) Bytes!

Yjuq

1. Frage: Muss die KI komplett in die _Solve Funktion ausgelagert werden oder darf diese in einer eigenen UDF unterteilt werden? (Um z.B. Teilaufgaben separat auszulagern)
2. Frage: Spielt die KI später auf ein 12x12 Feld (so wie du angeben hast in der Gray.au3) oder variiert dies?
3. Frage: Wird da die benötigte Zeit der KI eine Rolle in der Wertung spielen?

Ich hoffe dass ich hier nichts überlesen habe.

**Andy**

Da die solve-Funktion sowieso in eine eigene Datei ausgelagert sein soll, ist es imho egal, ob dort noch weitere Funktionen mit drinstehen!

**Mars**

Update des Beispielskripts siehe Startpost.
Bitte mal im Manuellen Modus ein paar Spiele spielen um zu testen ob er jetzt ordentlich funktioniert. Wie Andy in Post 5 bereits gesagt hat, hat der alte Algorithmus öfters mal angrenzende Felder nicht erkannt... Das sollte jetzt besser funktionieren, mehr Augen sehen mehr, bei meinen 5 Testspielen lief jedenfalls alles tadellos.

@MG:
1. Siehe Andy (post11): Die _solveMarkeGrafik01 (so soll der Name später mal aussehen) Funktion darf aus einem beliebig komplexen Skript bestehen, es gibt keine Größenbeschränkung, allerdings muss das Skript aus einer Datei bestehen.
2. Die Größe wird variiert. Vermutlich wird es Klein (8x8), Mittel (12x12), Groß (16x16) und Riesig (24x24). Vorallem für die kleinen und Mittleren Felder kommt hier nämlich die Methode des Vorausberechnens zum Tragen (also z.B. die nächsten 3 Züge (bei sehr klein geht auch BF) berechnen). Für Große Felder wäre die Laufzeit einer Vorausberechnung viel zu groß, daher ist hier Kreativität gefragt wie man auch so ein sehr gutes Ergebnis bekommt
3. Die Zeit ist beschränkt. Wie genau diese Beschränkung aussieht kann ich leider nicht sagen, da ich bisher selbst noch keine KI geschrieben habe und nicht weiß wie schnell oder langsam sich etwas lösen lässt. Es wird aber so aussehen, dass Brute Force nicht (vollständig) genutzt werden kann. Ein kleines 8x8 Feld kann man damit ggf bis zu 3-4 Stufen vorausberechnen, für ein 16x16 Feld wird die Zeitbeschränkung das aber verhindern. Wenn man den vorgegebenen Wert nur um ein paar Prozent (evtl. 20%) überschreitet wird das keine Auswirkungen auf die Bewertung haben, so genau lässt sich meistens sowieso nicht programmieren, dass man in jeder Situation eine Zeit genau einhalten kann. Besonderst schnelle Skripte bekommen KEINEN Bonus (sonst ist man mit der Random(0, 5, 1) Funktion auf Platz 1, frei nach dem Motto: Ich rechne es zwar falsch, dafür aber verdammt schnell).

Yjuq

Danke Mars, zu der Zeitbeschränkung:
Sag bitte noch rechtzeitig bescheid wie hoch du dann das limit setzt. Je mehr zeit man hat umeo mehr schritte lassen sich logischerweise im vorraus berechnen. Ggf. wird sich mein algorithmus dann selbständig an die zeitvorgabe anpassen wenn diese als zusätzlicher parameter oder als globale Konstante definiert wird. Dh. auch meine Frage.

Gesendet von meinem HTC Desire HD A9191 mit Tapatalk 2

**Andy**

Nur mal interessehalber, wie löst ihr das Problem von "guten" (lösbar in 25 Zügen) und "bösen" (lösbar in >40 Zügen) Rätseln innerhalb von einem Set (ich löse 16x16 Rätsel)?

Ich habe 3 (einfache) Algorithmen am Start, und vergleiche diese mit je 100 Rätseln. Mal gewinnt der eine, mal der andere!
@Mars, man sollte zuerst alle Rätsel zufällig erstellen, und danach alle Algorithmen auf jeweils das gleiche Rätsel loslassen.

Yjuq

Nun ja, bei meinen Algorithmus (welcher drz. nur auf Papier existiert) versuche ich alle Möglichkeiten zu berechnen. Diese Vorberechnung wird bis zu einer bestimmten Suchtiefe (wird abhängig von der vorgegeben Zeit sein) gemacht. Dies ist wahrscheinlich der Schritt den jeder Algorithmus der bei dem Wettbewerb eingereicht wird eingesetzt wird. Allerdings versuche ich durch Analyse des Spielfeldes bestimmte Kombinationen vorab auszugrenzen. Diese Analyse ist sehr oberflächlich gehalten, das hat den Grund, dass sich der Algorithmus an diesen Schritt nicht zulange aufhält. So kann ich die Suchtiefe um einiges erhöhen. Die bereits analysierten Daten werden abgespeichert, sodass bei einem erneuten Aufruf der Funktion an der letzten Analyse angesetzt werden kann und somit die Rätsel in möglichst wenigen Zügen gelöst werden kann. Zudem lege ich zusätzlich eine Datenbank an welche für ein 3x3 Spielfeld für jede Möglichkeit den besten Weg beinhaltet. Mithilfe dieser Datenbank kann ich die Möglichkeiten auf einem größeren Spielfeld schneller abschätzen. Dabei beachte ich, dass Muster auch gedreht und gespiegelt vorkommen können, so kann ich die Datenbank minimieren. Wenn sie nicht zu groß ausfällt dann schaue ich mal ob ich das doch lieber für 4x4 Spielfelder übernehme.

So sieht zumindest meine Idee bisher aus, in wie fern sich das ganze umsetzen lässt (und vorallem zeitsparend ist) muss ich mal schauen. Ich hab da auch so ein paar Tricks und Kniffe um auch mit den Beschränkungen ordentlich Speed in mein Skript zu bekommen.

**Mars**

Das ist immer das gleiche Problem, wenn man mit Zufällen arbeitet, je größer die Stichprobe, desto besser das Ergebnis.
Ich habe mir überlegt immer 10 Versuche (je mehr, desto besser das Ergebnis) zusammenzufassen und den Mittelwert als 1 Versuch zu zählen. (ändert nichts am Ergebnis, aber die Kurve sieht wesentlich schöner aus).

Das Problem ist: Angenommen ich nehme 100 zufällig erstellte Rätsel und reiche sie an alle Algorithmen weiter, dann wird es definitiv einen Gewinner geben. Allerdings wäre ein anderer Algorithmus bei anderen 100 Versuchen eventuell der beste. Vorallem ist der Mittelwert absolut nicht aussagekräftig. Im 1 Sigma intervall befindet sich nur zu 68% Wahrscheinlichkeit der tatsächliche Mittelwert. Wenn also Algo1 25.6 (+-3) und Algo2 26.5 (+-3.8) haben ist Algo1 nur mit einer gewissen wahrscheinlichkeit besser. (liegt nahe an 50% bei den Werten) Man kann also keinen Sieger bestimmen. Daher werde ich den PC bei einem Kopf an Kopfrennen wohl einfach mal ein paar (zehn)tausender berechnen lassen, anschließend sollte die Standardabweichung so klein sein, dass ein Sieger bestimmt werden kann. Ist sie das nich wird sich ein Platz auf der Treppe geteilt

Zur Zeitbeschränkung: Jeder Computer ist unterschiedlich schnell. Daher habe ich ein kleines Skript geschrieben welches bei mir ca. 0.2 Sekunden benötigt. Mein Algorithmus ist nicht besonderst komplex, liegt aber weit unter diesem Wert, daher sollte das locker ausreichen. Ihr könnt eure Methoden ja mal ausstoppen und Vorschläge für die Zeitbeschränkung abgeben. Ich vermute, dass man in 0.2sek ein 8x8 Feld schon fast per BF lösen kann.

Spoiler anzeigen

[autoit]

ConsoleWrite(GetTime() & @CRLF)

[/autoit] [autoit][/autoit] [autoit]

Func GetTime()
Local $n = 75, $t
For $i = 0 To $n - 1 Step 1
$t += _GetTime()
Next
Return Round($t, 0)
EndFunc

[/autoit] [autoit][/autoit] [autoit]

Func _GetTime()
Local $t = TimerInit(), $v = DllStructCreate('float a[5]'), $a[] = [99,88,77,66,55,44,33,22,11], $b[16][16]
For $o = 0 To 9 Step 1
For $i = 1 To 5 Step 1
$v.a(($i)) += ($i / $a[Random(0, UBound($a) - 1, 1)])^2
Next
Next
For $x = 0 To UBound($b, 1) - 1 Step 1
For $y = 0 To UBound($b, 2) - 1 Step 1
If $x = $y Then $b[$x][$y] += (($x^2 + $y^2)^0.5 / $a[Random(0, UBound($a) - 1, 1)])
$b[$x][$y] += $v.a((Mod($x + $y, 5) + 1))
If $b[$x][$y] < 0.5 Then $b[$x][$y] = ($b[$x][$y] + $b[$y][$x]) ^ 0.5
Next
Next
Return TimerDiff($t)
EndFunc

[/autoit]

Auch hier ist die Zeit nicht bei jedem Ausführen identisch, das ist nicht weiter tragisch, da sie nur als "richtwert" gilt. Es wird niemand disqualifiziert nur weil er etwas mehr Zeit braucht.

Edit: (Für alle die noch nicht genau wissen was sie von den vielen "Zufällen" und der damit verbundenen "willkürlichen" Bewertung halten sollen)
Meine Idee für den vergleich verschiedener Funktionen kann man sich ggf nur schwer vorstellen. Daher habe ich das ganze mal in Excel eingehämmert um zu demonstrieren wie das gemeint ist:
autoit.de/wcf/attachment/24894/
Wir sehen 4 verschiedene Lösungsmethoden:
1. Der Berühmte Zufall [Rnd]
2. Die Modulomethode [Mod] (zählt einfach die Zahlen von 0 bis 5 der Reihe nach durch)
3. Testet unmittelbar angrenzende Felder und wählt die am häufigsten vorkommende Farbe [M01] (es werden keine "Flächen" sondern wirklich nur die unmittelbar zu grauen Feldern benachbarten gezählt)
4. Gleiche Methode wie [M01] nur mit einer Berechnungsebene mehr. [M02] (Berechnet also nach Schema M01 ZWEI Schritte statt nur einen)
Zum Diagramm: Die dünnen Linien zeigen die tatsächlichen Messwerte, die dicken Linien zeigen eine geglättete Version.
-> Man sieht: M01 und M02 überschneiden sich deutlich. In vielen Fällen ist also M01 "besser" als M02. Anhand der Kurve sehen wir aber, dass M02 im Prinzip einen Vorsprung von Durchschnittlich (ca.) 3 Besitzt. OBACHT: Die angewendete Methode benutzt bereits Mittelwerte aus 10er Paketen. Das heißt, dass die einzelnen Mittelwerte nicht sehr aussagekräftig sind, würde man über 100er Pakete Mitteln sähe das Bild eventuell etwas klarer, aber immernoch ähnlich aus.
Dieses Schema zeigt die Methode nach der bewertet wird.

Yjuq

Zitat von Mars

[...] Meine Idee für den vergleich verschiedener Funktionen kann man sich ggf nur schwer vorstellen. [...]

Deine Idee muss man nicht verstehen oder? Das Excel Diagramm hat mich ehrlich gesagt viel mehr verwirrt als wie es eigentlich helfen sollte.
Also, du vergleichst die Mittelwerte und die Streuung, derjenige der dann die geringsten Werte hat wird Sieger. So richtig?

Vielleicht sollte ich mir mal die Mathematik dahinter angucken.

**AspirinJunkie**

Zitat von Mars

Vorallem ist der Mittelwert absolut nicht aussagekräftig. Im 1 Sigma intervall befindet sich nur zu 68% Wahrscheinlichkeit der tatsächliche Mittelwert. Wenn also Algo1 25.6 (+-3) und Algo2 26.5 (+-3.8) haben ist Algo1 nur mit einer gewissen wahrscheinlichkeit besser. (liegt nahe an 50% bei den Werten) Man kann also keinen Sieger bestimmen.

Dafür gibt es statistische Tests.
Wie man an deiner Grafik sehen kann, handelt es sich bei deinen ermittelten Mittelwerten um zufallsverteilte Werte.
Die Frage die sich hierbei stellt ist: Kann die Differenz zwischen den beiden Mittelwerten aus deren Zufallsverteilung erklärt werden oder ist dies so unwahrscheinlich, dass eine systematische Ursache der Grund hierfür ist?
Diese Frage kann über statistische Tests fundiert aufgelöst werden.
Für den Fall, dass es sich um zwei normalverteilte Werte handelt welche verglichen werden sollen, kommt der Zweistichproben-t-Test in Frage.
Ist deren Standardabweichung nicht gleich (über F-Test ermitteln) nimmt man den Welsh-Test.
Liegt außerdem keine Normalverteilung vor (z.B. über Shapiro-Wilk-Test testbar), dann weicht man auf nichtparametrische Tests, wie dem U-Test, aus.

Da hier aber gleich mehrere Stichproben verglichen werden sollen, müsste man wegen des Alpha-Kumulierungsfehlers aber eventuell noch die Anova bzw. den Kruskal-Wallis-Test bei Varianzinhomogenität oder den U-Test als nichtparametrische Alternative, in Betracht ziehen.

**Andy**

Zitat von AspirinJunkie

Für den Fall, dass es sich um zwei normalverteilte Werte handelt welche verglichen werden sollen, kommt der Zweistichproben-t-Test in Frage.
Ist deren Standardabweichung nicht gleich (über F-Test ermitteln) nimmt man den Welsh-Test.
Liegt außerdem keine Normalverteilung vor (z.B. über Shapiro-Wilk-Test testbar), dann weicht man auf nichtparametrische Tests, wie dem U-Test, aus.

Da hier aber gleich mehrere Stichproben verglichen werden sollen, müsste man wegen des Alpha-Kumulierungsfehlers aber eventuell noch die Anova bzw. den Kruskal-Wallis-Test bei Varianzinhomogenität oder den U-Test als nichtparametrische Alternative, in Betracht ziehen.

Urgs...
Ich kaufe ein e und lege einfach fest, dass gefälligst nicht statistisch so lange schöngerechnet werden soll, bis irgendein vorausgesagtes Ergebnis eintritt, sondern dass es einen Satz von Rätseln gibt, welcher von allen Algorithmen gelöst wird. Der Algorithmus mit der niedrigsten Anzahl Züge gewinnt.
Statistik nur noch für optische Spielereien (Diagramme usw) erforderlich!

Yjuq

Soa, ein Abgabetermin steht noch nicht fest oder?
Ich wollte mal ein kurzes Statement abgeben und hoffe von der Konkurrenz ein wenig zu erfahren.

Habe bisher nur meine Analyse Funktion komplett umgesetzt (kurze & schnelle Analyse des Spielfeldes → Sprich, keine Vorausberechnung an möglichen Zugkombinationen) und konnte dies schon als „eigene“ KI umsetzen. Meine Analyse bringt mich bei 2x 500 Spielen auf einem 8x8 Spielfeld auf folgende Ergebnisse:

Durchschnittliche Züge: 14.542 und 14.630 → 14.586 Züge
Bei der Streuung: 1.73962311353761 und 1.797654896317

Hier noch ein paar Werte für 16x16 Felder:

Spoiler anzeigen

Code

_SolveMake|28.7|1.88856206322871|30|24|30|29|29|29|28|28|31|29
_SolveMake|28.6|2.50333111406915|27|33|28|30|27|28|24|31|28|30
_SolveMake|27.8|2.39443799947573|31|31|25|30|27|27|25|28|25|29
_SolveMake|28|3.33333333333333|26|27|26|29|30|32|24|23|33|30
_SolveMake|29.8|2.48551358430763|28|29|30|32|27|27|34|30|28|33
_SolveMake|27.9|3.17804971641414|30|26|22|25|30|30|29|26|28|33
_SolveMake|27.9|3.41402336775183|28|26|29|24|35|28|25|25|32|27
_SolveMake|26.2|2.25092573548455|29|26|28|30|25|24|27|25|23|25
_SolveMake|27.3|2.49666444147653|31|28|28|22|30|27|25|28|27|27
_SolveMake|29.6|3.68781778291716|29|31|29|32|21|31|34|29|27|33

Ich denke für den Anfang ist das ein gutes Ergebnis. Lässt sich bestimmt noch verbessern.
Wie sieht's bei euch aus? Nur dass man mal so einen groben Messwert hat und man weiß wie hoch die Messlatte gesetzt ist.

Wettbewerb ? 7