{
"llm" : {
"feedback" : "# Exercise: floodfill\n\n### Correctness\n- Deine `IterativeFloodFill` implementiert aktuell keinen korrekten Flood-Fill: Du färbst Pixel unabhängig davon, ob sie die `oldColor` haben (die `oldColor` wird zwar mitgegeben, aber nirgends als Kriterium verwendet).\n- In `IterativeFloodFill` brichst du beim ersten Out-of-Bounds-Koordinatenfund mit `return` ab; dadurch wird die Füllung oft viel zu früh beendet (statt einfach diesen Eintrag zu überspringen und weiterzumachen).\n- In `IterativeFloodFill` veränderst du Koordinaten (`c.x++`) aufgrund eines Checks auf `newColor`; das führt dazu, dass du nicht mehr den eigentlich aus der Worklist geholten Pixel bearbeitest und die Worklist-Logik kaputtgeht.\n- In `RecursiveFloodFill` vergleichst du Farben einmal mit `!=` (`img.getPixel(x, y) != oldColor`) statt mit `.equals(...)`. Dadurch kann die Rekursion fälschlicherweise abbrechen, obwohl die Farbe inhaltlich gleich ist.\n- Die Statuszeile soll gemäss Aufgabe „↑↓ “ + aktueller Algorithmus anzeigen; bei dir fehlt das „↑↓ “ vor dem Algorithmus-Text.\n- Die Umschaltung der Algorithmen ist vertauscht: Bei dir macht `\"down\"` ein `modeIndex--` und `\"up\"` ein `modeIndex++`, also entgegen der Anforderung (↑/↓ zwischen Algorithmen wechseln, analog zur Farblogik).\n\n### Suggestion\n- Iterativ: Überlege dir die Bedingung, wann du ein aus der Worklist entnommenes Pixel wirklich einfärben darfst. Welche Farbe muss es haben, damit es „zur Fläche“ gehört (Stichwort: Farbe des Startpixels)?\n- Iterativ: Wenn du Nachbarn einfügst, wirst du zwangsläufig auch Koordinaten ausserhalb des Bildes erzeugen. Statt den ganzen Algorithmus zu beenden: Welche Aktion wäre sinnvoller für genau *diesen einen* Worklist-Eintrag?\n- Iterativ: Vermeide es, Koordinatenobjekte nach dem Entfernen aus der Worklist „umzubiegen“ (wie `c.x++`). Nimm stattdessen den Worklist-Eintrag als feste Position und entscheide nur, ob du ihn färbst und ob du seine Nachbarn hinzufügst.\n- Rekursiv: Schau dir alle Farbvergleiche an und stelle sicher, dass du konsequent denselben Vergleichsmechanismus verwendest wie in `ColorReplace` (inhaltlicher Vergleich).\n- UI/Key-Handling: Wenn du die Farblogik als Vorlage nimmst, kannst du die gleiche „Index hoch/runter + modulo“-Struktur auch für die Algorithmen verwenden; achte dabei darauf, welche Taste welchen Richtungswechsel bedeuten soll.\n- Footer: Wenn du „↑↓ “ wie bei den Farben („←→ “) darstellst, passt es zur Aufgabenbeschreibung und ist für Nutzer:innen klarer.\n\n3. Code Style:\n- Du hast eine eigene `ch.fhnw.prog1.exercise.floodfill.Color`-Klasse, verwendest aber im Rest `ch.trick17.gui.Color`; diese zusätzliche Klasse wirkt hier wie ein Fremdkörper und verwirrt (und sie wird offenbar nicht genutzt).\n- In `Coord` sind `x` und `y` package-private und werden mutiert (`c.x++`). Für Koordinaten ist ein unveränderliches Objekt (final Felder, keine Mutation) viel weniger fehleranfällig.\n- `Coord.hashCode()` via `Integer.parseInt(x + \"0\" + y)` ist sehr fragil (z.B. bei mehrstelligen Zahlen oder negativen Werten) und unnötig teuer; ausserdem passt das schlecht zu `equals`.\n- Mehrere `System.out.println(...)` Debug-Ausgaben in produktivem Code (u.a. in `Image.setPixel`, FloodFill-Klassen, Key-Handling). Wenn du debuggen willst, besser gezielt und danach entfernen.\n- Unbenutzte Imports in `DrawingApp` (`org.w3c.dom.ls.LSOutput`) und in `Coord` (`ch.trick17.gui.Color`) entfernen.\n\n\n# Exercise: flashcard\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: imagestats\n\n### Correctness\n- Du hast das Problem faktisch gelöst (durch Implementieren von `hashCode()`), obwohl in der Aufgabe ausdrücklich steht, dass du das Problem **nicht** lösen musst, sondern ein **Minimalbeispiel erstellen** sollst, das es reproduziert.\n- Es fehlt ein eigenständiges Minimalbeispiel-Programm, das das Verhalten mit `HashMap`/`HashSet` (Duplikate werden nicht erkannt) in wenigen Zeilen reproduziert.\n\n### Suggestion\n- Lass den Programmzustand so, dass das fehlerhafte Verhalten weiterhin sichtbar ist, und reduziere dann alles auf das kleinstmögliche Beispiel: nur eine `HashMap` (oder `HashSet`) und zweimal ein “gleiches” `Color`-Objekt einfügen, dann Ausgabe der Größe bzw. des Inhalts.\n- Überlege beim Minimalbeispiel: Welche Teile (Bild einlesen, Pixel-Schleifen, häufigste Farbe) tragen wirklich zur Reproduktion des Fehlers bei – und welche kannst du komplett weglassen, ohne dass das Problem verschwindet?\n\n### Code Style\n- `System.out.println(histogram.get(pixel));` innerhalb der doppelten Schleife erzeugt extrem viel Output und macht das Programm unnötig langsam/unübersichtlich; wenn du debuggen willst, begrenze die Ausgabe (z.B. nur für wenige Pixel) oder nutze gezielte Checks.\n- `import java.util.Objects;` ist aktuell ungenutzt (du hast die `Objects.hash(...)`-Variante auskommentiert). Entfernen oder konsistent verwenden.\n- Der auskommentierte alternative `hashCode()`-Return sollte entweder entfernt oder als bewusste Variante klar begründet werden, sonst wirkt es wie “toter Code”.\n",
"status" : "SUCCESS"
}
}