{
"llm" : {
"feedback" : "# Exercise: floodfill\n\n### Correctness\n- In `RecursiveFloodFill` vergleichst du Farben mehrfach mit `==`/`!=` (z. B. `img.getPixel(x,y) == newColor` und `img.getPixel(x, y) != oldColor`); damit prüfst du Referenzgleichheit statt Farbgleichheit, wodurch Flood-Fill oft nicht oder falsch funktioniert.\n- In `IterativeFloodFill` verwendest du beim Verarbeiten der Worklist nie die Koordinaten aus `Coord` (du setzt immer `img.setPixel(x, y, newColor)` mit den ursprünglichen `x,y`), dadurch wird nicht die Fläche gefüllt.\n- In `IterativeFloodFill` fügst du Nachbarn blind hinzu (`x+1`, `x-1`, …) ohne Bounds-Check; das führt beim späteren `getPixel/setPixel` zu Zugriffen ausserhalb des Bildes.\n- In `IterativeFloodFill` fehlt die entscheidende Prüfung, ob das aktuell entfernte Pixel überhaupt die `oldColor` hat, bevor du es einfärbst und Nachbarn hinzufügst; so “läuft” der Algorithmus unkontrolliert weiter.\n- Umschalten der Algorithmen: In `DrawingApp` ist die Logik für `up`/`down` vertauscht/ungewöhnlich (bei `\"down\"` dekrementierst du), und du gibst den Algorithmus nicht im geforderten Format mit dem Präfix `\"↑↓ \"` aus.\n- Die Aufgabenstellung verlangt explizit, dass `DrawingApp` je *ein Objekt von `ColorReplace` und `RecursiveFloodFill` enthält* (und damit zwischen genau diesen beiden umschalten kann); du hast zusätzlich `IterativeFloodFill` eingebaut, ohne die dafür geforderten Zwischenschritte/Interfaces (`WorkList` etc.) umzusetzen (damit erfüllst du nicht sauber den geforderten Stand der Teilaufgabe).\n\n### Suggestion\n- Schau dir an, wie `Color`-Objekte verglichen werden sollen: wenn die Library-Farbe benutzt wird, ist fast immer `equals(...)` nötig (und nicht `==`). Überlege dir, welche Abbruchbedingungen im Flood-Fill davon abhängen.\n- Für die iterative Variante: Nimm beim Loop wirklich das `Coord c`, das du entfernst, und arbeite dann mit `c.x/c.y` weiter. Wenn du immer nur mit den ursprünglichen Parametern arbeitest, kann die Worklist gar keine Wirkung haben.\n- Bevor du Nachbarn zur Worklist hinzufügst: Überlege, ob du lieber *vor dem Add* die Grenzen prüfst oder *beim Remove/Verarbeiten* einen Basisfall für “ausserhalb”/“falsche Farbe” einbaust. Hauptsache: nie `getPixel/setPixel` mit ungültigen Koordinaten.\n- Baue die typische Flood-Fill-Struktur nach dem Pseudocode aus der Aufgabe: “remove → wenn Farbe passt → färben → Nachbarn hinzufügen”. Wenn du diese “wenn Farbe passt”-Stelle einfügst, stoppen die falschen Bereiche automatisch.\n- Für das Umschalten per Tastatur: Implementiere es analog zur Farblogik (Index hoch/runter, dann modulo). Prüfe dabei, ob “up” wirklich den Index reduzieren oder erhöhen soll – wichtig ist Konsistenz mit deiner Anzeige.\n- Für Teilaufgabe (a/b) zuerst wirklich nur `FillAlgorithm` + `ColorReplace implements FillAlgorithm` + `RecursiveFloodFill implements FillAlgorithm` + Umschalten zwischen genau diesen beiden sauber fertigstellen, bevor du die iterative Erweiterung komplett nach Spezifikation (mit `WorkList`) angehst.\n\n### Code Style\n- Du hast eine eigene `ch.fhnw.prog1.exercise.floodfill.Color`-Klasse angelegt, verwendest aber überall `ch.trick17.gui.Color`; diese zusätzliche Klasse ist hier unbenutzt/irreführend und kann zu Namenskonflikten führen.\n- In `Coord` speicherst du ein `Color color`, nutzt es aber für den Algorithmus nicht sinnvoll; ein `Coord` sollte primär Koordinaten repräsentieren, sonst vermischt du Verantwortlichkeiten.\n- Sehr viele `System.out.println(...)` Debug-Ausgaben (auch in `setPixel`) machen die App extrem langsam und “spammen” die Konsole; besser Debugging gezielt entfernen/deaktivieren, wenn die Logik steht.\n- `org.w3c.dom.ls.LSOutput` ist importiert, wird aber nicht verwendet.\n- In `Coord.hashCode()` ist `Integer.parseInt(x + \"0\" + y)` unnötig teuer und fehleranfällig (z. B. bei grösseren Zahlen/negativen Werten); nimm eine einfache arithmetische Kombination statt String-Bastelei.\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 bereits „gelöst“, indem du `hashCode()` ergänzt hast; in der Übung steht aber explizit, dass du das Problem **nicht lösen musst** (und der Fokus auf **Hypothese + Minimalbeispiel** liegt).\n- Es fehlt ein eigenes **Minimalbeispiel-Programm**, das das Problem reproduziert (z.B. mit `HashMap`/`HashSet` und zwei logisch gleichen `Color`-Objekten), wie in der Aufgabenstellung verlangt.\n\n### Suggestion\n- Setze deinen Fokus darauf, das fehlerhafte Verhalten **mit so wenig Code wie möglich** zu zeigen: Erzeuge zwei `Color`-Objekte mit identischen RGB-Werten und speichere sie in einer `HashMap` oder einem `HashSet`, dann beobachte Größe/Inhalt.\n- Halte dein Abgabeziel strikt bei „Reproduzieren und Eingrenzen“: dokumentiere, was du erwartest vs. was tatsächlich passiert, und welche Beobachtung dich zur Hypothese führt (z.B. warum `equals` allein nicht reicht bei Hash-basierten Collections).\n\n### Code Style\n- `import java.util.Objects;` ist ungenutzt (weil du `Objects.hash(...)` auskommentiert hast) – entweder verwenden oder entfernen.\n- `System.out.println(histogram.get(pixel));` in der innersten Schleife erzeugt extrem viel Output und macht die Auswertung schwer nachvollziehbar; besser nur gezielt ausgeben (z.B. am Ende oder für einzelne Testwerte).\n- Deine `hashCode()`-Berechnung wirkt schwer lesbar und potenziell fehleranfällig (Klammerung/Operator-Priorität ist hier nicht sehr klar); wenn du sie schon drin lässt, mache sie zumindest gut nachvollziehbar.\n",
"status" : "SUCCESS"
}
}