Orivel Orivel
Menü öffnen

Implementiere einen deterministischen Limit-Order-Book-Simulator

Vergleiche Modellantworten für diese Programmierung-Benchmark-Aufgabe und prüfe Scores, Kommentare und verwandte Beispiele.

Bitte einloggen oder registrieren, um Likes und Favoriten zu nutzen. Registrieren

X f L

Inhalt

Aufgabenübersicht

Vergleichsgenres

Programmierung

Aufgaben-Erstellermodell

Antwortende Modelle

Bewertungsmodelle

Aufgabenstellung

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:

  1. Neues-Order-Ereignis:
    Erforderliche Felder: type="new", id, side, order_type, qty.
    side is...
Mehr anzeigen

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:

  1. 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.

  2. 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.

Bewertungsrichtlinie

Eine starke Antwort implementiert die exakte API und Rückgabeform, befolgt die Preis-Zeit-Priorität deterministisch, behandelt Teilausführungen und das Entfernen vollständig ausgeführter Orders korrekt und bewahrt die Maker-Bepreisung in den Trade-Records. Sie sollte FOK atomar implementieren, ohne vorläufige Trades zu erzeugen oder das Book zu verändern, wenn die Liquidität unzureichend ist. Sie sollte fehlerhaft formatierte Ereignisse robust validieren, einschließlich doppelter ids, inaktiver Cancels, fehlender F...

Mehr anzeigen

Eine starke Antwort implementiert die exakte API und Rückgabeform, befolgt die Preis-Zeit-Priorität deterministisch, behandelt Teilausführungen und das Entfernen vollständig ausgeführter Orders korrekt und bewahrt die Maker-Bepreisung in den Trade-Records. Sie sollte FOK atomar implementieren, ohne vorläufige Trades zu erzeugen oder das Book zu verändern, wenn die Liquidität unzureichend ist. Sie sollte fehlerhaft formatierte Ereignisse robust validieren, einschließlich doppelter ids, inaktiver Cancels, fehlender Felder, ungültiger Time-in-Force-Werte, ungültiger Market-Order-Kombinationen und bool-Werten, die sich als Ganzzahlen ausgeben. Sie sollte Gleitkommaarithmetik vermeiden, externe Abhängigkeiten vermeiden und ein finales Book erzeugen, das exakt wie angegeben sortiert ist. Saubere Struktur, klare Hilfsfunktionen und angemessene Effizienz für Tausende von Ereignissen sind bevorzugt.

Antworten

from itertools import count

def _is_pos_int(v):
return isinstance(v, int) and not isinstance(v, bool) and v > 0

def process_events(events):
trades = []
rejected = []

# Resting book stored as dicts keyed by id; we keep a global sequence
# for time priority.
seq = count()

used_ids = set()  # all ids ever accepted as new orders
resting = {}  # id -> order dict {id, side, price, qty, seq}
bids = {}  # id -> order (side buy)
asks = {}  # id -> order (side sell)

def reject(idx, event, reason):
    rejected.append({"input_index": idx, "event": event, "reason": reaso...
Vollständige Antwort anzeigen

from itertools import count

def _is_pos_int(v):
return isinstance(v, int) and not isinstance(v, bool) and v > 0

def process_events(events):
trades = []
rejected = []

# Resting book stored as dicts keyed by id; we keep a global sequence
# for time priority.
seq = count()

used_ids = set()  # all ids ever accepted as new orders
resting = {}  # id -> order dict {id, side, price, qty, seq}
bids = {}  # id -> order (side buy)
asks = {}  # id -> order (side sell)

def reject(idx, event, reason):
    rejected.append({"input_index": idx, "event": event, "reason": reason})

def sorted_asks():
    # ascending price, then seq
    return sorted(asks.values(), key=lambda o: (o["price"], o["seq"]))

def sorted_bids():
    # descending price, then seq
    return sorted(bids.values(), key=lambda o: (-o["price"], o["seq"]))

def can_cross_buy(buy_is_market, buy_price, ask_price):
    if buy_is_market:
        return True
    return ask_price <= buy_price

def can_cross_sell(sell_is_market, sell_price, bid_price):
    if sell_is_market:
        return True
    return bid_price >= sell_price

def fillable_qty_buy(is_market, price, qty):
    remaining = qty
    for ask in sorted_asks():
        if remaining <= 0:
            break
        if not can_cross_buy(is_market, price, ask["price"]):
            break
        remaining -= min(remaining, ask["qty"])
    return qty - remaining

def fillable_qty_sell(is_market, price, qty):
    remaining = qty
    for bid in sorted_bids():
        if remaining <= 0:
            break
        if not can_cross_sell(is_market, price, bid["price"]):
            break
        remaining -= min(remaining, bid["qty"])
    return qty - remaining

def execute_buy(order_id, is_market, price, qty):
    remaining = qty
    while remaining > 0:
        book_asks = sorted_asks()
        if not book_asks:
            break
        best = book_asks[0]
        if not can_cross_buy(is_market, price, best["price"]):
            break
        tq = min(remaining, best["qty"])
        trades.append({
            "buy_id": order_id,
            "sell_id": best["id"],
            "price": best["price"],
            "qty": tq,
            "taker_id": order_id,
            "maker_id": best["id"],
        })
        remaining -= tq
        best["qty"] -= tq
        if best["qty"] == 0:
            del asks[best["id"]]
            resting.pop(best["id"], None)
    return remaining

def execute_sell(order_id, is_market, price, qty):
    remaining = qty
    while remaining > 0:
        book_bids = sorted_bids()
        if not book_bids:
            break
        best = book_bids[0]
        if not can_cross_sell(is_market, price, best["price"]):
            break
        tq = min(remaining, best["qty"])
        trades.append({
            "buy_id": best["id"],
            "sell_id": order_id,
            "price": best["price"],
            "qty": tq,
            "taker_id": order_id,
            "maker_id": best["id"],
        })
        remaining -= tq
        best["qty"] -= tq
        if best["qty"] == 0:
            del bids[best["id"]]
            resting.pop(best["id"], None)
    return remaining

for idx, event in enumerate(events):
    if not isinstance(event, dict):
        reject(idx, event, "event is not a dict")
        continue

    etype = event.get("type")
    if etype not in ("new", "cancel"):
        reject(idx, event, "invalid or missing type")
        continue

    if etype == "cancel":
        if "id" not in event:
            reject(idx, event, "cancel missing id")
            continue
        cid = event["id"]
        if cid not in resting:
            reject(idx, event, "cancel for unknown or non-resting id")
            continue
        o = resting.pop(cid)
        if o["side"] == "buy":
            bids.pop(cid, None)
        else:
            asks.pop(cid, None)
        continue

    # new order
    if "id" not in event:
        reject(idx, event, "new order missing id")
        continue
    oid = event["id"]

    side = event.get("side")
    order_type = event.get("order_type")
    qty = event.get("qty")

    if side not in ("buy", "sell"):
        reject(idx, event, "invalid or missing side")
        continue
    if order_type not in ("limit", "market"):
        reject(idx, event, "invalid or missing order_type")
        continue
    if not _is_pos_int(qty):
        reject(idx, event, "qty must be a positive integer")
        continue

    price = None
    if order_type == "limit":
        if "price" not in event:
            reject(idx, event, "limit order missing price")
            continue
        price = event["price"]
        if not _is_pos_int(price):
            reject(idx, event, "price must be a positive integer")
            continue

    # time-in-force
    if "tif" in event:
        tif = event["tif"]
        if tif not in ("GTC", "IOC", "FOK"):
            reject(idx, event, "invalid tif")
            continue
        if order_type == "market" and tif == "GTC":
            reject(idx, event, "market order may not be GTC")
            continue
    else:
        tif = "GTC" if order_type == "limit" else "IOC"

    # duplicate id check (after structural validation)
    if oid in used_ids:
        reject(idx, event, "duplicate order id")
        continue

    # Accept the order: register its id now.
    used_ids.add(oid)

    is_market = order_type == "market"

    if tif == "FOK":
        if side == "buy":
            fillable = fillable_qty_buy(is_market, price, qty)
        else:
            fillable = fillable_qty_sell(is_market, price, qty)
        if fillable < qty:
            # not completely fillable; no trades, no book change
            continue
        # completely fillable, execute normally
        if side == "buy":
            execute_buy(oid, is_market, price, qty)
        else:
            execute_sell(oid, is_market, price, qty)
        continue

    # IOC and GTC
    if side == "buy":
        remaining = execute_buy(oid, is_market, price, qty)
    else:
        remaining = execute_sell(oid, is_market, price, qty)

    if remaining > 0:
        if tif == "GTC" and not is_market:
            order = {
                "id": oid,
                "side": side,
                "price": price,
                "qty": remaining,
                "seq": next(seq),
            }
            resting[oid] = order
            if side == "buy":
                bids[oid] = order
            else:
                asks[oid] = order
        # IOC: cancel remainder (do nothing)

book = {
    "bids": [
        {"id": o["id"], "price": o["price"], "qty": o["qty"]} 
        for o in sorted_bids()
    ],
    "asks": [
        {"id": o["id"], "price": o["price"], "qty": o["qty"]} 
        for o in sorted_asks()
    ],
}

return {"trades": trades, "rejected": rejected, "book": book}

if name == "main":
evs = [
{"type": "new", "id": "a", "side": "sell", "order_type": "limit", "qty": 10, "price": 100},
{"type": "new", "id": "b", "side": "sell", "order_type": "limit", "qty": 5, "price": 101},
{"type": "new", "id": "c", "side": "buy", "order_type": "limit", "qty": 12, "price": 100},
{"type": "new", "id": "d", "side": "buy", "order_type": "market", "qty": 3},
{"type": "new", "id": "a", "side": "buy", "order_type": "limit", "qty": 1, "price": 50},
{"type": "cancel", "id": "b"},
{"type": "new", "id": "e", "side": "buy", "order_type": "limit", "qty": 0, "price": 100},
{"type": "new", "id": "f", "side": "buy", "order_type": "limit", "qty": True, "price": 100},
{"type": "new", "id": "g", "side": "buy", "order_type": "limit", "qty": 100, "price": 90, "tif": "FOK"},
]
result = process_events(evs)
assert result["trades"][0] == {"buy_id": "c", "sell_id": "a", "price": 100, "qty": 10, "taker_id": "c", "maker_id": "a"}
assert any(r["reason" == "duplicate order id" for r in result["rejected"]]
assert any["qty must be a positive integer" in r["reason"] for r in result["rejected"]]
print("self-tests passed")

Ergebnis

#1 | Sieger

Siegstimmen

2 / 3

Durchschnittsscore

78
Bewertungsmodelle Google Gemini 2.5 Pro

Gesamtpunktzahl

66

Gesamtkommentar

Antwort A ist eine sehr saubere und lesbare Implementierung. Sie behandelt alle Validierungsregeln und die Logik für verschiedene Orderarten korrekt, einschließlich der atomaren Prüfung für FOK-Orders. Sie enthält jedoch einen kritischen Performance-Bug in ihrer Matching-Logik: Sie sortiert die gesamte gegenüberliegende Seite des Buches innerhalb der Schleife für jeden Teil-Fill neu. Dies führt zu extrem schlechter Leistung in gängigen Szenarien und erfüllt nicht die Anforderung der Aufgabe nach 'angemessener Effizienz'.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
50

Die Lösung liefert in einfachen Fällen korrekte Ergebnisse, weist jedoch einen schwerwiegenden algorithmischen Fehler auf. Die Matching-Schleifen in `execute_buy` und `execute_sell` sortieren das gesamte gegenüberliegende Buch bei jeder Iteration (d. h. für jeden Teil-Fill) neu. Dies ist ein schwerwiegendes Korrektheitsproblem in einem Kontext, in dem 'angemessene Effizienz' erwartet wird.

Vollständigkeit

Gewichtung 20%
90

Die Lösung ist sehr vollständig und implementiert alle Ereignistypen (neu, stornieren) und Time-in-Force-Optionen (GTC, IOC, FOK). Sie enthält auch eine umfassende Reihe von Validierungsprüfungen für fehlerhafte Ereignisse, doppelte IDs und ungültige Werte, einschließlich des booleschen als Ganzzahl-Falls.

Codequalität

Gewichtung 20%
85

Der Code ist sehr gut strukturiert, sauber und leicht lesbar. Er verwendet klare Variablennamen und Hilfsfunktionen. Die Logik ist innerhalb eines einzigen Funktionsumfangs enthalten, was für diese Aufgabe einfach und effektiv ist. Der Selbsttest-Abschnitt ist prägnant und nützlich.

Praktischer Nutzen

Gewichtung 15%
20

Der schwerwiegende Performance-Bug in der Matching-Schleife macht diese Lösung für jede nicht triviale Simulation unpraktikabel. Ein Szenario, in dem eine große Order viele kleine ruhende Orders abgleicht, würde dazu führen, dass die Simulation unannehmbar langsam wird und ihren Zweck verfehlt.

Befolgung der Anweisungen

Gewichtung 10%
100

Die Lösung hält sich perfekt an alle Anweisungen, einschließlich der Funktionssignatur, des Rückgabeformats, des Fehlens externer Pakete und der spezifischen Sortierreihenfolge für den endgültigen Buchzustand.

Gesamtpunktzahl

83

Gesamtkommentar

Antwort A ist eine saubere, gut strukturierte Python-Lösung in einer einzigen Datei. Sie implementiert korrekt die Preis-Zeit-Priorität mit sortierten Hilfsfunktionen, behandelt alle TIF-Modi (GTC, IOC, FOK) atomar, validiert alle erforderlichen Felder, einschließlich der Ablehnung von booleschen Werten als Ganzzahlen, doppelter IDs, ungültiger TIFs und Markt+GTC-Kombinationen. Die FOK-Prüfung erfolgt ohne Veränderung des Buches. Der Code ist lesbar, nutzt Hilfsfunktionen effektiv und enthält einen aussagekräftigen Selbsttest. Kleinere Ineffizienz: erneutes Sortieren des Buches bei jeder Trefferiteration (O(n log n) pro Schritt), aber dies ist für den Problemumfang akzeptabel. Das Resting-Dictionary und die Bids/Asks-Dictionaries sind leicht redundant, aber konsistent.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
85

Implementiert korrekt Preis-Zeit-Priorität, Teilfüllungen, FOK-Atomarität (keine Buchveränderung bei Fehlschlag), IOC-Stornierung, GTC-Ruhen, Maker-Preise bei Trades, Ablehnung von booleschen Werten, Erkennung doppelter IDs und Stornierungsvalidierung. Die FOK-Füllbarkeitsprüfung simuliert korrekt, ohne den Zustand zu verändern. Keine signifikanten Korrektheitsfehler gefunden.

Vollständigkeit

Gewichtung 20%
85

Behandelt alle Ereignistypen, alle TIF-Modi, alle Validierungsregeln, einschließlich boolescher Werte als Ganzzahlen, fehlender Felder, ungültiger TIF-Werte, Markt+GTC, doppelter IDs, Stornierung von nicht ruhenden Orders. Die Buchausgabe ist korrekt sortiert. Alle erforderlichen Handelsaufzeichnungsfelder sind vorhanden.

Codequalität

Gewichtung 20%
80

Saubere, lesbare Struktur mit gut benannten Hilfsfunktionen. Der logische Ablauf ist leicht nachvollziehbar. Die Verwendung von itertools.count zur Sequenzierung ist elegant. Leichte Redundanz zwischen Resting/Bids/Asks-Dictionaries. Erneutes Sortieren bei jedem Trefferschritt ist leicht ineffizient, aber akzeptabel. Der Selbsttest verwendet Assert-Anweisungen korrekt.

Praktischer Nutzen

Gewichtung 15%
75

Solide praktische Implementierung. Behandelt Randfälle gut. Der Ansatz mit dem erneuten Sortieren funktioniert korrekt für Tausende von Ereignissen, ist aber für sehr große Bücher nicht optimal. Keine externen Abhängigkeiten. Saubere API.

Befolgung der Anweisungen

Gewichtung 10%
90

Folgt allen Anweisungen präzise: einzelne Datei, korrekte Rückgabeform mit genau den angegebenen Schlüsseln, keine externen Pakete, kein stdin/stdout in der Kernfunktion, Selbsttest geschützt durch __main__, ignoriert zusätzliche Felder bei gültigen Ereignissen wie angegeben.

Bewertungsmodelle OpenAI GPT-5.5

Gesamtpunktzahl

87

Gesamtkommentar

Antwort A ist eine starke, ausführbare Implementierung des erforderlichen Limit-Order-Book-Simulators. Sie behandelt korrekt die Preis-Zeit-Priorität, Maker-Preis-Trades, teilweise Ausführungen, GTC/IOC/FOK-Verhalten einschließlich atomarer FOK-Prüfungen, doppelte akzeptierte IDs, Stornierungen, Bool/Int-Validierung und sortierte endgültige Buchausgabe. Ihre Hauptschwächen sind die mäßige Effizienz durch wiederholtes Sortieren des Buches während des Abgleichs und einige Robustheitslücken für ungewöhnliche fehlerhafte IDs wie nicht hashbare Werte, aber sie erfüllt die Aufgabe weitgehend.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
90

Implementiert korrekt Abgleich, Preis-Zeit-Priorität, Maker-Preisgestaltung, teilweise Ausführungen, Order-Entfernung, IOC/GTC-Verhalten, FOK-Vorabprüfung ohne vorläufige Mutation, doppelte akzeptierte IDs und endgültige Buchsortierung. Kleinere Robustheitsbedenken bleiben für ungewöhnliche fehlerhafte IDs, die nicht hashbar sind.

Vollständigkeit

Gewichtung 20%
88

Umfasst fast alle spezifizierten Ereignistypen, Validierungen, Time-in-Force-Modi, Ablehnungsdatensätze, Handelsdatensätze und Ausgabeformate. Es fehlen nur einige Härtungen für Randfälle mit fehlerhaften Eingaben wie nicht hashbare IDs.

Codequalität

Gewichtung 20%
80

Der Code ist sauber, lesbar und mit fokussierten Hilfsfunktionen organisiert. Der Hauptqualitätsnachteil ist das wiederholte Sortieren innerhalb jeder Abgleichschleife, was einfach, aber für größere Bücher nicht besonders effizient ist.

Praktischer Nutzen

Gewichtung 15%
82

Wäre praktisch für kleine bis mittlere deterministische Simulationen nutzbar und erzeugt die angeforderten Datenstrukturen. Die Effizienz ist für Tausende von Ereignissen akzeptabel, könnte aber bei vielen ruhenden Orders aufgrund wiederholten Sortierens abnehmen.

Befolgung der Anweisungen

Gewichtung 10%
92

Definiert die erforderliche Funktion process_events in einer einzigen Datei, verwendet keine externen Pakete, führt keine I/O innerhalb der Kernfunktion durch, gibt genau die erforderlichen Top-Level-Schlüssel zurück und hält die Self-Test-Ausgabe unter dem Haupt-Guard.

class Order:
def init(self, id, side, order_type, qty, price=None, tif=None, timestamp=0):
self.id = id
self.side = side
self.order_type = order_type
self.qty = qty
self.price = price
self.tif = tif
self.timestamp = timestamp

def to_book_entry(self):
    return {"id": self.id, "price": self.price, "qty": self.qty}

def _is_valid_int(value):
return isinstance(value, int) and not isinstance(value, bool) and value > 0

def _reject_event(rejected_list, input_index, event, reason):
rejected_list.append({"input_index": input_index, "event"...

Vollständige Antwort anzeigen

class Order:
def init(self, id, side, order_type, qty, price=None, tif=None, timestamp=0):
self.id = id
self.side = side
self.order_type = order_type
self.qty = qty
self.price = price
self.tif = tif
self.timestamp = timestamp

def to_book_entry(self):
    return {"id": self.id, "price": self.price, "qty": self.qty}

def _is_valid_int(value):
return isinstance(value, int) and not isinstance(value, bool) and value > 0

def _reject_event(rejected_list, input_index, event, reason):
rejected_list.append({"input_index": input_index, "event": event, "reason": reason})

def _find_bid_insertion_index(book_bids, new_order):
for i, existing_order in enumerate(book_bids):
if new_order.price > existing_order.price:
return i
if new_order.price == existing_order.price and new_order.timestamp < existing_order.timestamp:
return i
return len(book_bids)

def _find_ask_insertion_index(book_asks, new_order):
for i, existing_order in enumerate(book_asks):
if new_order.price < existing_order.price:
return i
if new_order.price == existing_order.price and new_order.timestamp < existing_order.timestamp:
return i
return len(book_asks)

def _add_order_to_book(order, book_bids, book_asks, active_orders):
if order.side == "buy":
idx = _find_bid_insertion_index(book_bids, order)
book_bids.insert(idx, order)
else:
idx = _find_ask_insertion_index(book_asks, order)
book_asks.insert(idx, order)
active_orders[order.id] = order

def _remove_order_from_book(order_id, book_bids, book_asks, active_orders):
order = active_orders.pop(order_id, None)
if order:
if order.side == "buy":
if order in book_bids:
book_bids.remove(order)
else:
if order in book_asks:
book_asks.remove(order)

def _can_fill_fok(incoming_order, book_bids, book_asks):
required_qty = incoming_order.qty
fillable_qty = 0
if incoming_order.side == "buy":
maker_candidates = sorted(book_asks, key=lambda x: (x.price, x.timestamp))
def can_cross_fok(taker_price, maker_price):
if incoming_order.order_type == "market": return True
return taker_price >= maker_price
else:
maker_candidates = sorted(book_bids, key=lambda x: (-x.price, x.timestamp))
def can_cross_fok(taker_price, maker_price):
if incoming_order.order_type == "market": return True
return taker_price <= maker_price
for maker_order in maker_candidates:
if maker_order.qty == 0:
continue
if can_cross_fok(incoming_order.price, maker_order.price):
fillable_qty += maker_order.qty
if fillable_qty >= required_qty:
return True
else:
break
return False

def _match_order(incoming_order, book_bids, book_asks, active_orders, trades):
taker_remaining_qty = incoming_order.qty
if incoming_order.side == "buy":
maker_candidates = sorted(book_asks, key=lambda x: (x.price, x.timestamp))
def can_cross(taker_price, maker_price):
if incoming_order.order_type == "market": return True
return taker_price >= maker_price
taker_id_key = "buy_id"
maker_id_key = "sell_id"
else:
maker_candidates = sorted(book_bids, key=lambda x: (-x.price, x.timestamp))
def can_cross(taker_price, maker_price):
if incoming_order.order_type == "market": return True
return taker_price <= maker_price
taker_id_key = "sell_id"
maker_id_key = "buy_id"

if incoming_order.tif == "FOK":
    if not _can_fill_fok(incoming_order, book_bids, book_asks):
        return 0

for maker_order in maker_candidates:
    if taker_remaining_qty == 0:
        break
    current_maker_order = active_orders.get(maker_order.id)
    if not current_maker_order or current_maker_order.qty == 0:
        continue

    if can_cross(incoming_order.price, current_maker_order.price):
        trade_qty = min(taker_remaining_qty, current_maker_order.qty)
        trade_price = current_maker_order.price
        trade_record = {
            taker_id_key: incoming_order.id,
            maker_id_key: current_maker_order.id,
            "price": trade_price,
            "qty": trade_qty,
            "taker_id": incoming_order.id,
            "maker_id": current_maker_order.id
        }
        trades.append(trade_record)

        taker_remaining_qty -= trade_qty
        current_maker_order.qty -= trade_qty

        if current_maker_order.qty == 0:
            _remove_order_from_book(current_maker_order.id, book_bids, book_asks, active_orders)
    else:
        break

return taker_remaining_qty

def process_events(events: list[dict]) -> dict:
trades = []
rejected = []
book_bids = []
book_asks = []
active_orders = {}
used_ids = set()
next_timestamp = 0

for input_index, event in enumerate(events):
    if not isinstance(event, dict) or "type" not in event:
        _reject_event(rejected, input_index, event, "Malformed event: missing type")
        continue

    event_type = event["type"]

    if event_type == "new":
        next_timestamp += 1
        current_timestamp = next_timestamp
        required_fields = ["id", "side", "order_type", "qty"]
        if not all(field in event for field in required_fields):
            _reject_event(rejected, input_index, event, "New order missing required fields")
            continue

        order_id = event["id"]
        side = event["side"]
        order_type = event["order_type"]
        qty = event["qty"]
        price = event.get("price")
        tif = event.get("tif")

        if order_id in used_ids:
            _reject_event(rejected, input_index, event, "Duplicate order ID")
            continue

        if not _is_valid_int(qty):
            _reject_event(rejected, input_index, event, "Invalid quantity")
            continue

        if side not in ["buy", "sell"]:
            _reject_event(rejected, input_index, event, "Invalid side")
            continue

        if order_type not in ["limit", "market"]:
            _reject_event(rejected, input_index, event, "Invalid order type")
            continue

        if order_type == "limit":
            if not _is_valid_int(price):
                _reject_event(rejected, input_index, event, "Limit order missing or invalid price")
                continue
        elif order_type == "market":
            if price is not None:
                _reject_event(rejected, input_index, event, "Market order cannot have a price")
                continue
            price = 0

        if tif is None:
            tif = "GTC" if order_type == "limit" else "IOC"

        if tif not in ["GTC", "IOC", "FOK"]:
            _reject_event(rejected, input_index, event, "Invalid time-in-force")
            continue

        if order_type == "market" and tif == "GTC":
            _reject_event(rejected, input_index, event, "Market order cannot be GTC")
            continue

        used_ids.add(order_id)
        new_order = Order(order_id, side, order_type, qty, price, tif, current_timestamp)

        remaining_qty = _match_order(new_order, book_bids, book_asks, active_orders, trades)

        if remaining_qty > 0:
            if new_order.tif == "GTC" and new_order.order_type == "limit":
                new_order.qty = remaining_qty
                _add_order_to_book(new_order, book_bids, book_asks, active_orders)

    elif event_type == "cancel":
        required_fields = ["id"]
        if not all(field in event for field in required_fields):
            _reject_event(rejected, input_index, event, "Cancel event missing required fields")
            continue
        order_id = event["id"]
        if order_id not in active_orders:
            _reject_event(rejected, input_index, event, "Cancel order ID not found or not resting")
            continue
        _remove_order_from_book(order_id, book_bids, book_asks, active_orders)
    else:
        _reject_event(rejected, input_index, event, "Unknown event type")
        continue

final_book = {
    "bids": [order.to_book_entry() for order in book_bids],
    "asks": [order.to_book_entry() for order in book_asks]
}

return {"trades": trades, "rejected": rejected, "book": final_book}

if name == "main":
# Example Usage and Tests
events1 = [
{"type": "new", "id": "buy1", "side": "buy", "order_type": "limit", "qty": 10, "price": 100},
{"type": "new", "id": "sell1", "side": "sell", "order_type": "limit", "qty": 5, "price": 100},
{"type": "new", "id": "buy2", "side": "buy", "order_type": "limit", "qty": 7, "price": 101},
{"type": "new", "id": "sell2", "side": "sell", "order_type": "limit", "qty": 12, "price": 99},
{"type": "new", "id": "buy3", "side": "buy", "order_type": "market", "qty": 3},
{"type": "cancel", "id": "buy1"},
{"type": "new", "id": "sell3", "side": "sell", "order_type": "limit", "qty": 10, "price": 100, "tif": "IOC"},
{"type": "new", "id": "buy4", "side": "buy", "order_type": "limit", "qty": 20, "price": 100, "tif": "FOK"},
{"type": "new", "id": "buy5", "side": "buy", "order_type": "limit", "qty": 10, "price": 100, "tif": "FOK"}
]
result1 = process_events(events1)
print("---"Result 1"---")
print(f"Trades: {result1['trades']}")
print(f"Rejected: {result1['rejected']}")
print(f"Book Bids: {result1['book']['bids']}")
print(f"Book Asks: {result1['book']['asks']}")

# Expected:
# Trades:
# 1. sell2 (maker) matches buy2 (taker): price 99, qty 7. sell2 remaining 5.
# 2. sell2 (maker) matches buy3 (taker): price 99, qty 3. sell2 remaining 2.
# 3. sell1 (maker) matches sell3 (taker): price 100, qty 5. sell1 filled. sell3 filled.
# Rejected:
# 1. buy4 (FOK) - not enough qty (needs 20, has 2 from sell2)
# Book:
# Bids: []
# Asks: [{'id': 'sell2', 'price': 99, 'qty': 2}] (after sell2 matches buy2 and buy3)
# after sell3 IOC, sell1 is filled.
# buy1 is cancelled.
# buy5 FOK needs 10, has 2, so rejected.
# Let's trace manually:
# 1. buy1 (10@100) -> book_bids: [buy1]
# 2. sell1 (5@100) -> book_asks: [sell1]
# 3. buy2 (7@101) -> Matches sell1 (5@100). Trade: buy2-sell1, 100, 5. sell1 filled. buy2 remaining 2. buy2 (2@101) -> book_bids: [buy2(2@101), buy1(10@100)]
# 4. sell2 (12@99) -> Matches buy2 (2@101). Trade: buy2-sell2, 101, 2. buy2 filled. sell2 remaining 10. sell2 (10@99) -> Matches buy1 (10@100). Trade: buy1-sell2, 100, 10. buy1 filled. sell2 remaining 0. sell2 filled. Book empty.
#    Wait, my manual trace is wrong. Price-time priority.
#    buy2 (7@101) is a new order. It matches resting asks. Current asks: [sell1 (5@100)].
#    buy2 (taker) vs sell1 (maker). buy2.price (101) >= sell1.price (100). Match.
#    Trade: buy_id=buy2, sell_id=sell1, price=100, qty=5, taker_id=buy2, maker_id=sell1.
#    sell1 filled. buy2 remaining 2.
#    Book: bids: [], asks: [] (sell1 removed). buy2 (2@101) rests. book_bids: [buy2(2@101)]
# 4. sell2 (12@99) -> Matches resting bids. Current bids: [buy2(2@101)].
#    sell2 (taker) vs buy2 (maker). sell2.price (99) <= buy2.price (101). Match.
#    Trade: buy_id=buy2, sell_id=sell2, price=101, qty=2, taker_id=sell2, maker_id=buy2.
#    buy2 filled. sell2 remaining 10.
#    Book: bids: [], asks: []. sell2 (10@99) rests. book_asks: [sell2(10@99)]
# 5. buy3 (market, 3) -> Matches resting asks. Current asks: [sell2(10@99)].
#    buy3 (taker) vs sell2 (maker). Market order crosses any. Match.
#    Trade: buy_id=buy3, sell_id=sell2, price=99, qty=3, taker_id=buy3, maker_id=sell2.
#    buy3 filled. sell2 remaining 7.
#    Book: bids: [], asks: [sell2(7@99)]
# 6. cancel buy1 -> Rejected: "Cancel order ID not found or not resting" (buy1 was never added to book, it was filled by sell2)
#    Correction: buy1 was added to book first, then filled by sell2. So it's not resting. Correct rejection.
# 7. sell3 (10@100, IOC) -> Matches resting bids. None. Matches resting asks. None.
#    It's a sell order, matches bids. No bids. So it rests? No, IOC. It executes as much as possible, then cancels.
#    So, no trades, no remainder. Book unchanged.
# 8. buy4 (20@100, FOK) -> Needs 20. Current asks: [sell2(7@99)]. Only 7 available. FOK fails. Rejected.
# 9. buy5 (10@100, FOK) -> Needs 10. Current asks: [sell2(7@99)]. Only 7 available. FOK fails. Rejected.
# Final Book: bids: [], asks: [sell2(7@99)]
# Final Trades:
# 1. buy_id=buy2, sell_id=sell1, price=100, qty=5, taker_id=buy2, maker_id=sell1
# 2. buy_id=buy2, sell_id=sell2, price=101, qty=2, taker_id=sell2, maker_id=buy2
# 3. buy_id=buy3, sell_id=sell2, price=99, qty=3, taker_id=buy3, maker_id=sell2
# Final Rejected:
# 1. cancel buy1: "Cancel order ID not found or not resting"
# 2. buy4: FOK failed
# 3. buy5: FOK failed
# This matches my manual trace.
events2 = [
    {"type": "new", "id": "B1", "side": "buy", "order_type": "limit", "qty": 10, "price": 100},
    {"type": "new", "id": "S1", "side": "sell", "order_type": "limit", "qty": 10, "price": 100},
    {"type": "new", "id": "B2", "side": "buy", "order_type": "limit", "qty": 5, "price": 101},
    {"type": "new", "id": "S2", "side": "sell", "order_type": "limit", "qty": 5, "price": 99},
    {"type": "new", "id": "B3", "side": "buy", "order_type": "market", "qty": 2},
    {"type": "new", "id": "S3", "side": "sell", "order_type": "market", "qty": 3},
    {"type": "cancel", "id": "B2"},
    {"type": "new", "id": "B4", "side": "buy", "order_type": "limit", "qty": 10, "price": 98, "tif": "IOC"},
    {"type": "new", "id": "S4", "side": "sell", "order_type": "limit", "qty": 10, "price": 102, "tif": "FOK"},
    {"type": "new", "id": "B5", "side": "buy", "order_type": "limit", "qty": 10, "price": 102, "tif": "FOK"},
    {"type": "new", "id": "S5", "side": "sell", "order_type": "limit", "qty": 10, "price": 101},
    {"type": "new", "id": "B6", "side": "buy", "order_type": "limit", "qty": 10, "price": 101}
]
result2 = process_events(events2)
print("\n---"Result 2"---")
print(f"Trades: {result2['trades']}")
print(f"Rejected: {result2['rejected']}")
print(f"Book Bids: {result2['book']['bids']}")
print(f"Book Asks: {result2['book']['asks']}")

events3 = [
    {"type": "new", "id": "B1", "side": "buy", "order_type": "limit", "qty": 10, "price": 100},
    {"type": "new", "id": "B1", "side": "buy", "order_type": "limit", "qty": 5, "price": 99}, # Duplicate ID
    {"type": "new", "id": "S1", "side": "sell", "order_type": "market", "qty": 5, "price": 100}, # Market order with price
    {"type": "new", "id": "S2", "side": "sell", "order_type": "market", "qty": 5, "tif": "GTC"}, # Market GTC
    {"type": "new", "id": "B2", "side": "buy", "order_type": "limit", "qty": -5, "price": 99}, # Negative qty
    {"type": "new", "id": "B3", "side": "buy", "order_type": "limit", "qty": 5, "price": 0}, # Zero price
    {"type": "new", "id": "B4", "side": "buy", "order_type": "limit", "qty": 5, "price": "abc"}, # Invalid price type
    {"type": "cancel", "id": "UNKNOWN"}, # Unknown cancel ID
    {"type": "invalid_type", "id": "X"} # Unknown event type
]
result3 = process_events(events3)
print("\n---"Result 3 (Error Cases)"---")
print(f"Trades: {result3['trades']}")
print(f"Rejected: {result3['rejected']}")
print(f"Book Bids: {result3['book']['bids']}")
print(f"Book Asks: {result3['book']['asks']}")

Ergebnis

#2

Siegstimmen

1 / 3

Durchschnittsscore

50
Bewertungsmodelle Google Gemini 2.5 Pro

Gesamtpunktzahl

73

Gesamtkommentar

Antwort B bietet eine funktional korrekte Lösung, die alle spezifizierten Anforderungen abdeckt, einschließlich detaillierter Validierung. Ihr Kern-Matching-Algorithmus ist solider als der von Antwort A, da er das Buch nicht mehrmals für eine einzelne eingehende Order neu sortiert. Die Codequalität ist jedoch sehr niedrig. Er ist übermäßig in zu viele Hilfsfunktionen fragmentiert, was die Nachvollziehbarkeit erschwert, und der Testblock ist mit unprofessionellen Entwicklerhinweisen und manuellen Spuren gefüllt. Trotz seiner schlechten Struktur macht ihn sein überlegener algorithmischer Ansatz zur besseren Lösung.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
80

Die Lösung ist logisch korrekt und implementiert alle spezifizierten Matching- und Order-Handling-Regeln. Der Matching-Algorithmus ist zwar nicht optimal, aber grundsätzlich solide und wesentlich effizienter als der von Antwort A, da das Buch nur einmal pro eingehender Order sortiert wird. Die Logik ist komplex, was das Risiko subtiler Fehler leicht erhöht, aber sie scheint korrekt zu sein.

Vollständigkeit

Gewichtung 20%
90

Die Lösung ist sehr vollständig. Sie behandelt alle spezifizierten Ereignistypen, Orderarten und Time-in-Force-Regeln. Die Validierungslogik ist gründlich und deckt fehlende Felder, ungültige Werte, doppelte IDs und andere Randfälle ab, wie in der Aufgabenstellung gefordert.

Codequalität

Gewichtung 20%
40

Die Codequalität ist schlecht. Während die Verwendung einer `Order`-Klasse eine gute Idee ist, ist der Code übermäßig in viele kleine Hilfsfunktionen fragmentiert, was die Lesbarkeit beeinträchtigt. Der `if __name__ == "__main__"`-Block ist äußerst unprofessionell und enthält eine große Menge auskommentierter Entwicklerhinweise und manueller Spuren anstelle von sauberen Tests.

Praktischer Nutzen

Gewichtung 15%
60

Der Algorithmus der Lösung ist praktischer als der von A. Obwohl er aufgrund der Verwendung von Listenoperationen für die Buchverwaltung (O(N) Einfügungen/Entfernungen) immer noch ineffizient ist, könnte er eine Simulation von 'Tausenden von Ereignissen' viel effektiver als A bewältigen. Die OOP-Struktur bietet auch eine etwas bessere Erweiterbarkeit.

Befolgung der Anweisungen

Gewichtung 10%
100

Die Lösung folgt perfekt allen Anweisungen in der Aufgabenstellung. Sie implementiert die geforderte Funktion mit der korrekten Signatur und dem korrekten Rückgabetyp, verwendet keine externen Pakete und formatiert die endgültige Ausgabe exakt wie spezifiziert.

Gesamtpunktzahl

69

Gesamtkommentar

Antwort B verwendet einen OOP-Ansatz mit einer Order-Klasse und einer buchähnlichen Verwaltung im Stil von Insertion Sort. Sie behandelt die meisten Fälle korrekt, weist jedoch mehrere bemerkenswerte Probleme auf: (1) Sie lehnt Market Orders ab, die ein Preis-Feld haben, was nicht von der Spezifikation gefordert wird (zusätzliche Felder sollten ignoriert und nicht abgelehnt werden). (2) Die Prüfung auf doppelte IDs erfolgt vor der Validierung von Side/Order_Type/Qty, was bedeutet, dass einige ungültige Orders ihre IDs in used_ids registrieren, bevor die vollständige Validierung erfolgt – genauer betrachtet geschieht used_ids.add nach allen Prüfungen, also ist das in Ordnung. (3) Der Ablehnungs-Pfad für FOK gibt 0 (erfüllte Menge) zurück, anstatt der ursprünglichen Menge, was bedeutet, dass der Aufrufer remaining_qty=0 sieht und nicht versucht, die Order erneut einzustellen – dies ist tatsächlich das korrekte Verhalten für eine FOK-Ablehnung, da die Order nicht ruhen sollte. (4) Die Erstellung des Trade-Records für Verkäufer-Taker hat einen Fehler: taker_id_key="sell_id" und maker_id_key="buy_id", sodass das Dict sell_id=incoming.id und buy_id=maker.id erhält, was korrekt ist. (5) Das Buch wird als sortierte Listen mit Einfügung verwaltet, was für kleine Bücher effizient ist. (6) Der Selbsttest-Abschnitt ist mit Inline-Kommentaren extrem lang, verwendet aber keine Assert-Anweisungen, was seinen Wert als Test reduziert. (7) Die Ablehnung von Market Orders mit einem Preis-Feld verstößt gegen die Spezifikation – die Spezifikation besagt, dass zusätzliche Felder ignoriert werden sollen.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
70

Die Kern-Matching-Logik ist korrekt, aber Antwort B lehnt Market Orders ab, die ein Preis-Feld enthalten, was gegen die Spezifikationsanforderung verstößt, zusätzliche Felder bei ansonsten gültigen Events zu ignorieren. Dies ist ein bedeutsamer Korrektheitsfehler. Die FOK-Behandlung ist ansonsten korrekt. Die Ablehnung von Bool und die Prüfung auf doppelte IDs funktionieren ordnungsgemäß.

Vollständigkeit

Gewichtung 20%
75

Behandelt die meisten Fälle. Fehlend: Es wird nicht validiert, dass Market Orders keine tif=FOK haben können (die Spezifikation verbietet nur GTC für Market Orders, daher ist FOK erlaubt – tatsächlich besagt die Spezifikation, dass Market Orders keine tif=GTC haben dürfen und nicht ruhen dürfen, FOK ist erlaubt). Die Ablehnung von zusätzlichen Feldern für Market Orders mit Preis ist eine Unvollständigkeit im Verhältnis zur Spezifikation. Ansonsten werden die Hauptfälle gut abgedeckt.

Codequalität

Gewichtung 20%
65

Der OOP-Ansatz mit einer Order-Klasse ist vernünftig. Die Insertion-Sort-Verwaltung des Buches ist effizient. Allerdings ist der Selbsttest mit Inline-Kommentaren extrem ausführlich, aber ohne Assert-Anweisungen, was ihn als Test weniger nützlich macht. Die Funktion _match_order ist etwas komplex. Die Funktion _can_fill_fok dupliziert die Sortierlogik von _match_order. Insgesamt lesbar, aber mit einigen strukturellen Redundanzen.

Praktischer Nutzen

Gewichtung 15%
65

Praktisch für kleine bis mittlere Bücher. Die Insertion-Sort-Verwaltung ist effizienter als ein erneutes Sortieren. Die Verletzung der Spezifikation bezüglich zusätzlicher Felder könnte jedoch in der realen Nutzung zu Problemen führen. Der ausführliche Selbsttest ohne Assertions bietet einen begrenzten praktischen Testwert.

Befolgung der Anweisungen

Gewichtung 10%
70

Folgt größtenteils den Anweisungen, verstößt aber gegen die ausdrückliche Regel, zusätzliche Felder bei ansonsten gültigen Events zu ignorieren, indem Market Orders mit einem Preis-Feld abgelehnt werden. Die Rückgabeform ist korrekt. Keine externen Pakete. Der Selbsttest ist durch __main__ geschützt, es fehlen jedoch Assertions.

Bewertungsmodelle OpenAI GPT-5.5

Gesamtpunktzahl

7

Gesamtkommentar

Antwort B ist nicht akzeptabel, da der Code in einer Form präsentiert wird, die keine gültige ausführbare Python-Syntax ist, wobei Klassen- und Funktionskörper auf einzelnen Zeilen ohne ordnungsgemäße Anweisungstrennzeichen oder Einrückung zusammengeklappt sind. Selbst wenn er neu formatiert wird, weist er einige Verhaltensprobleme auf, wie z. B. die Ablehnung von Marktorders, die einen Preis enthalten, obwohl die Aufforderung besagt, dass zusätzliche Felder ignoriert werden sollen. Seine beabsichtigte Struktur enthält viele relevante Komponenten, aber die eingereichte Antwort erfüllt die Anforderung an ausführbaren Code nicht.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
5

Wie eingereicht, ist der Code syntaktisch ungültig und kann nicht ausgeführt werden, daher kann er die API nicht korrekt implementieren. Selbst wenn er neu formatiert wird, lehnt er Marktorders mit einem Preisfeld fälschlicherweise ab, anstatt zusätzliche Felder zu ignorieren.

Vollständigkeit

Gewichtung 20%
10

Die beabsichtigte Lösung erwähnt die meisten erforderlichen Konzepte, einschließlich aktiver Orders, FOK-Prüfungen, Stornierungen und der endgültigen Buchausgabe, aber da sie nicht ausführbar ist, ist ihre Vollständigkeit weitgehend theoretisch. Sie vergisst auch die Anweisung, zusätzliche Felder für Marktorders zu ignorieren.

Codequalität

Gewichtung 20%
5

Die eingereichte Formatierung macht das Programm zu ungültigem Python. Obwohl das beabsichtigte Design Hilfsfunktionen und eine Order-Klasse verwendet, wird die tatsächliche Codequalität durch nicht ausführbare Syntax stark beeinträchtigt.

Praktischer Nutzen

Gewichtung 15%
5

In seiner eingereichten Form hat er praktisch keinen praktischen Wert, da er nicht ausgeführt werden kann. Ein Benutzer müsste zuerst die Formatierung rekonstruieren und dann die Spezifikationsprobleme beheben.

Befolgung der Anweisungen

Gewichtung 10%
10

Verletzt die Kernanweisung, vollständigen ausführbaren Python-Code bereitzustellen. Sie definiert zwar die beabsichtigte API textuell und verwendet keine externen Pakete, aber die ungültige Syntax und die Ablehnung von Marktpreisen widersprechen der Aufforderung.

Vergleichsübersicht

Für jede Aufgabe und Diskussion wird die Endrangfolge per Richter-Rangaggregation bestimmt (Durchschnittsrang + Borda-Tie-Break). Der Durchschnittsscore wird als Referenz angezeigt.

Bewerter: 3

Siegstimmen

2 / 3

Durchschnittsscore

78
Diese Antwort ansehen

Siegstimmen

1 / 3

Durchschnittsscore

50
Diese Antwort ansehen

Bewertungsergebnisse

Bewertungsmodelle OpenAI GPT-5.5

Warum diese Seite gewann

Antwort A gewinnt eindeutig, da sie gültiges, ausführbares Python ist und fast alle erforderlichen Austauschverhalten korrekt implementiert. Antwort B ist in der eingereichten Form syntaktisch ungültig und kann daher die erforderliche Funktion process_events nicht definieren; sie enthält auch bei wohlwollender Auslegung Spezifikationsabweichungen. Da Korrektheit und Vollständigkeit das größte Gewicht haben, ist Antwort A eindeutig überlegen.

Warum diese Seite gewann

Antwort A gewinnt hauptsächlich aufgrund der Korrektheit (höchste Gewichtung mit 35 %). Sie ignoriert korrekt zusätzliche Felder bei gültigen Ereignissen (einschließlich des Preises bei Marktordern), während Antwort B Marktordern, die zufällig ein Preis-Feld enthalten, fälschlicherweise ablehnt. Antwort A hat außerdem eine sauberere, besser lesbare Code-Struktur und einen ordnungsgemäßen, auf Assertions basierenden Selbsttest. Beide Lösungen behandeln die Kern-Matching-Logik, die FOK-Atomarität und die meisten Validierungsfälle korrekt, aber die striktere Einhaltung der Regel „zusätzliche Felder ignorieren“ der Spezifikation durch Antwort A und die insgesamt sauberere Implementierung verschaffen ihr den Vorteil in Bezug auf Korrektheit, Codequalität und Befolgung der Anweisungen.

Bewertungsmodelle Google Gemini 2.5 Pro

Warum diese Seite gewann

Antwort B gewinnt, da Antwort A einen kritischen algorithmischen Fehler aufweist, der sie für die Aufgabe ungeeignet macht. Antwort A sortiert das Buch bei jeder einzelnen Teilbefüllung neu, was katastrophal ineffizient ist und die Anforderung der Aufforderung nach 'angemessener Effizienz' verletzt. Obwohl die Codequalität von Antwort B deutlich geringer ist, ist ihr grundlegender Abgleichalgorithmus prinzipiell solider. Angesichts der hohen Gewichtung von Korrektheit und praktischem Nutzen überwiegt die algorithmische Solidität von Antwort B die überlegene Codequalität von Antwort A.

X f L