{
"llm" : {
"feedback" : "Exercise: fractal\n\n## 1. Correctness\n- In `Boxes` ist `drawRec(...)` nicht implementiert, damit wird keine Box-Fraktalform gezeichnet.\n- In `Triangles` ist `drawRec(...)` nicht implementiert, damit wird keine Dreiecks-Fraktalform gezeichnet.\n\n## 2. Suggestion\n- Für `Boxes.drawRec(...)`: Überlege dir eine Rekursions-Abbruchbedingung (z. B. wenn `n == 0`) und zeichne in diesem Fall genau ein Rechteck mit `g.drawRect(x, y, s, s)`. Im rekursiven Fall zeichnest du das aktuelle Rechteck und rufst `drawRec` für kleinere Teil-Quadrate auf (mit angepassten `x/y`-Positionen und kleinerem `s`), sodass das gewünschte Muster entsteht.\n- Für `Triangles.drawRec(...)`: Auch hier zuerst eine Abbruchbedingung (z. B. `n == 0`). Dann: Zeichne das Dreieck, indem du die drei Kanten mit `g.drawLine(...)` zwischen `(x0,y0)-(x1,y1)`, `(x1,y1)-(x2,y2)`, `(x2,y2)-(x0,y0)` verbindest. Für die Rekursion brauchst du die Mittelpunkte der Seiten, um daraus kleinere Dreiecke zu bilden und `drawRec` mit diesen neuen Eckpunkten und `n-1` aufzurufen.\n\n## 3. Code Style\n- Die `// TODO implement`-Kommentare sind noch vorhanden; sobald du fertig bist, entferne sie oder ersetze sie durch kurze, beschreibende Kommentare zur Rekursionsidee (Abbruchfall / rekursiver Fall).\n\n\nExercise: knapsack\n\n1. Correctness\n- `pack(int i)` ist nicht implementiert, damit wird keine Suche nach Kombinationen durchgeführt und `maxValue` bleibt immer 0.\n- `packItem(int i)` ist nicht implementiert, dadurch werden Gewicht und Wert beim “Mitnehmen” eines Gegenstands nie aktualisiert.\n- `unpackItem(int i)` ist nicht implementiert, dadurch kann ein zuvor hinzugefügter Gegenstand (bzw. mehrere Kopien davon) nicht wieder entfernt werden; Backtracking ist so nicht möglich.\n- Die Anforderung „Gegenstände bis zu n‑Mal mitnehmen“ wird aktuell nirgends umgesetzt (es gibt keine Schleife/Logik, die 0..maxN Kopien pro Item berücksichtigt).\n\n2. Suggestion\n- Überlege dir eine rekursive Struktur wie beim klassischen Knapsack: Für jedes Item-Index `i` alle Möglichkeiten durchprobieren und dann mit `i+1` weitermachen; hier brauchst du zusätzlich eine Schleife, die die Anzahl Kopien (0 bis `maxN`) für dieses Item variiert.\n- Achte darauf, dass du nur dann weiter verzweigst/rekursiv gehst, wenn das aktuelle Gewicht die `maxWeight`-Grenze nicht überschreitet, und dass du beim Erreichen des Endes (`i == weights.length`) `maxValue` mit `currValue` vergleichst.\n- `packItem`/`unpackItem` sollten spiegelbildlich arbeiten: Was du beim Einpacken zum aktuellen Gewicht/Wert addierst, musst du beim Auspacken wieder vollständig entfernen (bei mehreren Kopien entsprechend mehrfach oder mit Faktor).\n- Wenn du pro Item mehrere Kopien nacheinander einpackst, stell sicher, dass du nach dem Durchprobieren aller Kopien für dieses Item den Zustand wieder auf „wie vor diesem Item“ zurücksetzt, bevor du zurückkehrst.\n\n3. Code Style\n- Die TODO-Kommentare und leeren Methoden sind im finalen Abgabezustand problematisch; entferne TODOs, sobald implementiert, oder ersetze sie durch kurze, aussagekräftige Kommentare zur Logik.\n- Optional zur Lesbarkeit: Benenne `i` sprechender (z.B. `index`) und nutze konsequent Klammern/Formatierung, damit Rekursion + Schleifen leichter nachvollziehbar sind.\n\n\nExercise: queens\n\n### 1. Correctness\n- `solve()` ist nicht implementiert und liefert immer `false`, damit wird nie eine Lösung gesucht/gefunden und das Board bleibt leer.\n- `count()` ist nicht implementiert und liefert immer `0`, damit wird die Anzahl möglicher Lösungen nicht gezählt.\n\n### 2. Suggestion\n- Für `solve()`: Überlege dir eine rekursive Backtracking-Funktion, die zeilenweise (oder spaltenweise) eine Dame setzt, mit `checkPlacement(row, col)` prüft und bei Fehlschlag wieder entfernt (Backtracking). Der Abbruchfall ist erreicht, wenn alle N Reihen erfolgreich belegt sind.\n- Für `count()`: Nutze eine sehr ähnliche Rekursion wie bei `solve()`, aber statt beim ersten Treffer zu stoppen, erhöhst du einen Zähler bei jeder vollständigen Platzierung und suchst danach weiter (nach dem Zurücksetzen/Backtracking).\n\n### 3. Code Style\n- In `BoardPrinter`: `if (board[row][col] == true)` ist unnötig ausführlich; ein direkter Boolean-Check ist lesbarer.\n- Es gibt keine offensichtlichen unbenutzten oder themenfremden Code-Teile, aber die TODO-Kommentare in `QueensSolver` sollten nach der Implementierung entfernt werden.\n\n\nExercise: sudoku\n\n## 1. Correctness\n- In `SudokuSolverImpl`, the recursive `solved(SudokuModel model, int fieldNr)` is not implemented and always returns `false`, so the solver can never report a found solution and will never fill the model.\n- In `SudokuSolverImpl`, the recursive `nofSolutions(SudokuModel model, int fieldNr, int max)` is not implemented and always returns `0`, so the solution counter will never find/count any solutions.\n- The requirements say: if `solved(...)` returns `false`, the model must be reset to its initial state; currently there is no logic that restores the grid after trying.\n- The requirements say: `nofSolutions(...)` must reset the model to its initial state when finished; currently there is no logic to restore the grid after counting.\n\n## 2. Suggestion\n- For `solved`: think in terms of backtracking over the fields from `fieldNr = 0` up to `size*size - 1`: compute `(row, col)` from `fieldNr`, skip pre-filled cells, otherwise try values `1..size`, check validity with `checker.oneOK(...)`, recurse, and if it doesn’t work undo the choice (clear the field) before trying the next value.\n- For restoring the initial state in `solved(false)`: you’ll need some way to remember which cells were originally empty vs. fixed (or store the original values) so that after an unsuccessful search you can revert only what you changed.\n- For `nofSolutions`: it’s essentially the same search as `solved`, but instead of stopping at the first full solution you increment a counter when you reach the end, and continue searching until either all branches are explored or you hit the `max` limit.\n- For the `MAX` bound: make sure your recursion checks the current count and stops exploring deeper once you already reached `max`, otherwise the runtime can explode (e.g., almost-empty grids).\n- To ensure the model is reset after `nofSolutions`: apply the same “remember original board / fixed cells” idea, and always undo changes during backtracking (clear when returning), so at the end you’re back at the starting configuration.\n\n## 3. Code Style\n- The attempt currently duplicates many provided framework/template files unchanged; usually only `SudokuSolverImpl` is expected to be modified—keeping your submission focused on the changed file(s) makes review easier.\n- Remove the `// TODO implement` stubs once implemented and replace them with meaningful method-level comments only where needed (otherwise the code should be self-explanatory through names like `fieldNr`, `row`, `col`).\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: <0>"
}, {
"name" : "random2()",
"status" : "FAILED",
"message" : "expected: <340> but was: <0>"
}, {
"name" : "random3()",
"status" : "FAILED",
"message" : "expected: <558> but was: <0>"
} ]
}
}