Programmierung
Vergleicht Korrektheit, Qualität und Praxistauglichkeit des erzeugten Codes.
In diesem Genre werden vor allem Fähigkeiten wie Korrektheit, Vollständigkeit, Codequalität betrachtet.
Anders als system design geht es hier stärker darum, ob der Code wirklich funktioniert als um Architekturentscheidungen auf hohem Niveau.
Ein hoher Wert hier garantiert weder besseres Produkturteil noch bessere Architektur oder bessere Erklärungen für Einsteiger.
Wofür starke Modelle in diesem Genre gut geeignet sind
Implementierung, Debugging, Refactoring und praktische Programmierunterstützung.
Was dieses Genre allein nicht zeigen kann
ob das Modell besser für Architektur, Stakeholder-Dokumente oder offene Ideation geeignet ist.
Programmierung: Claude Fable 5 debütiert an der Spitze, GPT-5 mini ist die belastbarste Wahl
Anthropic
OpenAI
OpenAI
Durchschnittswert je Modell
Gewichtung
Claude Fable 5 kam in dieses Genre und übernahm sofort die Spitze: Es gewann sein Auftaktduell mit dem stärksten Auftritt der Tabelle. Auch GPT-5.6 hat bislang alles gewonnen, was es bestritten hat. Beide Bilanzen sind beeindruckend und zugleich dünn: Ein Auftaktsieg belegt, dass ein Modell hier gewinnen kann — nicht, dass es dabei bleibt. Die genaue Reihenfolge ganz oben ist als frühes Signal zu lesen.
Die belastbarste Bilanz des Genres gehört GPT-5 mini: Es hat mehr Programmieraufgaben bestritten als jeder der Führenden und keine verloren. Für ein Modell der leichten Klasse ist eine ungeschlagene Serie gegen Frontier-Konkurrenz die beste Preis-Leistungs-Geschichte dieser Tabelle. GPT-5.5 dagegen erzielt einen der besten Durchschnitte des Genres, hat seine Duelle aber geteilt — guter Code, der den Code auf der Gegenseite nicht immer schlug. Claude Sonnet 5 lieferte im ersten Auftritt einen soliden Durchschnitt und verlor dennoch; seine Platzierung unterzeichnet derzeit die Qualität seiner Ausgabe.
Die Korrektheit dominiert die Bewertung, gefolgt von Vollständigkeit und Codequalität — das Ranking bestraft subtile Fehler härter als bloßen Stil. Die Gemini-Familie hat in diesem Genre noch kein Duell für sich entschieden und liegt auch beim Durchschnitt hinten. All das spiegelt die spezifischen Aufgaben und Juroren von Orivel: Programmierung reicht von Algorithmen bis API-Design, und eine Handvoll Aufgaben kann diesen Raum nicht abdecken.
Fazit
GPT-5 mini ist heute die Wahl, die sich verteidigen lässt — ungeschlagen über die meisten Duelle, zu Kosten der leichten Klasse. Claude Fable 5 und GPT-5.6 wirken noch stärker, aber auf früher Basis. Spannend ist, ob GPT-5.5 seine hochwertigen Antworten in Siege verwandelt.
Diese Analyse basiert auf den von Orivel gemessenen Benchmark-Werten für dieses Genre und wird regelmäßig aktualisiert. Die Werte sind bedingungsabhängige Messungen, keine absolute Wahrheit.
Ranking starker Modelle in diesem Genre
Dieses Ranking ist nach dem Durchschnittsscore nur innerhalb dieses Genres sortiert.
Zuletzt aktualisiert: 25 Jul 2026 01:19
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
| Gerankte Modelle | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | Claude Fable 5 | Anthropic |
100%
|
91
|
1 | 1 | Bewertung und Punktzahl von Claude Fable 5 ansehen |
| #2 | GPT-5.6 | OpenAI |
100%
|
86
|
2 | 2 | Bewertung und Punktzahl von GPT-5.6 ansehen |
| #3 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Bewertung und Punktzahl von GPT-5 mini ansehen |
| #4 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Bewertung und Punktzahl von GPT-5.5 ansehen |
| #5 | Claude Sonnet 5 NEU | Anthropic |
0%
|
83
|
0 | 1 | Bewertung und Punktzahl von Claude Sonnet 5 ansehen |
| #6 | Gemini 2.5 Pro |
0%
|
74
|
0 | 5 | Bewertung und Punktzahl von Gemini 2.5 Pro ansehen | |
| #7 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Bewertung und Punktzahl von Gemini 2.5 Flash-Lite ansehen | |
| #8 | Gemini 2.5 Flash |
0%
|
68
|
0 | 5 | Bewertung und Punktzahl von Gemini 2.5 Flash ansehen |
Was in Programmierung bewertet wird
Kriterien und Gewichte für dieses Genre-Ranking.
Korrektheit
35.0%
Dieses Kriterium ist enthalten, um Korrektheit in der Antwort zu prüfen. Es hat mehr Gewicht, weil dieser Teil das Gesamtergebnis in diesem Genre stark prägt.
Vollständigkeit
20.0%
Dieses Kriterium ist enthalten, um Vollständigkeit in der Antwort zu prüfen. Es hat ein klares Gewicht, weil es die Qualität sichtbar beeinflusst, auch wenn es nicht alles bestimmt.
Codequalität
20.0%
Dieses Kriterium ist enthalten, um Codequalität in der Antwort zu prüfen. Es hat ein klares Gewicht, weil es die Qualität sichtbar beeinflusst, auch wenn es nicht alles bestimmt.
Praktischer Nutzen
15.0%
Dieses Kriterium ist enthalten, um Praktischer Nutzen in der Antwort zu prüfen. Es ist leichter gewichtet, weil es das Hauptziel unterstützt, das Genre aber nicht allein definiert.
Befolgung der Anweisungen
10.0%
Dieses Kriterium ist enthalten, um Befolgung der Anweisungen in der Antwort zu prüfen. Es ist leichter gewichtet, weil es das Hauptziel unterstützt, das Genre aber nicht allein definiert.
Aktuelle Aufgaben
Programmierung
Webserver-Protokoll-Analysator
Schreiben Sie eine Python-Funktion analyze_logs(log_data), die einen mehrzeiligen String entgegennimmt, der Webserver-Protokolleinträge enthält. Die Funktion soll diese Logs parsen, eine Analyse durchführen und ein Dictionary zurückgeben, das die Ergebnisse zusammenfasst. Jede gültige Logzeile folgt diesem Format: [TIMESTAMP] LEVEL IP_ADDRESS "REQUEST_METHOD /path" RESPONSE_CODE BYTES_SENT Beispiel für eine gültige Zeile: [2023-10-27T10:00:00Z] INFO 192.168.1.1 "GET /index.html" 200 1543 Ihre Funktion sollte: Nur die gültigen Logzeilen parsen und fehlerhafte oder leere Zeilen dabei elegant ignorieren. Die folgenden Metriken berechnen: total_requests: Die Gesamtanzahl der gültigen Logeinträge. error_rate: Der Prozentsatz der Requests mit einem LEVEL von ERROR, gerundet auf zwei Nachkommastellen. top_3_ips: Eine Liste von Tupeln, wobei jedes Tupel eine IP-Adresse und deren Request-Anzahl enthält, für die 3 am häufigsten vorkommenden IPs. Die Liste soll absteigend nach Request-Anzahl sortiert sein. busiest_hour: Die Stunde des Tages (ein Integer von 0 bis 23), die die meisten Requests hatte. Der Zeitstempel liegt im ISO-8601-Format (UTC). Ein Dictionary mit den Schlüsseln total_requests, error_rate, top_3_ips und busiest_hour zurückgeben, das die berechneten Werte enthält. Behandeln Sie die folgenden Randfälle: Wenn der Eingabestring log_data leer ist, geben Sie ein Dictionary mit entsprechend nullgesetzten oder leeren Werten zurück (z. B. total_requests: 0, top_3_ips: []). Wenn es weniger als 3 eindeutige IP-Adressen gibt, sollte die Liste top_3_ips alle eindeutigen IPs enthalten, sortiert nach Anzahl. Wenn es einen Gleichstand für die verkehrsreichste Stunde gibt, ist es akzeptabel, eine beliebige der gleichstehenden Stunden zurückzugeben.
Programmierung
Ratenbegrenzer mit gleitendem Fenster und fairen Mehrmandantenquoten
Implementieren Sie eine wiederverwendbare Rate-Limiter-Bibliothek in einer Sprache Ihrer Wahl (Python, Go, TypeScript, Java oder Rust), die pro Client Anfragenquoten mithilfe eines gleitenden-Fenster-Algorithmus durchsetzt und zusätzlich eine faire Verteilungsrichtlinie über mehrere Mandanten bietet. Funktionale Anforderungen: Bieten Sie eine Klasse oder ein Modul mit einer Methode wie allow(tenant_id, client_id, now_ms), die zurückgibt, ob eine Anfrage erlaubt ist und, falls sie abgelehnt wird, wie viele Millisekunden bis zur nächsten erlaubten Anfrage verbleiben (retry_after_ms). Jeder Client ist auf eine maximale Anzahl von Anfragen innerhalb eines rollenden Zeitfensters beschränkt (zum Beispiel 100 Anfragen pro 60.000 ms). Die Konfiguration muss pro Mandant anpassbar sein. Implementieren Sie ein echtes gleitendes Fenster (gewichtet oder auf Logbasis), nicht ein festes Kalender-Bucket-Fenster, sodass Spitzenlasten über Bucket-Grenzen hinweg korrekt behandelt werden. Fügen Sie eine globale Obergrenze pro Mandant hinzu, sodass alle Clients eines Mandanten zusammen ein mandantenweites Maximum nicht überschreiten können. Wenn der Mandant ausgelastet ist, wird die verbleibende Kapazität fair unter den aktiven Clients verteilt, anstatt von einem Client monopolisiert zu werden. Der Limiter muss unter gleichzeitigen Zugriffen von mehreren Threads oder asynchronen Tasks sicher sein. Der Speicher darf nicht unbegrenzt wachsen: veraltete Client-Zustände müssen im Laufe der Zeit entfernt oder kompaktiert werden. Liefergegenstände: Die vollständige Implementierung mit klarer öffentlicher API und Inline-Dokumentation wichtiger Entscheidungen. Eine kurze Erklärung (in Kommentaren oder einem kurzen Prosatext) des gewählten gleitenden-Fenster-Algorithmus sowie seiner Genauigkeits-/Speicher-Kompromisse. Eine Testsuite, die die unten beschriebenen Kern-Grenzfälle abdeckt. In Code und Tests ausdrücklich zu behandelnde Grenzfälle: Anfragen genau an der Fenstergrenze. Ein Client, der inaktiv wird und nach vollständigem Ablauf des Fensters zurückkehrt. Gleichzeitig eintreffende Anfragen, die auf denselben Client-Zähler rennen. Uhr, die rückwärts läuft, oder doppelte Zeitstempel. Mandantensättigung und faire Neuverteilung unter konkurrierenden Clients. Aussondern veralteter Client-Zustände, ohne aktive Clients zu entfernen. Geben Sie alle Annahmen an, die Sie treffen (Einzelprozess vs. verteilt, Verfügbarkeit einer monotonen Uhr usw.). Wenn Sie einen Einzelprozess annehmen, beschreiben Sie kurz, wie das Design auf eine verteilte Bereitstellung erweitert werden würde.
Programmierung
Implementiere einen deterministischen Limit-Order-Book-Simulator
Schreibe eine Python-3.11-Lösung in einer einzigen Datei, die die Funktion process_events(events: list[dict]) -> dict implementiert. Verwende keine externen Pakete. Die Funktion muss ein kleines Börsen-Limit-Order-Book für ein Instrument simulieren. Sie erhält eine Liste von Ereignis-Dictionaries in Eingabereihenfolge und gibt ein Dictionary mit genau diesen Schlüsseln zurück: trades, rejected, book. Ereignistypen: Neues-Order-Ereignis: Erforderliche Felder: type="new", id, side, order_type, qty. side ist "buy" oder "sell". order_type ist "limit" oder "market". qty ist eine positive ganze Zahl. Eine Limit-Order erfordert außerdem price, eine positive ganze Anzahl von Cent. Das optionale Feld tif ist Time-in-Force: "GTC", "IOC" oder "FOK". Falls es fehlt, verwende "GTC" für Limit-Orders und "IOC" für Market-Orders. Market-Orders dürfen nicht tif="GTC" haben und dürfen nicht im Book verbleiben. Cancel-Ereignis: Erforderliche Felder: type="cancel", id. Es storniert die verbleibende Menge einer derzeit im Book ruhenden Order mit dieser id. Matching-Regeln: Das Book hat bids und asks. Ruhende Buy-Limit-Orders sind bids; ruhende Sell-Limit-Orders sind asks. Preis-Zeit-Priorität ist zwingend: zuerst der beste Preis; bei gleichem Preis zuerst die früher akzeptierte ruhende Order. Eine Buy-Order matched gegen ruhende asks, solange sie kreuzen kann: Eine Market-Buy kreuzt jeden ask; eine Limit-Buy kreuzt asks mit ask-Preis <= Buy-Limit-Preis. Eine Sell-Order matched gegen ruhende bids, solange sie kreuzen kann: Eine Market-Sell kreuzt jeden bid; eine Limit-Sell kreuzt bids mit bid-Preis >= Sell-Limit-Preis. Jede Trade-Menge ist min(verbleibende Menge der eingehenden Order, verbleibende Menge der ruhenden Order). Der Trade-Preis ist immer der Limit-Preis der ruhenden Maker-Order, niemals der Preis der eingehenden Order. Ein Trade-Record muss unmittelbar beim Eintreten angehängt werden und genau diese Schlüssel haben: buy_id, sell_id, price, qty, taker_id, maker_id. Teilweise ausgeführte ruhende Orders behalten ihre ursprüngliche Priorität mit der verbleibenden Menge. Vollständig ausgeführte Orders verlassen das Book. Time-in-Force-Verhalten: GTC-Limit-Orders lassen jeden nicht ausgeführten Rest im Book ruhen. IOC-Orders führen sofort so viel wie möglich aus und stornieren dann jeden Rest. FOK-Orders müssen gemäß dem aktuellen Book und den Kreuzungsregeln sofort vollständig ausführbar sein. Falls sie nicht vollständig ausführbar sind, erzeugen sie keine Trades und verändern das Book nicht. Falls sie vollständig ausführbar sind, werden sie normal ausgeführt. FOK-Orders verbleiben niemals im Book. Validierungs- und Zurückweisungsregeln: Wenn ein Ereignis fehlerhaft formatiert ist, weise es zurück, ohne das Book zu verändern. Hänge einen Zurückweisungs-Record an rejected an mit den Schlüsseln input_index, event, reason. Der Grund kann eine kurze, für Menschen lesbare Zeichenkette sein. Weise eine neue Order zurück, wenn ihre id bereits von einer zuvor akzeptierten neuen Order verwendet wurde, selbst wenn diese frühere Order inzwischen ausgeführt oder storniert wurde. Weise Cancel-Ereignisse für unbekannte ids oder ids zurück, die nicht mehr im Book ruhen. Weise qty- und price-Werte zurück, die nicht ganzzahlig sind, null sind oder negativ sind. In Python darf bool für diese Felder nicht als Ganzzahl akzeptiert werden. Ignoriere zusätzliche Felder bei ansonsten gültigen Ereignissen. Rückgabeformat: trades: Liste von Trade-Records in Ausführungsreihenfolge. rejected: Liste von Zurückweisungs-Records in Eingabereihenfolge. book: ein Dictionary mit den Schlüsseln bids und asks. book["bids"] muss alle ruhenden bids auflisten, sortiert nach absteigendem Preis, dann ursprünglicher Ruhezeit, jeweils als {"id": id, "price": price, "qty": remaining_qty}. book["asks"] muss alle ruhenden asks auflisten, sortiert nach aufsteigendem Preis, dann ursprünglicher Ruhezeit, jeweils als {"id": id, "price": price, "qty": remaining_qty}. Deine Antwort sollte vollständiger ausführbarer Python-Code sein, der process_events definiert. Du darfst Hilfsklassen/-funktionen und einen kleinen Selbsttest-Abschnitt einfügen, geschützt durch if name == "main":, aber die Kernfunktion darf weder von stdin lesen noch nach stdout schreiben.
Programmierung
Atomare JSON-Patch-Anwendung in Python implementieren
Schreiben Sie eine Python-3.11-Implementierung einer Funktion namens apply_json_patch(document, patch), die eine JSON-Patch-ähnliche Sequenz von Operationen auf einen JSON-kompatiblen Wert anwendet und den gepatchten Wert zurückgibt. Das Eingabedokument kann jede Kombination aus dict, list, str, int, float, bool und None sein. Der Patch ist eine Liste von Operations-Dicts. Die Implementierung darf das ursprüngliche Dokument oder irgendein von ihm erreichbares verschachteltes Objekt nicht verändern. Wenn irgendeine Operation ungültig ist, muss die Funktion eine benutzerdefinierte Ausnahme-Klasse namens JsonPatchError auslösen und das ursprüngliche Dokument unverändert lassen. Unterstützte Operationen sind add, remove, replace, move, copy und test. Verwenden Sie JSON Pointer-Pfade mit durch Schrägstriche getrennten Tokens, wobei der leere String das gesamte Dokument identifiziert, Tokens ~1 als / und ~0 als ~ dekodieren und jede andere Verwendung von ~ ungültig ist. Für Objekte ist ein Pfad-Token ein Schlüssel. Für Arrays muss ein Pfad-Token eine nicht-negative ganze Zahl ohne führende Nullen sein, mit Ausnahme des einzelnen Tokens 0; nur für add darf das letzte Token - zum Anhängen sein. Die add-Operation fügt in Arrays an einem Index von 0 bis len(array) ein, hängt für - an, setzt einen Objekt-Schlüssel oder ersetzt das gesamte Dokument, wenn der Pfad leer ist. Die remove-Operation verlangt, dass das Ziel existiert, und löscht es. Die replace-Operation verlangt, dass das Ziel existiert, und ersetzt es. Die move-Operation verlangt from und path, entfernt den Wert bei from und fügt ihn bei path hinzu, und muss das Verschieben eines Wertes in einen seiner eigenen Nachkommen ablehnen. Die copy-Operation verlangt from und path und kopiert den Quellwert tief nach Ziel. Die test-Operation verlangt value und ist nur erfolgreich, wenn das aktuelle Ziel tiefengleich zu value ist, einschließlich normaler Python-Gleichheit für Zahlen und exakter Gleichheit für Strings, Booleans und None. Jedes Operations-Dict muss genau die für diese Operation erforderlichen Felder plus das Feld op enthalten; unbekannte Felder oder fehlende Felder sind Fehler. Die Funktion sollte deterministisch, angemessen effizient und nur von der Python-Standardbibliothek abhängig sein. Fügen Sie alle notwendigen Hilfsfunktionen oder -klassen hinzu. Schreiben Sie kein Kommandozeilenprogramm und verwenden Sie keine externen Pakete.
Programmierung
Implementieren Sie einen auf Abhängigkeiten basierenden Aufgabenplaner in Python
Schreiben Sie eine Python-Funktion oder -Klasse, die eine Liste von Aufgaben basierend auf ihren Abhängigkeiten plant. Der Scheduler soll die Reihenfolge bestimmen, in der Aufgaben ausgeführt werden können, und Aufgaben gruppieren, die parallel ausgeführt werden können. Die Eingabe ist eine Liste von Dictionaries, wobei jedes Dictionary eine Aufgabe mit den folgenden Schlüsseln repräsentiert: id: Eine eindeutige Zeichenfolgenkennung für die Aufgabe. name: Ein String-Name für die Aufgabe. dependencies: Eine Liste von String-IDs von Aufgaben, die abgeschlossen sein müssen, bevor diese Aufgabe starten kann. Ihre Implementierung sollte: Die Liste der Aufgaben-Dictionaries als Eingabe entgegennehmen. Einen gültigen Ausführungsplan als Liste von Listen zurückgeben. Jede innere Liste stellt einen 'Batch' von Aufgaben dar, die gleichzeitig ausgeführt werden können. Die Reihenfolge der Batches repräsentiert die sequentielle Ausführungsreihenfolge. Die Reihenfolge der Aufgaben-IDs innerhalb eines Batches spielt keine Rolle. Zirkuläre Abhängigkeiten erkennen und behandeln. Wenn ein Zyklus gefunden wird, sollte ein ValueError mit einer beschreibenden Nachricht ausgelöst werden. Fälle erkennen und behandeln, in denen eine Abhängigkeits-ID keiner vorhandenen Aufgabe entspricht. Dies sollte ebenfalls einen ValueError auslösen.
Programmierung
Ratenbegrenzer mit gleitendem Fenster und Burst-Zulassung
Entwerfen und implementieren Sie einen threadsicheren Ratenbegrenzer in einer Sprache Ihrer Wahl (Python, Go, Java, TypeScript oder Rust), der die folgenden Anforderungen unterstützt: API-Oberfläche: Stellen Sie mindestens diese Operationen bereit: allow(client_id: str, cost: int = 1) -> bool — gibt zurück, ob die Anfrage gerade jetzt erlaubt ist. retry_after(client_id: str) -> float — gibt Sekunden zurück, bis mindestens 1 Einheit Kapazität verfügbar ist (0, wenn aktuell erlaubt). Ein Konstruktor, der eine pro-Client-Konfiguration akzeptiert: rate (Einheiten pro Sekunde), burst (maximale gespeicherte Einheiten) und ein optionales window_seconds für die Gleitfenster-Abrechnung. Algorithmus: Implementieren Sie eine Hybridlösung, die einen Token Bucket (für Burst-Toleranz) mit einem Gleitfenster-Log oder -Zähler kombiniert (um die Gesamtzahl der innerhalb von window_seconds erlaubten Anfragen zu begrenzen und so anhaltenden Missbrauch zu verhindern, den ein reiner Token Bucket nach Auffüllungen erlauben würde). Eine Anfrage ist nur dann erlaubt, wenn beide Prüfungen bestehen. Begründen Sie Ihre Wahl der Datenstruktur für das Gleitfenster (exakter Log vs. gewichtete Zwei-Bucket-Approximation) und diskutieren Sie Speichergenauigkeits-Abwägungen in einem kurzen Kommentarfeld oder einer Begleitnotiz. Nebenläufigkeit: Der Limiter wird von vielen Threads/Goroutines gleichzeitig für dieselben und verschiedene client_ids getroffen. Vermeiden Sie, dass ein einzelner globaler Lock zum Flaschenhals wird (z. B. per-Client-Locks oder Lock-Striping). Dokumentieren Sie, warum Ihr Ansatz unter konkurrierenden allow-Aufrufen korrekt ist (kein Doppelverbrauch von Tokens, keine verlorenen Updates). Zeitquelle: Machen Sie die Uhr injizierbar, damit Tests deterministisch sind. Verwenden Sie standardmäßig eine monotonische Uhr. Randfälle, die explizit behandelt werden müssen: cost größer als burst (muss abgelehnt werden, darf niemals ewig blockieren). Uhr geht rückwärts oder große Pausen (z. B. angehaltene VM): clampen statt abstürzen, und keine unbegrenzten Tokens gewähren. Erste Anfrage für einen neuen Client (Lazy-Initialisierung). Aufräumen veralteter Clients (Speicher darf nicht unbegrenzt wachsen, wenn Clients aufhören zu rufen). Bruchteilige Tokens / sub-millisekunden Timing. Tests: Stellen Sie mindestens 6 Unit-Tests mit der injizierbaren Uhr bereit, die abdecken: grundlegendes Allow/Deny, Burst-Entleerung und Auffüllung, gleitende Fenster-Grenze unabhängig von Bucket-Auffüllung, cost > burst, gleichzeitige Kontention auf einem Client (deterministische Eigenschaft: insgesamt erlaubte Anfragen in T Sekunden ≤ rate*T + burst), und Eviktion veralteter Clients. Komplexität: Geben Sie die amortisierte Zeitkomplexität von allow und die Speicherkomplexität pro Client an. Liefern Sie: vollständigen ausführbaren Code (eine einzelne Datei ist in Ordnung, Sie können Dateien aufteilen, wenn Sie sie deutlich kennzeichnen), die Tests und eine kurze Designnotiz (max. ~250 Wörter), die Ihre Entscheidungen und die präzisen Semantiken erklärt, wenn die beiden Algorithmen uneinig sind.