Antwort A: Google Gemini 2.5 Pro
import sys import bisect def solve(): """ Implementiert einen versionierten Schlüssel-Wert-Speicher, der Befehle von stdin liest und Ergebnisse nach stdout schreibt. """ try: n_str = sys.stdin.readline() if not n_str: return n = int(n_str.strip()) except (ValueError, IndexError): return # Die Hauptdatenstruktur. # Ein Wörterbuch, das jeden Schlüssel auf eine Liste seiner historischen Zustände abbildet. # Jeder Zustand ist ein Tupel: (Version, Wert). # Die Liste für jeden Schlüssel wird nach Version sortiert gehalten. # Ein W...
Vollstandige Antwort anzeigen ▼
import sys import bisect def solve(): """ Implementiert einen versionierten Schlüssel-Wert-Speicher, der Befehle von stdin liest und Ergebnisse nach stdout schreibt. """ try: n_str = sys.stdin.readline() if not n_str: return n = int(n_str.strip()) except (ValueError, IndexError): return # Die Hauptdatenstruktur. # Ein Wörterbuch, das jeden Schlüssel auf eine Liste seiner historischen Zustände abbildet. # Jeder Zustand ist ein Tupel: (Version, Wert). # Die Liste für jeden Schlüssel wird nach Version sortiert gehalten. # Ein Wert von None stellt eine Löschung dar. store = {} global_version = 0 for _ in range(n): line = sys.stdin.readline() if not line: continue parts = line.strip().split() command = parts[0] if command == "SET": # Erstellt oder überschreibt einen Schlüssel mit einem Wert und erstellt eine neue Version. key, value = parts[1], parts[2] global_version += 1 if key not in store: store[key] = [] store[key].append((global_version, value)) elif command == "DELETE": # Entfernt einen Schlüssel und erstellt eine neue Version. # Dies gilt auch, wenn der Schlüssel nicht existiert. key = parts[1] global_version += 1 if key not in store: store[key] = [] store[key].append((global_version, None)) elif command == "GET": # Gibt den aktuellen Wert eines Schlüssels zurück. key = parts[1] if key not in store or not store[key]: print("NULL") else: # Der letzte Eintrag in der Historienliste ist der aktuelle Zustand. _version, value = store[key][-1] print(value if value is not None else "NULL") elif command == "GET_VERSION": # Gibt den Wert eines Schlüssels zu einer bestimmten historischen Version zurück. key, version_str = parts[1], parts[2] version = int(version_str) if version <= 0 or version > global_version: print("INVALID_VERSION") elif key not in store or not store[key]: print("NULL") else: history = store[key] # Erstellt eine Liste nur mit den Versionsnummern für eine effiziente Suche. versions = [v for v, _val in history] # Findet die Einfügestelle für die angeforderte Version. # bisect_right findet den Index, an dem die Version eingefügt würde, # um die Reihenfolge beizubehalten. Das bedeutet, alle Elemente links von diesem # Index haben Versionen kleiner oder gleich der angeforderten Version. idx = bisect.bisect_right(versions, version) if idx == 0: # Keine historische Version ist <= der angeforderten Version. print("NULL") else: # Der gewünschte Zustand befindet sich am vorherigen Index (idx - 1). _v, value = history[idx - 1] print(value if value is not None else "NULL") elif command == "HISTORY": # Gibt alle historischen Zustände für einen Schlüssel zurück. key = parts[1] if key not in store or not store[key]: print("EMPTY") else: history = store[key] result_parts = [] for v, val in history: str_val = val if val is not None else "NULL" result_parts.append(f"{v}:{str_val}") print(",".join(result_parts)) if __name__ == "__main__": solve()
Ergebnis
Siegstimmen
1 / 3
Durchschnittsscore
Gesamtpunktzahl
Gesamtkommentar
Antwort A bietet eine korrekte und vollständige Implementierung des versionierten Schlüssel-Wert-Speichers. Sie verarbeitet alle Befehle ordnungsgemäß, verwendet bisect für effiziente historische Lookups und enthält klare Kommentare und Docstrings. Sie hat jedoch ein Leistungsproblem: Bei GET_VERSION wird bei jedem Abruf eine neue Liste von Versionsnummern erstellt (`versions = [v for v, _val in history]`), was O(k) pro Abfrage ist, wobei k die Anzahl der historischen Einträge für diesen Schlüssel ist. Bei 200.000 Befehlen mit vielen historischen Abfragen könnte dies ein erhebliches Leistungsengpass sein. Sie verwendet auch readline() in einer Schleife, was bei großen Eingaben langsamer ist als das Lesen von Blöcken. Der Code prüft auch nicht korrekt auf Version <= 0 für GET_VERSION - die Spezifikation besagt, dass Versionen positive ganze Zahlen sind, und Version 0 oder negativ sollte wohl INVALID_VERSION sein, was Antwort A zwar behandelt. Insgesamt ist es eine solide Lösung mit einem bemerkenswerten Effizienzproblem.
Bewertungsdetails anzeigen ▼
Korrektheit
Gewichtung 35%Antwort A behandelt alle Befehle korrekt: SET, DELETE, GET, GET_VERSION, HISTORY. Sie verwendet ordnungsgemäß bisect_right für historische Lookups, behandelt NULL für gelöschte Schlüssel, gibt EMPTY für nie betroffene Schlüssel zurück und prüft auf ungültige Versionen, einschließlich Version <= 0. Alle in der Spezifikation genannten Randfälle scheinen korrekt behandelt zu werden.
Vollstandigkeit
Gewichtung 20%Antwort A implementiert alle fünf Befehle wie spezifiziert, behandelt alle im Prompt genannten Randfälle, einschließlich unveränderter SET-Werte, die neue Versionen erstellen, DELETE bei nicht vorhandenen Schlüsseln, die Versionen erstellen, und ordnungsgemäße HISTORY-Formatierung. Die Lösung ist vollständig und ausführbar.
Codequalitat
Gewichtung 20%Antwort A hat eine gute Codequalität mit klaren Variablennamen, einem Docstring und hilfreichen Inline-Kommentaren, die die Logik erklären. Der Code ist gut strukturiert und leicht verständlich. Die Verwendung von bisect ist sauber, obwohl die temporäre Listenerstellung in GET_VERSION ein unnötiges Muster ist.
Praktischer Nutzen
Gewichtung 15%Antwort A funktioniert korrekt, hat aber ein erhebliches Leistungsproblem: GET_VERSION erstellt bei jedem Aufruf eine neue Liste von Versionen, was sie zu O(k) pro Abfrage macht, noch vor der binären Suche. In Kombination mit zeilenweisem Lesen und einzelnen Druckaufrufen könnte diese Lösung mit der angegebenen Grenze von 200.000 Befehlen bei vielen historischen Abfragen Schwierigkeiten haben.
Befolgung der Anweisungen
Gewichtung 10%Antwort A folgt allen Anweisungen: liest von stdin, schreibt nach stdout, ist ein vollständiges ausführbares Programm in einer Datei, behandelt alle spezifizierten Befehle und Randfälle und verwendet einen effizienten Datenstrukturansatz (pro Schlüssel Verlauf-Listen mit binärer Suche).
Gesamtpunktzahl
Gesamtkommentar
Antwort A bietet eine robuste und gut strukturierte Lösung. Sie implementiert alle Befehle korrekt, behandelt Randfälle wie nicht vorhandene Schlüssel und ungültige Versionen (einschließlich nicht positiver Versionen für GET_VERSION) und verwendet effiziente Datenstrukturen und Algorithmen (wie `bisect` für historische Lookups). Die Eingabeverarbeitung ist Standard und robust für die zeilenweise Verarbeitung. Der Code ist klar, gut kommentiert und Pythonic.
Bewertungsdetails anzeigen ▼
Korrektheit
Gewichtung 35%Die Lösung implementiert alle Befehle korrekt und behandelt die angegebenen Randfälle. Sie interpretiert auch 'Versionen sind positive ganze Zahlen' korrekt, indem sie nicht positive Versionen in GET_VERSION als INVALID_VERSION behandelt, was eine robuste Interpretation der impliziten Anforderungen der Aufgabenstellung ist.
Vollstandigkeit
Gewichtung 20%Das Programm ist vollständig, ausführbar und deckt alle erforderlichen Funktionalitäten und Ein-/Ausgabeformate ab. Die Eingabeerfassung ist robust für die zeilenweise Verarbeitung.
Codequalitat
Gewichtung 20%Der Code ist gut strukturiert, verwendet klare Variablennamen und enthält hilfreiche Kommentare. Er nutzt das `bisect`-Modul für eine effiziente und Pythonic-Binärsuche, was zu saubererem und wartbarerem Code beiträgt.
Praktischer Nutzen
Gewichtung 15%Die Lösung verwendet effiziente Datenstrukturen (Dictionary von Listen von Tupeln) und Algorithmen (Binärsuche) für historische Abfragen, was sie skalierbar macht. Ihre robuste Eingabebehandlung und umfassenden Fehlerprüfungen erhöhen ihren praktischen Nutzen.
Befolgung der Anweisungen
Gewichtung 10%Die Lösung folgt sorgfältig allen expliziten Anweisungen, einschließlich Versionsregeln, Ausgabeformaten und Effizienzerwägungen. Sie interpretiert auch implizite Anforderungen korrekt, wie z. B. die Behandlung nicht positiver Versionen als ungültig.
Gesamtpunktzahl
Gesamtkommentar
Antwort A ist ein vollständiges ausführbares Programm und erfasst das Kernmodell der Versionierungshistorie korrekt für SET, DELETE, GET, GET_VERSION und HISTORY. Seine Semantik stimmt größtenteils mit der Aufforderung überein, einschließlich globaler Versionierung und der Aufzeichnung von Löschungen. Die Implementierung von GET_VERSION baut jedoch bei jeder Abfrage eine Liste von Versionsnummern neu auf, was unnötige Überlastung verursacht und die Skalierbarkeit für die angegebene große Eingabe beeinträchtigt. Sie behandelt auch nicht-positive Versionen als ungültig, was vernünftig ist, aber über positive Ganzzahlen hinaus nicht explizit gefordert wird. Insgesamt ist sie in typischen Fällen korrekt, aber weniger effizient als erwartet für intensive historische Abfragen.
Bewertungsdetails anzeigen ▼
Korrektheit
Gewichtung 35%Die Logik für SET, DELETE, GET, GET_VERSION und HISTORY ist größtenteils korrekt, einschließlich globaler Versionen und Löschmarkierungen. Historische Abfragen geben den neuesten Zustand zum oder vor dem angeforderten Zeitpunkt zurück, und ungültige zukünftige Versionen werden behandelt. Die Hauptkorrektheits-Einschränkung ist in normalen Fällen nicht funktional, sondern an Annahmen zur Randbehandlung und den Stil der Abfrageimplementierung gebunden.
Vollstandigkeit
Gewichtung 20%Die Antwort liefert ein vollständiges, funktionierendes Ein-Datei-Programm, liest von stdin, schreibt nach stdout und deckt alle erforderlichen Befehle und Ausgaben ab. Sie enthält auch das erforderliche historische Verhalten und die nur bei direkter Änderung erstellte Historie. Sie ist vollständig für die Aufgabe, mit nur geringfügiger Mehrdeutigkeit bei Randfällen bezüglich ungültiger nicht-positiver Versionen.
Codequalitat
Gewichtung 20%Der Code ist lesbar und vernünftig organisiert, mit klaren Kommentaren und unkomplizierter Kontrollfluss. Das Erstellen einer neuen Versionsliste innerhalb jedes GET_VERSION-Aufrufs ist jedoch eine vermeidbare Designschwäche, und die zeilenweise Ausgabe ist für intensive Ausgaben weniger optimiert. Die Qualität ist solide, aber nicht besonders stark für einen leistungssensiblen Benchmark.
Praktischer Nutzen
Gewichtung 15%Das Programm funktioniert für viele normale Eingaben, aber wiederholte GET_VERSION-Aufrufe bei großen Historien verursachen zusätzlichen Overhead durch das jedes Mal erneute Erstellen von Versions-Arrays. Das macht es für die im Prompt beschriebene hohe Arbeitslast weniger geeignet. Es ist als Basislinie praktisch, aber nicht ideal für die Benchmark-Beschränkungen.
Befolgung der Anweisungen
Gewichtung 10%Die Antwort folgt der Anweisung, vollständigen ausführbaren Code bereitzustellen, und hält sich eng an die angegebene Befehlssemantik und das Ausgabeformat. Sie respektiert die globale Versionierung und die Erstellung von Versionen nur bei Änderungen. Geringfügige Randbehandlungen bei ungültigen Versionen beeinträchtigen die Konformität nicht wesentlich.