Orivel Orivel
Menue oeffnen

Implementieren Sie eine TokenBucket-Rate-Limiter-Klasse

Vergleiche Modellantworten fuer diese Programmierung-Benchmark-Aufgabe und pruefe Scores, Kommentare und verwandte Beispiele.

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

X f L

Inhalt

Aufgabenubersicht

Vergleichsgenres

Programmierung

Aufgaben-Erstellermodell

Antwortende Modelle

Bewertungsmodelle

Aufgabenstellung

Implementieren Sie eine `TokenBucket`-Klasse in einer Programmiersprache Ihrer Wahl (z. B. Python, JavaScript, Java, C++). Die Klasse sollte folgendes haben: 1. Einen Konstruktor, der zwei Argumente akzeptiert: - `capacity`: Ein Integer, der die maximale Anzahl an Tokens darstellt, die der Bucket halten kann. - `refill_rate`: Eine Zahl, die die Rate angibt, mit der Tokens pro Sekunde dem Bucket hinzugefügt werden. 2. Eine Methode `allow_request()`: - Diese Methode nimmt keine Argumente. - Sie sollt...

Mehr anzeigen

Implementieren Sie eine `TokenBucket`-Klasse in einer Programmiersprache Ihrer Wahl (z. B. Python, JavaScript, Java, C++). Die Klasse sollte folgendes haben: 1. Einen Konstruktor, der zwei Argumente akzeptiert: - `capacity`: Ein Integer, der die maximale Anzahl an Tokens darstellt, die der Bucket halten kann. - `refill_rate`: Eine Zahl, die die Rate angibt, mit der Tokens pro Sekunde dem Bucket hinzugefügt werden. 2. Eine Methode `allow_request()`: - Diese Methode nimmt keine Argumente. - Sie sollte `True` zurückgeben, wenn eine Anfrage erlaubt ist (d. h. mindestens ein Token im Bucket vorhanden ist), und `False`, wenn nicht. - Wenn eine Anfrage erlaubt ist, sollte sie ein Token aus dem Bucket verbrauchen. Ihre Implementierung muss eigenständig sein und sich für die Kernlogik nicht auf externe Bibliotheken stützen. Sie sollten den Zustand des Buckets (aktuelle Anzahl an Tokens und die Zeit der letzten Überprüfung) innerhalb der Klasseninstanz verwalten.

Erganzende Informationen

Der Token-Bucket-Algorithmus ist eine gängige Methode zur Ratenbegrenzung. Er funktioniert wie folgt: - Der Bucket hat eine feste `capacity`. - Tokens werden dem Bucket mit einer konstanten `refill_rate` hinzugefügt. - Ist der Bucket voll, werden neu hinzukommende Tokens verworfen. - Jede eingehende Anfrage versucht, ein Token aus dem Bucket zu verbrauchen. - Ist ein Token verfügbar, wird die Anfrage erlaubt und die Token-Anzahl dekrementiert. - Sind keine Tokens verfügbar, wird die Anfrage abgelehnt. Dieser Algor...

Mehr anzeigen

Der Token-Bucket-Algorithmus ist eine gängige Methode zur Ratenbegrenzung. Er funktioniert wie folgt: - Der Bucket hat eine feste `capacity`. - Tokens werden dem Bucket mit einer konstanten `refill_rate` hinzugefügt. - Ist der Bucket voll, werden neu hinzukommende Tokens verworfen. - Jede eingehende Anfrage versucht, ein Token aus dem Bucket zu verbrauchen. - Ist ein Token verfügbar, wird die Anfrage erlaubt und die Token-Anzahl dekrementiert. - Sind keine Tokens verfügbar, wird die Anfrage abgelehnt. Dieser Algorithmus erlaubt Burst-Anfragen bis zur `capacity` des Buckets und drosselt anschließend die Anfragen langfristig auf die `refill_rate`. Ihre Implementierung sollte die Anzahl der hinzuzufügenden Tokens anhand der seit der letzten Verarbeitung einer Anfrage verstrichenen Zeit korrekt berechnen.

Bewertungsrichtlinie

A high-quality answer will provide a correct, robust, and well-written implementation of the `TokenBucket` class. - **Correctness:** Die Kernlogik muss korrekt implementiert sein. Dazu gehört die genaue Berechnung der hinzuzufügenden Tokens basierend auf der verstrichenen Zeit, die Sicherstellung, dass die Token-Anzahl niemals die `capacity` überschreitet, und das korrekte Verbuchen von Tokens für erlaubte Anfragen. - **Robustness:** Die Lösung sollte Randfälle behandeln, wie die allererste Anfrage, mehrere Anfrag...

Mehr anzeigen

A high-quality answer will provide a correct, robust, and well-written implementation of the `TokenBucket` class. - **Correctness:** Die Kernlogik muss korrekt implementiert sein. Dazu gehört die genaue Berechnung der hinzuzufügenden Tokens basierend auf der verstrichenen Zeit, die Sicherstellung, dass die Token-Anzahl niemals die `capacity` überschreitet, und das korrekte Verbuchen von Tokens für erlaubte Anfragen. - **Robustness:** Die Lösung sollte Randfälle behandeln, wie die allererste Anfrage, mehrere Anfragen in sehr kurzer Folge und lange Inaktivitätsperioden zwischen Anfragen. Die Berechnung der Token-Auffüllung sollte präzise sein und nicht unter kumulativen Gleitkommaungenauigkeiten leiden. - **Code Quality:** Der Code sollte sauber, lesbar und idiomatisch für die gewählte Sprache sein. Er sollte gut strukturiert sein, mit klaren Variablennamen und Kommentaren, wo die Logik nicht offensichtlich ist. - **State Management:** Die Implementierung muss ihren internen Zustand korrekt verwalten (z. B. die Anzahl der Tokens und den Zeitstempel der letzten Aktualisierung) über mehrere Aufrufe von `allow_request()` hinweg.

Antworten

import time class TokenBucket: """Ein Token-Bucket-Ratenbegrenzer. Tokens werden mit einer konstanten `refill_rate` (Tokens pro Sekunde) bis zu `capacity` hinzugefügt. Jeder Aufruf von `allow_request()` versucht, ein Token zu verbrauchen. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Maximale Anzahl von Tokens, die der Bucket aufnehmen kann. refill_rate: Anzahl der pro Sekunde zum Bucket hinzugefügten Tokens. """ self.capacity: int = capacity self.refill_rate: float = refill_rate...

Vollstandige Antwort anzeigen

import time class TokenBucket: """Ein Token-Bucket-Ratenbegrenzer. Tokens werden mit einer konstanten `refill_rate` (Tokens pro Sekunde) bis zu `capacity` hinzugefügt. Jeder Aufruf von `allow_request()` versucht, ein Token zu verbrauchen. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Maximale Anzahl von Tokens, die der Bucket aufnehmen kann. refill_rate: Anzahl der pro Sekunde zum Bucket hinzugefügten Tokens. """ self.capacity: int = capacity self.refill_rate: float = refill_rate self.tokens: float = float(capacity) # startet voll self.last_refill_time: float = time.monotonic() def _refill(self) -> None: """Fügt Tokens basierend auf der seit der letzten Auffüllung verstrichenen Zeit hinzu.""" now = time.monotonic() elapsed = now - self.last_refill_time tokens_to_add = elapsed * self.refill_rate self.tokens = min(self.capacity, self.tokens + tokens_to_add) self.last_refill_time = now def allow_request(self) -> bool: """Versucht, ein Token zu verbrauchen. Returns: True, wenn die Anfrage zugelassen wird (ein Token war verfügbar und wurde verbraucht), False andernfalls. """ self._refill() if self.tokens >= 1: self.tokens -= 1 return True return False # --------------------------------------------------------------------------- # Kurze Demo / Rauchtest # --------------------------------------------------------------------------- if __name__ == "__main__": bucket = TokenBucket(capacity=5, refill_rate=2) # 5 max, 2 Tokens/Sekunde # Burst: sollte 5 Anfragen sofort zulassen for i in range(7): result = bucket.allow_request() print(f"Anfrage {i + 1}: {'zugelassen' if result else 'abgelehnt'}") # Warten, bis sich die Tokens aufgefüllt haben print("\nSchlafe 1,5 Sekunden...") time.sleep(1.5) # sollte ca. 3 Tokens auffüllen for i in range(5): result = bucket.allow_request() print(f"Anfrage {i + 1}: {'zugelassen' if result else 'abgelehnt'}")

Ergebnis

#2

Siegstimmen

0 / 3

Durchschnittsscore

79

Gesamtpunktzahl

80

Gesamtkommentar

Antwort A bietet eine saubere, korrekte und gut dokumentierte Implementierung der TokenBucket-Klasse. Sie verwendet time.monotonic() für eine genaue Zeitmessung, füllt Tokens korrekt basierend auf der verstrichenen Zeit auf, begrenzt Tokens auf die Kapazität und verbraucht ein Token pro erlaubter Anfrage. Der Code ist lesbar mit guten Docstrings und enthält eine hilfreiche Demo/Smoke-Test. Es fehlt jedoch die Threadsicherheit (kein Sperrmechanismus), was eine bemerkenswerte Lücke für einen Ratenbegrenzer ist, der typischerweise in gleichzeitigen Umgebungen verwendet würde. Es fehlt auch die Eingabevalidierung für Konstruktorargumente.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
85

Die Kernlogik ist korrekt: Tokens werden basierend auf der verstrichenen Zeit mit time.monotonic() aufgefüllt, auf die Kapazität begrenzt und ein Token wird pro erlaubter Anfrage verbraucht. Das Fehlen von Threadsicherheit bedeutet jedoch, dass die Implementierung bei gleichzeitiger Nutzung aufgrund von Race Conditions zu falschen Ergebnissen führen kann.

Vollstandigkeit

Gewichtung 20%
75

Die Implementierung deckt alle erforderlichen Elemente ab: Konstruktor mit Kapazität und Auffüllrate, allow_request()-Methode und internes Zustandsmanagement. Sie enthält eine ausführbare Demo. Es fehlen jedoch Threadsicherheit und Eingabevalidierung, die für eine vollständige Implementierung wichtig sind.

Codequalitat

Gewichtung 20%
80

Der Code ist sauber, lesbar und gut dokumentiert mit klaren Docstrings und Typ-Hints. Variablennamen sind beschreibend. Die Trennung der Auffülllogik in eine private Methode ist gutes Design. Kleinere Abzüge für fehlende Namenskonventionen für private Attribute.

Praktischer Nutzen

Gewichtung 15%
70

Die Implementierung ist für Single-Thread-Szenarien praktisch nützlich und enthält eine hilfreiche Demo. Das Fehlen von Threadsicherheit schränkt jedoch ihren praktischen Wert in realen Anwendungen, in denen Ratenbegrenzer typischerweise in gleichzeitigen Umgebungen verwendet werden, erheblich ein.

Befolgung der Anweisungen

Gewichtung 10%
90

Folgt allen Anweisungen: Implementiert die TokenBucket-Klasse in Python, der Konstruktor akzeptiert Kapazität und Auffüllrate, allow_request() nimmt keine Argumente und gibt True/False zurück, während ein Token verbraucht wird. Verwendet nur die Standardbibliothek (time-Modul). Der Zustand wird innerhalb der Instanz verwaltet.

Bewertungsmodelle Google Gemini 2.5 Pro

Gesamtpunktzahl

82

Gesamtkommentar

Antwort A bietet eine korrekte und gut geschriebene Implementierung für eine Single-Thread-Umgebung. Ihre Stärken sind sauberer Code mit modernen Python-Typ-Hinweisen, klare Logik und eine ausgezeichnete lauffähige Demo, die ihr Verhalten verifiziert. Ihre größte Schwäche ist jedoch die fehlende Thread-Sicherheit, was sie für die meisten realen Anwendungen eines Ratenbegrenzers, bei denen gleichzeitige Anfragen üblich sind, ungeeignet macht.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
80

Die Implementierung ist in einem Single-Thread-Kontext logisch korrekt. Die Token-Auffüllberechnung und die Kapazitätsbegrenzung sind ordnungsgemäß implementiert. Sie ist jedoch in einer gleichzeitigen Umgebung nicht korrekt, was ein häufiger Anwendungsfall für diesen Algorithmus ist.

Vollstandigkeit

Gewichtung 20%
90

Die Antwort ist sehr vollständig und bietet nicht nur die Klassenimplementierung, sondern auch ein lauffähiges Demo-Skript unter `if __name__ == "__main__":`. Diese Demo zeigt effektiv das Burst- und Auffüllverhalten und macht es leicht verständlich und überprüfbar.

Codequalitat

Gewichtung 20%
85

Die Codequalität ist hoch. Sie verwendet moderne Python-Funktionen wie Typ-Hinweise, verfügt über klare Docstrings und folgt guten Namenskonventionen. Die Logik ist gut strukturiert mit einer privaten Hilfsmethode zum Auffüllen.

Praktischer Nutzen

Gewichtung 15%
60

Der praktische Wert ist begrenzt, da die Implementierung nicht Thread-sicher ist. Ratenbegrenzer werden fast immer in gleichzeitigen Umgebungen (wie Webservern) verwendet, wo diese Implementierung Race Conditions unterliegt und nicht zuverlässig funktionieren würde.

Befolgung der Anweisungen

Gewichtung 10%
100

Die Antwort folgt perfekt allen Anweisungen in der Aufforderung und implementiert die angegebene Klasse, den Konstruktor und die Methode mit der korrekten Logik. Die Lösung ist in sich geschlossen.

Bewertungsmodelle OpenAI GPT-5.4

Gesamtpunktzahl

75

Gesamtkommentar

Antwort A bietet eine korrekte und lesbare Python-Implementierung eines Token-Buckets. Sie verwendet eine monotone Uhr, verwaltet den internen Zustand ordnungsgemäß, füllt sich basierend auf der verstrichenen Zeit auf, begrenzt die Token auf die Kapazität und verbraucht ein Token pro erlaubter Anfrage. Die Hauptschwächen sind fehlende Eingabevalidierung, kein Schutz für gleichzeitigen Zugriff und ein einfacher, auf Gleitkommazahlen basierender Ansatz, ohne die im Prompt erwähnten Präzisionsbedenken zu berücksichtigen. Die enthaltene Demo ist hilfreich, aber für die Kernaufgabe nicht notwendig.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
78

Die Logik für das Nachfüllen und den Verbrauch ist korrekt: Die verstrichene Zeit wird mit einer monotonen Uhr gemessen, Token werden proportional hinzugefügt, auf die Kapazität begrenzt und ein Token wird verbraucht, wenn verfügbar. Sie behandelt die erste Verwendung und lange Leerlaufzeiten ordnungsgemäß. Die Bewertung wird zurückgehalten, da sie keine ungültigen Parameter behandelt und eine einfache Gleitkommaakkumulation ohne jegliche Abmilderung verwendet.

Vollstandigkeit

Gewichtung 20%
70

Er enthält den erforderlichen Konstruktor, den internen Zustand und die allow_request-Methode, und die Implementierung ist in sich geschlossen. Er deckt jedoch keine Parametervalidierung ab und diskutiert keine Randbedingungen wie ungültige Kapazität oder Nachfüllrate.

Codequalitat

Gewichtung 20%
76

Der Code ist sauber, lesbar und idiomatisch, mit guter Benennung und hilfreichen Docstrings. Die Struktur ist einfach und leicht zu verfolgen. Er verliert einige Punkte, da der öffentliche Zustand direkt zugänglich ist und der zusätzliche Demo-Code nicht Teil der Kernimplementierung ist.

Praktischer Nutzen

Gewichtung 15%
66

Sie ist für einfache Single-Thread-Szenarien verwendbar und demonstriert das Verhalten mit einem schnellen Smoke-Test. In realistischeren Umgebungen verringern die fehlende Validierung und Thread-Sicherheit den operativen Nutzen.

Befolgung der Anweisungen

Gewichtung 10%
88

Sie folgt der Aufgabe gut, indem sie eine in sich geschlossene TokenBucket-Klasse mit dem erforderlichen Konstruktor und dem allow_request-Verhalten implementiert. Das einzige geringfügige Problem ist die Einbeziehung von zusätzlichem Demo-Code über die angeforderte Kernantwort hinaus.

import time import threading class TokenBucket: """ Ein einfacher Token-Bucket-Ratenbegrenzer. Args: capacity (int): maximale Anzahl von Tokens im Bucket. refill_rate (float): Tokens pro Sekunde hinzugefügt. Methoden: allow_request() -> bool: gibt True zurück und verbraucht ein Token, falls verfügbar, andernfalls False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity muss > 0 sein") if refill_rate < 0: raise ValueError("refill_rate muss >= 0 sein") self.capacity = float(...

Vollstandige Antwort anzeigen

import time import threading class TokenBucket: """ Ein einfacher Token-Bucket-Ratenbegrenzer. Args: capacity (int): maximale Anzahl von Tokens im Bucket. refill_rate (float): Tokens pro Sekunde hinzugefügt. Methoden: allow_request() -> bool: gibt True zurück und verbraucht ein Token, falls verfügbar, andernfalls False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity muss > 0 sein") if refill_rate < 0: raise ValueError("refill_rate muss >= 0 sein") self.capacity = float(capacity) self.refill_rate = float(refill_rate) # aktuelle Tokens können gebrochen sein, um teilweise Auffüllung zu berücksichtigen self._tokens = float(capacity) self._last_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """Tokens basierend auf der seit der letzten Auffüllung verstrichenen Zeit auffüllen.""" now = time.monotonic() elapsed = now - self._last_time if elapsed <= 0: return added = elapsed * self.refill_rate # Tokens auf Kapazität begrenzen self._tokens = min(self.capacity, self._tokens + added) self._last_time = now def allow_request(self): """ Versuchen Sie, ein Token zu verbrauchen. Returns: bool: True, wenn ein Token verfügbar war und verbraucht wurde, andernfalls False. """ with self._lock: self._refill() if self._tokens >= 1.0: self._tokens -= 1.0 return True return False # Beispielverwendung: # bucket = TokenBucket(capacity=10, refill_rate=1.5) # 1,5 Tokens pro Sekunde # if bucket.allow_request(): # # Anfrage bearbeiten # else: # # Anfrage ablehnen oder drosseln

Ergebnis

#1 | Sieger

Siegstimmen

3 / 3

Durchschnittsscore

86

Gesamtpunktzahl

87

Gesamtkommentar

Antwort B bietet eine korrekte, robuste und produktionsreife Implementierung der TokenBucket-Klasse. Sie enthält die gesamte Kernlogik von Antwort A, fügt aber wichtige Verbesserungen hinzu: Thread-Sicherheit durch threading.Lock(), Eingabevalidierung mit aussagekräftigen Fehlermeldungen für ungültige Konstruktorargumente und private Namenskonventionen (_tokens, _last_time, _lock) für eine bessere Kapselung. Die Absicherung gegen elapsed <= 0 ist ein kleiner defensiver Touch. Der Code ist sauber, gut dokumentiert und folgt den Python-Konventionen. Die einzige geringfügige Schwäche ist das Fehlen einer lauffähigen Demo, aber die Beispielverwendungskommentare gleichen dies teilweise aus.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
90

Die Kernlogik ist korrekt und zusätzlich durch ein threading.Lock() geschützt, was Race Conditions in nebenläufigen Umgebungen verhindert. Die Eingabevalidierung stellt sicher, dass das Objekt immer in einem gültigen Zustand ist. Die Absicherung gegen elapsed <= 0 ist eine kleine, aber sinnvolle defensive Prüfung.

Vollstandigkeit

Gewichtung 20%
85

Die Implementierung deckt alle erforderlichen Elemente ab und geht darüber hinaus mit Thread-Sicherheit, Eingabevalidierung und ordnungsgemäßer Kapselung. Die Beispielverwendungskommentare bieten Anleitung. Die einzige geringfügige Lücke ist das Fehlen einer lauffähigen Demo, aber dies ist ein geringfügiges Anliegen.

Codequalitat

Gewichtung 20%
85

Der Code ist sauber, lesbar und gut strukturiert. Er verwendet private Namenskonventionen (_tokens, _last_time, _lock) für eine bessere Kapselung, enthält klare Docstrings und folgt den Python-Konventionen. Der Docstring auf Klassenebene ist umfassend. Etwas besser als A in Bezug auf Kapselung und defensive Programmierung.

Praktischer Nutzen

Gewichtung 15%
85

Die Implementierung ist für den realen Einsatz sehr praktisch. Die Thread-Sicherheit macht sie für nebenläufige Anwendungen geeignet, die Eingabevalidierung verhindert Missbrauch und die saubere API erleichtert die Integration. Die Beispielverwendungskommentare unterstützen die praktische Übernahme weiter.

Befolgung der Anweisungen

Gewichtung 10%
90

Folgt allen Anweisungen: Implementiert die TokenBucket-Klasse in Python, der Konstruktor akzeptiert Kapazität und Nachfüllrate, allow_request() nimmt keine Argumente entgegen und gibt True/False zurück, während ein Token verbraucht wird. Verwendet nur die Standardbibliothek (time, threading-Module). Der Zustand wird innerhalb der Instanz verwaltet.

Bewertungsmodelle Google Gemini 2.5 Pro

Gesamtpunktzahl

85

Gesamtkommentar

Antwort B bietet eine robuste und praktische Implementierung des Token-Bucket-Algorithmus. Ihre Hauptstärken sind die Thread-Sicherheit, die durch die Verwendung eines Locks erreicht wird, und die Einbeziehung der Eingabevalidierung, was sie für den Einsatz in nebenläufigen, produktionsähnlichen Umgebungen geeignet macht. Obwohl der Code gut strukturiert ist, fehlen Typ-Annotationen und eine ausführbare Demonstration, was seine Klarheit und Vollständigkeit verbessert hätte.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
90

Die Implementierung ist sowohl im Single-Threaded- als auch im Multi-Threaded-Kontext aufgrund der Verwendung eines Locks logisch korrekt. Dies macht die Lösung in einem viel breiteren und realistischeren Szenariobereich korrekt.

Vollstandigkeit

Gewichtung 20%
65

Die Antwort liefert die erforderliche Klasse, enthält aber nur einen auskommentierten Ausschnitt für die Beispielverwendung. Es fehlt eine ausführbare Demonstration oder Testfälle zur Überprüfung der Funktionalität, was sie weniger vollständig macht als Antwort A.

Codequalitat

Gewichtung 20%
80

Die Codequalität ist gut, mit klaren Docstrings, sinnvollen Variablennamen und der Einbeziehung der Eingabevalidierung, was eine gute Praxis ist. Es fehlen jedoch Typ-Annotationen, die im modernen Python zur Verbesserung der Lesbarkeit und Wartbarkeit Standard sind.

Praktischer Nutzen

Gewichtung 15%
95

Der praktische Wert ist extrem hoch. Durch die Einbeziehung eines Threading-Locks ist die Implementierung Thread-sicher und kann in realen Multi-Threading-Anwendungen eingesetzt werden. Die zusätzliche Eingabevalidierung erhöht ihre Praktikabilität und Robustheit weiter.

Befolgung der Anweisungen

Gewichtung 10%
100

Die Antwort folgt perfekt allen Anweisungen in der Eingabeaufforderung und implementiert die angegebene Klasse, den Konstruktor und die Methode mit der korrekten Logik. Die Lösung ist in sich geschlossen, da `threading` Teil der Standardbibliothek ist.

Bewertungsmodelle OpenAI GPT-5.4

Gesamtpunktzahl

84

Gesamtkommentar

Antwort B bietet eine korrekte und robustere Python-Implementierung. Sie verwendet eine monotone Uhr, validiert Konstruktor-Eingaben, verwaltet den Zustand sauber, begrenzt Nachfüllungen korrekt und verbraucht Token sicher. Sie fügt auch Threadsicherheit mit einem Lock hinzu, was sie in realen Anwendungen praktikabler macht. Ihr einziger kleiner Nachteil ist, dass sie immer noch auf Gleitkommaarithmetik angewiesen ist, ohne spezielle Vorkehrungen gegen langfristige Präzisionsakkumulation, aber insgesamt ist sie stärker und produktionsorientierter.

Bewertungsdetails anzeigen

Korrektheit

Gewichtung 35%
84

Die Kernlogik des Token-Buckets ist korrekt und Zustandsaktualisierungen erfolgen konsistent. Sie füllt korrekt basierend auf der verstrichenen monotonen Zeit auf, begrenzt auf die Kapazität und verbraucht ein Token pro erfolgreicher Anfrage. Eingabevalidierung stärkt die Korrektheit, und Locking verhindert Race-bedingte Inkonsistenzen im Multithreading-Betrieb. Eine geringe Reduzierung nur, weil sie immer noch einfache Gleitkommaarithmetik verwendet.

Vollstandigkeit

Gewichtung 20%
82

Sie implementiert die angeforderte Klasse und Methoden vollständig, verwaltet den internen Zustand korrekt und bleibt in sich geschlossen. Sie deckt auch wichtige Randfälle durch Konstruktorvalidierung und sichere Zugriffsmuster ab, was sie vollständiger als die Basisvorgabe macht.

Codequalitat

Gewichtung 20%
83

Der Code ist gut strukturiert, lesbar und praktisch, mit klarer Benennung, prägnanten Kommentaren und guter Kapselung durch unterstrichene Attribute. Die Lock-Verwendung ist sauber integriert und die Implementierung konzentriert sich auf die Klasse selbst.

Praktischer Nutzen

Gewichtung 15%
85

Sie ist näher an der Produktionsnutzung, da sie Eingaben validiert und unter gleichzeitiger Ausführung sicher ist. Die Implementierung ist immer noch kompakt und leicht direkt in Anwendungen zu übernehmen, was ihr einen hohen praktischen Wert verleiht.

Befolgung der Anweisungen

Gewichtung 10%
92

Sie folgt den Anweisungen sehr gut: Sie bietet eine in sich geschlossene TokenBucket-Klasse mit dem erforderlichen Konstruktor, Zustandsverwaltung und allow_request-Verhalten. Die Antwort bleibt fokussiert und stimmt eng mit der erwarteten reinen Code-Implementierung überein.

Vergleichsuebersicht

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

Bewerter: 3

Siegstimmen

0 / 3

Durchschnittsscore

79
Diese Antwort ansehen

Siegstimmen

3 / 3

Durchschnittsscore

86
Diese Antwort ansehen

Bewertungsergebnisse

Bewertungsmodelle OpenAI GPT-5.4

Warum diese Seite gewann

Antwort B gewinnt, da sie das erforderliche Token-Bucket-Verhalten erfüllt und gleichzeitig robuster und praktischer ist. Im Vergleich zu Antwort A fügt sie Eingabevalidierung und Threadsicherheit hinzu, was die Zuverlässigkeit erheblich verbessert, ohne die Klarheit zu beeinträchtigen. Beide Antworten sind in der Kernlogik korrekt, aber B erfüllt die Erwartungen des Benchmarks an Robustheit und praktischen Wert besser.

Bewertungsmodelle Google Gemini 2.5 Pro

Warum diese Seite gewann

Antwort B ist der Gewinner, da sie eine threadsichere Implementierung bietet, was für einen Ratenbegrenzer in fast jeder praktischen Anwendung eine kritische Anforderung ist. Die Anforderung der Aufgabenstellung nach einer "robusten" Lösung, die "mehrere Anfragen in sehr schneller Folge" verarbeitet, impliziert stark die Notwendigkeit einer Nebenläufigkeitskontrolle. Während Antwort A mit einer ausführbaren Demo und Typ-Hinweisen eine bessere Präsentation hat, ist ihr Mangel an Threadsicherheit ein grundlegender Mangel an Robustheit für dieses spezielle Problem. Die Lösung von Antwort B ist robuster und hat einen deutlich höheren praktischen Wert, was sie zur überlegenen technischen Lösung macht.

Warum diese Seite gewann

Antwort B gewinnt, da sie Thread-Sicherheit durch threading.Lock() beinhaltet, was für einen Ratenbegrenzer, der in realen gleichzeitigen Szenarien verwendet wird, entscheidend ist. Sie fügt auch Eingabevalidierung und eine bessere Kapselung durch private Attribute hinzu. Beide Antworten sind funktional korrekt, aber Antwort B ist robuster und produktionsreifer, was sie insgesamt zur stärkeren Implementierung macht.

X f L