{
"llm" : {
"feedback" : "# Exercise: fractal\n\n### Correctness\n- In `Boxes.drawRec` rufst du als ersten rekursiven Aufruf wieder `drawRec(g, x, y, s, n-1)` mit **denselben** `x,y,s` auf; dadurch verkleinert sich das Quadrat in diesem Ast nicht und das Muster/Abbruchverhalten passt nicht zur geforderten rekursiven Unterteilung.\n- In `Boxes.drawRec` ist der Abbruchfall auf `n == 1` gesetzt und zeichnet dabei gar nichts; bei `n == 0` wird weiterhin gezeichnet und rekursiv gegangen, was mit der typischen “Basisfall zeichnet, sonst teilt auf” Logik kollidiert.\n- In `Triangles.drawRec` ist der Abbruchfall ebenfalls `n == 1` und zeichnet dabei gar keinen Dreiecksrand; bei kleineren `n` bekommst du so ggf. keine sichtbare Ausgabe, obwohl mindestens das kleinste Dreieck gezeichnet werden sollte.\n- In `Triangles.drawRec` zeichnest du die drei Kanten in **jedem** Rekursionsschritt (auch wenn `n > 1`), nicht nur im Basisfall; das ergibt ein anderes Bild als die rekursive Unterteilung in kleinere Dreiecke, die erst im Basisfall gezeichnet werden.\n- In `Circles.drawRec` ist der Abbruchfall `n == 1` und zeichnet dabei keinen Kreis; damit fehlt auch hier der kleinste Kreis als Basis.\n- In `Circles.drawRec` verwendest du `cos(72)`, `sin(72)` usw. als wären das Gradwerte, aber `Math.cos/sin` erwarten Radiant; dadurch landen die Kind-Kreise an falschen Positionen.\n- In `Circles.drawRec` zeichnest du nur zwei rekursive Kind-Kreise (die restlichen sind auskommentiert), womit die erwartete “Fraktal”-Struktur unvollständig ist.\n\n### Suggestion\n- Boxes: Achte darauf, dass **jeder** rekursive Aufruf ein **kleineres** Quadrat (z.B. `s/2`) bekommt; überprüfe speziell den Aufruf, der aktuell `s` unverändert lässt.\n- Boxes: Definiere den Basisfall so, dass er wirklich etwas zeichnet und dann stoppt; teste gedanklich die Fälle `n=0`, `n=1`, `n=2` und schau, ob jeweils genau das erwartete Detaillevel entsteht.\n- Triangles: Überlege dir eine klare Trennung: *Basisfall zeichnet das Dreieck*, *sonst berechnest du Mittelpunkte und rufst 3 Teil-Dreiecke auf*; wenn du in jedem Level zeichnest, überlagerst du das Muster.\n- Triangles: Prüfe deine drei rekursiven Dreiecke: sie sollten aus den Eckpunkten und den jeweils passenden Mittelpunkten zusammengesetzt sein (und dabei alle kleiner sein als das Ausgangsdreieck).\n- Circles: Wenn du Winkel verwenden willst, rechne Grad → Radiant um (oder nutze eine Hilfsfunktion dafür); sonst stimmen die Positionen nicht.\n- Circles: Zeichne den aktuellen Kreis immer, und entscheide dann anhand von `n`, ob du weitere Kind-Kreise zeichnest; so bleibt auch die letzte Rekursionsebene sichtbar.\n- Circles: Kontrolliere deine Offset-Rechnung: Kind-Kreise sollten relativ zu `(x,y)` des Elternkreises platziert werden (nicht über Hilfsvariablen, die `x`/`y` und `r` mischen), und der Abstand hängt typischerweise von `r` und dem Kindradius ab.\n\n### Code Style\n- In allen Klassen sind viele auskommentierte Zeilen/Debug-Notizen; räume die weg, sobald du dich entschieden hast, sonst wird es schwer, die eigentliche Logik zu lesen.\n- `Circles`: du importierst `cos/sin` statisch, verwendest aber “magische Zahlen” (72, 144, …) ohne Kommentar/Benennung; benannte Konstanten (z.B. Anzahl Kreise, Winkelabstand) würden die Absicht klarer machen.\n- `Fractal`: Du startest mit `n = 10`; zum Testen der Rekursion ist es oft übersichtlicher, mit kleinen Werten zu beginnen (z.B. 0–3), damit man Fehler im Basisfall schneller sieht.\n\n\n# Exercise: knapsack\n\n### Correctness\n- In `pack(int i)` verwendest du `for (; i <= maxN; i++)` und überschreibst damit den Item-Index `i` (statt die Anzahl Kopien zu variieren). Dadurch iterierst du nicht korrekt über alle Gegenstände, sondern vermischst „welches Item“ mit „wie oft“.\n- Durch `i <= maxN` kann `loadItem(i)` mit `i == maxN` oder allgemein `i >= weights.length` aufgerufen werden, was bei den gegebenen Arrays zu einem `ArrayIndexOutOfBoundsException` führen kann.\n- Du berücksichtigst das Kriterium „bis zu maxN Stück pro Gegenstand“ nicht korrekt: du lädst und entlädst pro Schleifendurchlauf jeweils nur **ein** Stück (`loadItem`/`unloadItem`), es gibt aber keinen Zustand, der „0, 1, 2, …, maxN“ Stück desselben Items sauber abbildet.\n- Der Abbruch/Branching entspricht nicht dem unbounded/limited-Knapsack-Backtracking: Du rufst `pack(i+1)` mehrfach auf, aber ohne vorher/nachher konsistent mehrere Kopien des *gleichen* Items zu packen; so werden Kombinationen entweder verpasst oder falsch gezählt.\n- Es fehlt eine sinnvolle Gewichtsbeschränkungs-Prüfung **vor** dem weiteren Rekursions-Abstieg (du prüfst nur im Blattfall `i == weights.length`), dadurch explorierst du auch Zustände, die schon längst über `maxWeight` liegen (bei vielen Kopien wird das besonders problematisch).\n\n### Suggestion\n- Trenne in deiner Rekursion klar zwei Dimensionen: (1) welches Item `i` du gerade betrachtest und (2) wie viele Kopien dieses Items du nimmst (0 bis `maxN`). Der `for`-Loop sollte die Kopienzahl variieren, nicht den Item-Index.\n- Achte darauf, dass `i` immer nur von `0` bis `weights.length` läuft; die Schleife sollte sich an `maxN` orientieren, aber niemals `i` über die Array-Länge hinaus treiben.\n- Wenn du mehrere Kopien eines Items ausprobieren willst, musst du entweder wiederholt laden (z.B. k-mal) und erst nach dem Durchprobieren wieder vollständig „zurückspulen“, oder du verwaltest die Rücknahme so, dass nach dem Loop der ursprüngliche Zustand wiederhergestellt ist.\n- Bau eine frühe Schranke ein: sobald `currWeight > maxWeight`, solltest du in diesem Rekursionszweig nicht weitergehen (gerade bei „n-mal“ spart das extrem viel).\n- Überprüfe gedanklich einen einzelnen Schritt: „Ich bin bei Item i. Ich probiere 0 Stück, dann 1 Stück, … bis maxN Stück (oder bis Gewicht überschritten). Danach gehe ich weiter zu i+1.“ Wenn dein Code das nicht direkt widerspiegelt, stimmt die Struktur noch nicht.\n\n### Code Style\n- In der Lösung sind viele `System.out.println(...)` Debug-Ausgaben (auch in `loadItem`). Die Tests erwarten typischerweise keine Konsolen-Ausgabe; entferne Debug-Prints oder nutze einen Debug-Logger, den du abschalten kannst.\n- `for(; i <= maxN; i++)` ist schwer lesbar und nutzt die Methode-Parameter-Variable als Schleifenvariable; verwende dafür eine eigene lokale Variable (z.B. `n`), damit klar bleibt, was Index und was Anzahl ist.\n\n\n# Exercise: sudoku\n\n### Correctness\n- `Sudoku.main()` hat nicht die geforderte Signatur `public static void main(String[] args)`, dadurch startet die Applikation typischerweise nicht korrekt.\n- In `solved(...)` verwendest du feste Grenzen (`81`, `9`) statt `model.size()`; damit ist die Methode nicht allgemein korrekt für andere Sudoku-Grössen, obwohl das Interface das zulässt.\n- `solved(...)` erfüllt die Vorgabe „bei false: model wurde auf den Initialzustand zurückgesetzt“ nicht zuverlässig: Du clearst nur das zuletzt probierte Feld, aber falls in tieferen Rekursionen bereits gesetzte Werte verbleiben (je nach Verlauf), kann das Model verändert zurückkommen.\n- `nofSolutions(...)` setzt direkt am Anfang `max = 0` und ignoriert damit die MAX-Abbruchbedingung aus dem Interface.\n- `nofSolutions(...)` zählt Lösungen nicht korrekt: du rufst an mehreren Stellen `solved(...)` auf (das findet höchstens *eine* Lösung und verändert das Model), statt die Anzahl Lösungen systematisch zu akkumulieren.\n- `nofSolutions(...)` stellt den Initialzustand des Models am Ende nicht sicher wieder her (Anforderung: „The model was reset to its initial state.“).\n\n### Suggestion\n- Für den Startpunkt: prüfe, wie eine Java-Applikation den Einstiegspunkt findet (Signatur/`static`/`public`) und passe deine `main`-Methode entsprechend an.\n- Versuche in `solved` und `nofSolutions` konsequent mit `model.size()` zu rechnen: Gesamtfelder = `size*size`, Zeile/Spalte aus `fieldNr` ebenfalls mit `size`.\n- Damit das Model bei „kein Solverfolg“ wieder im Ausgangszustand ist: überlege dir, an welchen Stellen im Backtracking du ein Feld wieder leeren musst (typisch: immer dann, wenn du ein Feld testweise gesetzt hast und kein passender Pfad gefunden wurde).\n- In `solved(...)`: statt jedes Mal das ganze Sudoku mit `checker.allOK(model)` zu prüfen, reicht es normalerweise, nur den gerade gesetzten Wert zu prüfen (Hinweis: dafür gibt es `checker.oneOK(model, i, j)`).\n- Für `nofSolutions(...)`: denke in „alle Möglichkeiten ausprobieren und aufsummieren“ statt „einmal lösen“: jede gültige Belegung führt rekursiv zu einer Anzahl Teillösungen, die du addierst; und du musst den `max`-Parameter so weiterreichen, dass du früh abbrechen kannst, sobald du genug Lösungen gefunden hast.\n- Achte darauf, dass `nofSolutions` am Ende (egal ob Abbruch oder nicht) das zuletzt gesetzte Feld wieder cleared, bevor du zurückkehrst, damit das Model wirklich wieder im Initialzustand landet.\n\n3. Code Style:\n- Die vielen `System.out.println(...)` in den rekursiven Methoden machen die Ausgabe extrem noisy und verlangsamen Backtracking stark; zum Debuggen ok, aber für die finale Abgabe sollten die raus oder zumindest über ein Debug-Flag steuerbar sein.\n- In `nofSolutions(...)` ist der Parametername `max` irreführend, wenn du ihn gleich überschreibst; generell: Parameter nicht „zweckentfremden“, sondern eine eigene Zählvariable verwenden.\n- Du verwendest an mehreren Stellen Magic Numbers (`81`, `9`); auch wenn es für 9x9 funktioniert, ist es lesbarer und weniger fehleranfällig, wenn du diese aus dem Modell ableitest.\n\n\n# Exercise: queens\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
},
"unitTest" : {
"tests" : [ {
"name" : "allZero()",
"status" : "PASSED",
"message" : null
}, {
"name" : "uselessStuff()",
"status" : "PASSED",
"message" : null
}, {
"name" : "random1()",
"status" : "FAILED",
"message" : "expected: <190> but was: <174>"
}, {
"name" : "random2()",
"status" : "FAILED",
"message" : "expected: <340> but was: <0>"
}, {
"name" : "random3()",
"status" : "FAILED",
"message" : null
}, {
"name" : "boardIsValidAfterSolveN4()",
"status" : "FAILED",
"message" : "Board must contain exactly N queens ==> expected: <4> but was: <0>"
}, {
"name" : "boardIsValidAfterSolveN5()",
"status" : "FAILED",
"message" : "Board must contain exactly N queens ==> expected: <5> but was: <0>"
}, {
"name" : "boardIsValidAfterSolveN8()",
"status" : "FAILED",
"message" : "Board must contain exactly N queens ==> expected: <8> but was: <0>"
}, {
"name" : "boardSizeIsCorrectForN4()",
"status" : "PASSED",
"message" : null
}, {
"name" : "boardSizeIsCorrectForN8()",
"status" : "PASSED",
"message" : null
}, {
"name" : "countN1()",
"status" : "FAILED",
"message" : "N=1 has exactly 1 solution ==> expected: <1> but was: <0>"
}, {
"name" : "countN2()",
"status" : "PASSED",
"message" : null
}, {
"name" : "countN3()",
"status" : "PASSED",
"message" : null
}, {
"name" : "countN4()",
"status" : "FAILED",
"message" : "N=4 has exactly 2 solutions ==> expected: <2> but was: <0>"
}, {
"name" : "countN5()",
"status" : "FAILED",
"message" : "N=5 has exactly 10 solutions ==> expected: <10> but was: <0>"
}, {
"name" : "countN6()",
"status" : "FAILED",
"message" : "N=6 has exactly 4 solutions ==> expected: <4> but was: <0>"
}, {
"name" : "countN8()",
"status" : "FAILED",
"message" : "N=8 has exactly 92 solutions ==> expected: <92> but was: <0>"
}, {
"name" : "solveReturnsTrueForN1()",
"status" : "FAILED",
"message" : "N=1 has exactly one solution ==> expected: <true> but was: <false>"
}, {
"name" : "solveReturnsTrueForN4()",
"status" : "FAILED",
"message" : "N=4 has valid queen placements ==> expected: <true> but was: <false>"
}, {
"name" : "solveReturnsTrueForN8()",
"status" : "FAILED",
"message" : "N=8 has valid queen placements ==> expected: <true> but was: <false>"
}, {
"name" : "solveReturnsFalseForN2()",
"status" : "PASSED",
"message" : null
}, {
"name" : "solveReturnsFalseForN3()",
"status" : "PASSED",
"message" : null
} ]
}
}