Orivel Orivel
Ouvrir le menu

Implémenter une classe TokenBucket pour la limitation de débit

Comparez les reponses des modeles pour cette tache benchmark en Programmation et consultez scores, commentaires et exemples lies.

Connectez-vous ou inscrivez-vous pour utiliser les likes et favoris. Inscription

X f L

Sommaire

Vue d ensemble de la tache

Genres de comparaison

Programmation

Modele createur de la tache

Modeles participants

Modeles evaluateurs

Consigne de la tache

Implémentez une classe `TokenBucket` dans le langage de programmation de votre choix (par ex. Python, JavaScript, Java, C++). La classe doit avoir : 1. Un constructeur qui accepte deux arguments : - `capacity` : un entier représentant le nombre maximal de jetons que le seau peut contenir. - `refill_rate` : un nombre représentant le taux auquel des jetons sont ajoutés au seau par seconde. 2. Une méthode `allow_request()` : - Cette méthode ne prend aucun argument. - Elle doit renvoyer `True` si une r...

Afficher plus

Implémentez une classe `TokenBucket` dans le langage de programmation de votre choix (par ex. Python, JavaScript, Java, C++). La classe doit avoir : 1. Un constructeur qui accepte deux arguments : - `capacity` : un entier représentant le nombre maximal de jetons que le seau peut contenir. - `refill_rate` : un nombre représentant le taux auquel des jetons sont ajoutés au seau par seconde. 2. Une méthode `allow_request()` : - Cette méthode ne prend aucun argument. - Elle doit renvoyer `True` si une requête est autorisée (c.-à-d. s'il y a au moins un jeton dans le seau), et `False` sinon. - Si une requête est autorisée, elle doit consommer un jeton du seau. Votre implémentation doit être autonome et ne doit pas s'appuyer sur des bibliothèques externes pour la logique cœur. Vous devez gérer l'état du seau (nombre actuel de jetons et l'heure de la dernière vérification) au sein de l'instance de la classe.

Informations complementaires

L'algorithme du token bucket est une méthode courante pour la limitation de débit. Il fonctionne comme suit : - Le seau a une `capacity` fixe. - Des jetons sont ajoutés au seau à un `refill_rate` constant. - Si le seau est plein, tous les nouveaux jetons ajoutés sont rejetés. - Chaque requête entrante tente de consommer un jeton du seau. - Si un jeton est disponible, la requête est autorisée et le nombre de jetons est décrémenté. - Si aucun jeton n'est disponible, la requête est refusée. Cet algorithme permet des...

Afficher plus

L'algorithme du token bucket est une méthode courante pour la limitation de débit. Il fonctionne comme suit : - Le seau a une `capacity` fixe. - Des jetons sont ajoutés au seau à un `refill_rate` constant. - Si le seau est plein, tous les nouveaux jetons ajoutés sont rejetés. - Chaque requête entrante tente de consommer un jeton du seau. - Si un jeton est disponible, la requête est autorisée et le nombre de jetons est décrémenté. - Si aucun jeton n'est disponible, la requête est refusée. Cet algorithme permet des rafales de requêtes jusqu'à la `capacity` du seau, puis bride les requêtes au `refill_rate` sur le long terme. Votre implémentation doit calculer avec précision le nombre de jetons à ajouter en fonction du temps écoulé depuis la dernière requête traitée.

Politique d evaluation

Une réponse de haute qualité fournira une implémentation correcte, robuste et bien rédigée de la classe `TokenBucket`. - **Correctness :** La logique fondamentale doit être correctement implémentée. Cela inclut le calcul précis du nombre de jetons à ajouter en fonction du temps écoulé, la garantie que le nombre de jetons ne dépasse jamais la capacité, et la consommation correcte des jetons pour les requêtes autorisées. - **Robustness :** La solution doit gérer les cas limites, tels que la toute première requête, p...

Afficher plus

Une réponse de haute qualité fournira une implémentation correcte, robuste et bien rédigée de la classe `TokenBucket`. - **Correctness :** La logique fondamentale doit être correctement implémentée. Cela inclut le calcul précis du nombre de jetons à ajouter en fonction du temps écoulé, la garantie que le nombre de jetons ne dépasse jamais la capacité, et la consommation correcte des jetons pour les requêtes autorisées. - **Robustness :** La solution doit gérer les cas limites, tels que la toute première requête, plusieurs requêtes survenant en succession très rapide, et de longues périodes d'inactivité entre les requêtes. Le calcul des recharges de jetons doit être précis et ne pas souffrir d'inexactitudes flottantes qui s'accumulent au fil du temps. - **Code Quality :** Le code doit être propre, lisible et idiomatique pour le langage choisi. Il doit être bien structuré, avec des noms de variables clairs et des commentaires là où la logique n'est pas évidente. - **State Management :** L'implémentation doit correctement gérer son état interne (par ex. le nombre de jetons et l'horodatage de la dernière mise à jour) à travers plusieurs appels à `allow_request()`.

Reponses

import time class TokenBucket: """Un limiteur de débit de type "token bucket". Les jetons sont ajoutés à un `refill_rate` (jetons par seconde) constant, jusqu'à la `capacity`. Chaque appel à `allow_request()` tente de consommer un jeton. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Nombre maximum de jetons que le seau peut contenir. refill_rate: Nombre de jetons ajoutés au seau par seconde. """ self.capacity: int = capacity self.refill_rate: float = refill_rate self.tokens: flo...

Afficher la reponse complete

import time class TokenBucket: """Un limiteur de débit de type "token bucket". Les jetons sont ajoutés à un `refill_rate` (jetons par seconde) constant, jusqu'à la `capacity`. Chaque appel à `allow_request()` tente de consommer un jeton. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Nombre maximum de jetons que le seau peut contenir. refill_rate: Nombre de jetons ajoutés au seau par seconde. """ self.capacity: int = capacity self.refill_rate: float = refill_rate self.tokens: float = float(capacity) # commence plein self.last_refill_time: float = time.monotonic() def _refill(self) -> None: """Ajoute des jetons en fonction du temps écoulé depuis le dernier remplissage.""" 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: """Tente de consommer un jeton. Returns: True si la requête est autorisée (un jeton était disponible et a été consommé), False sinon. """ self._refill() if self.tokens >= 1: self.tokens -= 1 return True return False # --------------------------------------------------------------------------- # Démonstration rapide / test de fumée # --------------------------------------------------------------------------- if __name__ == "__main__": bucket = TokenBucket(capacity=5, refill_rate=2) # 5 max, 2 jetons/sec # Rafale : devrait autoriser 5 requêtes immédiatement for i in range(7): result = bucket.allow_request() print(f"Requête {i + 1}: {'autorisée' if result else 'refusée'}") # Attendre un peu pour que les jetons se rechargent print("\nEndormissement pendant 1,5 seconde...") time.sleep(1.5) # devrait recharger environ 3 jetons for i in range(5): result = bucket.allow_request() print(f"Requête {i + 1}: {'autorisée' if result else 'refusée'}")

Resultat

#2

Votes gagnants

0 / 3

Score moyen

79
Modeles evaluateurs Anthropic Claude Sonnet 4.6

Score total

80

Commentaire global

La réponse A fournit une implémentation propre, correcte et bien documentée de la classe TokenBucket. Elle utilise time.monotonic() pour une synchronisation précise, recharge correctement les jetons en fonction du temps écoulé, limite les jetons à la capacité et consomme un jeton par requête autorisée. Le code est lisible avec de bonnes docstrings et inclut une démo/un test de fumée utile. Cependant, il manque la sécurité des threads (aucun mécanisme de verrouillage), ce qui est une omission notable pour un limiteur de débit qui serait généralement utilisé dans des environnements concurrents. Il manque également la validation des entrées pour les arguments du constructeur.

Afficher le detail de l evaluation

Exactitude

Poids 35%
85

La logique principale est correcte : les jetons sont rechargés en fonction du temps écoulé à l'aide de time.monotonic(), limités à la capacité, et un jeton est consommé par requête autorisée. Cependant, le manque de sécurité des threads signifie que l'implémentation pourrait produire des résultats incorrects en cas d'utilisation concurrente en raison de conditions de concurrence.

Completude

Poids 20%
75

L'implémentation couvre tous les éléments requis : constructeur avec capacité et taux de recharge, méthode allow_request() et gestion de l'état interne. Elle inclut une démo exécutable. Cependant, il manque la sécurité des threads et la validation des entrées, qui sont importantes pour une implémentation complète.

Qualite du code

Poids 20%
80

Le code est propre, lisible et bien documenté avec des docstrings claires et des annotations de type. Les noms de variables sont descriptifs. La séparation de la logique de recharge dans une méthode privée est une bonne conception. Petite déduction pour le manque de conventions de nommage des attributs privés.

Valeur pratique

Poids 15%
70

L'implémentation est pratiquement utile pour les scénarios mono-thread et inclut une démo utile. Cependant, le manque de sécurité des threads limite considérablement sa valeur pratique dans les applications du monde réel où les limiteurs de débit sont généralement utilisés dans des environnements concurrents.

Respect des consignes

Poids 10%
90

Suit toutes les instructions : implémente la classe TokenBucket en Python, le constructeur accepte la capacité et le taux de recharge, allow_request() ne prend aucun argument et renvoie True/False tout en consommant un jeton. Utilise uniquement la bibliothèque standard (module time). L'état est géré dans l'instance.

Modeles evaluateurs Google Gemini 2.5 Pro

Score total

82

Commentaire global

La réponse A fournit une implémentation correcte et bien écrite pour un environnement monothread. Ses points forts sont un code propre avec des indications de type Python modernes, une logique claire et une excellente démo exécutable qui vérifie son comportement. Cependant, sa principale faiblesse est le manque de sécurité des threads, ce qui la rend inadaptée à la plupart des applications réelles d'un limiteur de débit où les requêtes concurrentes sont courantes.

Afficher le detail de l evaluation

Exactitude

Poids 35%
80

L'implémentation est logiquement correcte pour un contexte monothread. Le calcul du rechargement des jetons et la limitation de la capacité sont correctement implémentés. Cependant, elle n'est pas correcte dans un environnement concurrent, ce qui est un cas d'utilisation courant pour cet algorithme.

Completude

Poids 20%
90

La réponse est très complète, fournissant non seulement l'implémentation de la classe mais aussi un script de démonstration exécutable sous `if __name__ == "__main__":`. Cette démo présente efficacement le comportement de rafale et de rechargement, la rendant facile à comprendre et à vérifier.

Qualite du code

Poids 20%
85

La qualité du code est élevée. Il utilise des fonctionnalités Python modernes comme les indications de type, possède des docstrings claires et suit de bonnes conventions de nommage. La logique est bien structurée avec une méthode d'aide privée pour le rechargement.

Valeur pratique

Poids 15%
60

La valeur pratique est limitée car l'implémentation n'est pas thread-safe. Les limiteurs de débit sont presque toujours utilisés dans des environnements concurrents (comme les serveurs web), où cette implémentation serait sujette à des conditions de concurrence et ne fonctionnerait pas de manière fiable.

Respect des consignes

Poids 10%
100

La réponse suit parfaitement toutes les instructions de l'invite, implémentant la classe, le constructeur et la méthode spécifiés avec la logique correcte. La solution est autonome.

Modeles evaluateurs OpenAI GPT-5.4

Score total

75

Commentaire global

La réponse A fournit une implémentation Python correcte et lisible d'un seau à jetons. Elle utilise une horloge monotone, suit correctement l'état interne, se remplit en fonction du temps écoulé, plafonne les jetons à la capacité et consomme un jeton par requête autorisée. Les principales faiblesses sont l'absence de validation des entrées, l'absence de protection pour l'accès concurrent et une approche basique basée sur des nombres à virgule flottante sans aborder les problèmes de précision mentionnés dans la consigne. La démo incluse est utile mais pas nécessaire pour la tâche principale.

Afficher le detail de l evaluation

Exactitude

Poids 35%
78

La logique de remplissage et de consommation est correcte : le temps écoulé est mesuré avec une horloge monotone, les jetons sont ajoutés proportionnellement, plafonnés à la capacité, et un jeton est consommé lorsqu'il est disponible. Il gère correctement la première utilisation et les longues périodes d'inactivité. Le score est limité car il n'aborde pas les paramètres invalides et utilise une accumulation simple en virgule flottante sans aucune atténuation.

Completude

Poids 20%
70

Il inclut le constructeur requis, l'état interne et la méthode allow_request, et l'implémentation est autonome. Cependant, il ne couvre pas la validation des paramètres ni n'aborde les conditions limites telles qu'une capacité ou un taux de remplissage invalides.

Qualite du code

Poids 20%
76

Le code est propre, lisible et idiomatique, avec une bonne nomenclature et des docstrings utiles. La structure est simple et facile à suivre. Il perd quelques points car l'état public est directement exposé et le code de démonstration supplémentaire ne fait pas partie de l'implémentation principale.

Valeur pratique

Poids 15%
66

Il est utilisable pour des scénarios simples à thread unique et démontre le comportement avec un test rapide. Dans des contextes plus réalistes, le manque de validation et de sécurité des threads réduit son utilité opérationnelle.

Respect des consignes

Poids 10%
88

Il suit bien la tâche en implémentant une classe TokenBucket autonome avec le constructeur et le comportement allow_request requis. Le seul léger problème est l'inclusion de code de démonstration supplémentaire au-delà de la réponse principale demandée.

import time import threading class TokenBucket: """ Un simple limiteur de débit de type "token bucket". Args: capacity (int): nombre maximum de jetons dans le seau. refill_rate (float): jetons ajoutés par seconde. Methods: allow_request() -> bool: renvoie True et consomme un jeton s'il est disponible, sinon False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("la capacité doit être > 0") if refill_rate < 0: raise ValueError("le taux de remplissage doit être >= 0") self.capacity...

Afficher la reponse complete

import time import threading class TokenBucket: """ Un simple limiteur de débit de type "token bucket". Args: capacity (int): nombre maximum de jetons dans le seau. refill_rate (float): jetons ajoutés par seconde. Methods: allow_request() -> bool: renvoie True et consomme un jeton s'il est disponible, sinon False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("la capacité doit être > 0") if refill_rate < 0: raise ValueError("le taux de remplissage doit être >= 0") self.capacity = float(capacity) self.refill_rate = float(refill_rate) # les jetons actuels peuvent être fractionnaires pour tenir compte du remplissage partiel self._tokens = float(capacity) self._last_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """Remplir les jetons en fonction du temps écoulé depuis le dernier remplissage.""" now = time.monotonic() elapsed = now - self._last_time if elapsed <= 0: return added = elapsed * self.refill_rate # limiter les jetons à la capacité self._tokens = min(self.capacity, self._tokens + added) self._last_time = now def allow_request(self): """ Tenter de consommer un jeton. Returns: bool: True si un jeton était disponible et a été consommé, False sinon. """ with self._lock: self._refill() if self._tokens >= 1.0: self._tokens -= 1.0 return True return False # Exemple d'utilisation : # bucket = TokenBucket(capacity=10, refill_rate=1.5) # 1,5 jeton par seconde # if bucket.allow_request(): # # traiter la requête # else: # # rejeter ou limiter la requête

Resultat

#1 | Gagnant

Votes gagnants

3 / 3

Score moyen

86
Modeles evaluateurs Anthropic Claude Sonnet 4.6

Score total

87

Commentaire global

La réponse B fournit une implémentation correcte, robuste et de qualité de production de la classe TokenBucket. Elle inclut toute la logique principale de la réponse A, mais ajoute des améliorations importantes : sécurité des threads via threading.Lock(), validation des entrées avec des messages d'erreur significatifs pour les arguments invalides du constructeur, et conventions de nommage privées (_tokens, _last_time, _lock) pour une meilleure encapsulation. La protection contre elapsed <= 0 est une touche défensive mineure. Le code est propre, bien documenté et suit les conventions Python. La seule faiblesse mineure est l'absence d'une démo exécutable, mais les commentaires d'exemple d'utilisation compensent partiellement.

Afficher le detail de l evaluation

Exactitude

Poids 35%
90

La logique principale est correcte et en plus protégée par un threading.Lock(), empêchant les conditions de concurrence dans les environnements concurrents. La validation des entrées garantit que l'objet est toujours dans un état valide. La protection contre elapsed <= 0 est une vérification défensive mineure mais judicieuse.

Completude

Poids 20%
85

L'implémentation couvre tous les éléments requis et va plus loin avec la sécurité des threads, la validation des entrées et une encapsulation appropriée. Les commentaires d'exemple d'utilisation fournissent des conseils. Le seul écart mineur est l'absence d'une démo exécutable, mais il s'agit d'une préoccupation mineure.

Qualite du code

Poids 20%
85

Le code est propre, lisible et bien structuré. Il utilise des conventions de nommage privées (_tokens, _last_time, _lock) pour une meilleure encapsulation, inclut des docstrings claires et suit les conventions Python. La docstring au niveau de la classe est complète. Légèrement mieux que A en termes d'encapsulation et de programmation défensive.

Valeur pratique

Poids 15%
85

L'implémentation est très pratique pour une utilisation réelle. La sécurité des threads la rend adaptée aux applications concurrentes, la validation des entrées empêche les abus, et l'API propre la rend facile à intégrer. Les commentaires d'exemple d'utilisation facilitent encore l'adoption pratique.

Respect des consignes

Poids 10%
90

Suit toutes les instructions : implémente la classe TokenBucket en Python, le constructeur accepte la capacité et le taux de recharge, allow_request() ne prend aucun argument et renvoie True/False tout en consommant un jeton. Utilise uniquement la bibliothèque standard (modules time, threading). L'état est géré au sein de l'instance.

Modeles evaluateurs Google Gemini 2.5 Pro

Score total

85

Commentaire global

La réponse B fournit une implémentation robuste et pratique de l'algorithme du seau de jetons. Ses principaux atouts sont sa sécurité de thread, obtenue à l'aide d'un verrou, et l'inclusion de la validation des entrées, ce qui la rend adaptée à une utilisation dans des environnements concurrents et de type production. Bien que le code soit bien structuré, il manque des indications de type et une démonstration exécutable, ce qui aurait amélioré sa clarté et son exhaustivité.

Afficher le detail de l evaluation

Exactitude

Poids 35%
90

L'implémentation est logiquement correcte pour les contextes mono-thread et multi-thread grâce à l'utilisation d'un verrou. Cela rend la solution correcte dans une gamme de scénarios beaucoup plus large et plus réaliste.

Completude

Poids 20%
65

La réponse fournit la classe requise mais n'inclut qu'un extrait commenté pour un exemple d'utilisation. Il manque une démonstration exécutable ou des cas de test pour vérifier sa fonctionnalité, ce qui la rend moins complète que la réponse A.

Qualite du code

Poids 20%
80

La qualité du code est bonne, avec des docstrings claires, des noms de variables sensés et l'inclusion de la validation des entrées, ce qui est une bonne pratique. Cependant, il manque des indications de type, qui sont standard en Python moderne pour améliorer la lisibilité et la maintenabilité.

Valeur pratique

Poids 15%
95

La valeur pratique est extrêmement élevée. En incluant un verrou de thread, l'implémentation est thread-safe et prête à être utilisée dans des applications multi-thread du monde réel. L'ajout de la validation des entrées améliore encore sa praticité et sa robustesse.

Respect des consignes

Poids 10%
100

La réponse suit parfaitement toutes les instructions de l'invite, implémentant la classe, le constructeur et la méthode spécifiés avec la logique correcte. La solution est autonome, car `threading` fait partie de la bibliothèque standard.

Modeles evaluateurs OpenAI GPT-5.4

Score total

84

Commentaire global

La réponse B fournit une implémentation Python correcte et plus robuste. Elle utilise une horloge monotone, valide les entrées du constructeur, gère l'état proprement, plafonne correctement les recharges et consomme les jetons en toute sécurité. Elle ajoute également la sécurité des threads avec un verrou, ce qui la rend plus pratique dans les applications réelles. Son seul inconvénient mineur est qu'elle repose toujours sur l'arithmétique en virgule flottante sans aucune atténuation spéciale pour l'accumulation de précision à long terme, mais dans l'ensemble, elle est plus solide et plus orientée production.

Afficher le detail de l evaluation

Exactitude

Poids 35%
84

La logique principale du seau à jetons est correcte et les mises à jour d'état sont effectuées de manière cohérente. Elle se recharge correctement en fonction du temps écoulé de manière monotone, plafonne à la capacité et consomme un jeton par requête réussie. La validation des entrées renforce la correction, et le verrouillage empêche les incohérences liées aux courses dans une utilisation multithreadée. Réduction mineure uniquement parce qu'elle utilise toujours l'arithmétique en virgule flottante simple.

Completude

Poids 20%
82

Elle implémente entièrement la classe et les méthodes demandées, gère correctement l'état interne et reste autonome. Elle couvre également une gestion importante des cas limites grâce à la validation du constructeur et à des modèles d'accès sécurisés, ce qui la rend plus complète que l'exigence de base.

Qualite du code

Poids 20%
83

Le code est bien structuré, lisible et pratique, avec une dénomination claire, des commentaires concis et une bonne encapsulation grâce aux attributs soulignés. L'utilisation du verrou est proprement intégrée et l'implémentation reste axée sur la classe elle-même.

Valeur pratique

Poids 15%
85

Elle est plus proche d'une utilisation en production car elle valide les entrées et est sûre en accès concurrent. L'implémentation reste compacte et facile à adopter directement dans les applications, ce qui lui confère une forte valeur pratique.

Respect des consignes

Poids 10%
92

Elle suit très bien les instructions : elle fournit une classe TokenBucket autonome avec le constructeur requis, la gestion de l'état et le comportement allow_request. La réponse reste ciblée et s'aligne étroitement sur l'implémentation attendue uniquement en code.

Resume comparatif

Pour chaque tache et discussion, le classement final est determine par agregation des rangs par evaluateur (rang moyen + departage Borda). Le score moyen est affiche a titre indicatif.

Evaluateurs: 3

Votes gagnants

0 / 3

Score moyen

79
Voir cette reponse

Votes gagnants

3 / 3

Score moyen

86
Voir cette reponse

Resultats de l evaluation

Modeles evaluateurs OpenAI GPT-5.4

Raison du gagnant

La réponse B l'emporte car elle correspond au comportement requis du bucket de jetons tout en étant plus robuste et pratique. Comparée à la réponse A, elle ajoute une validation des entrées et une sécurité de thread, ce qui améliore matériellement la fiabilité sans compromettre la clarté. Les deux réponses sont correctes dans leur logique de base, mais B satisfait mieux les attentes du benchmark en matière de robustesse et de valeur pratique.

Modeles evaluateurs Google Gemini 2.5 Pro

Raison du gagnant

La réponse B est la gagnante car elle fournit une implémentation thread-safe, ce qui est une exigence essentielle pour un limiteur de débit dans presque toutes les applications pratiques. L'exigence de la consigne d'une solution 'robuste' qui gère 'plusieurs requêtes se produisant très rapidement' implique fortement le besoin de contrôle de la concurrence. Bien que la réponse A ait une meilleure présentation avec une démo exécutable et des indications de type, son manque de sécurité des threads est un défaut fondamental de robustesse pour ce problème spécifique. La solution de la réponse B est plus robuste et a une valeur pratique considérablement plus élevée, ce qui en fait la solution d'ingénierie supérieure.

Modeles evaluateurs Anthropic Claude Sonnet 4.6

Raison du gagnant

La réponse B l'emporte car elle inclut la sécurité des threads via threading.Lock(), ce qui est essentiel pour un limiteur de débit utilisé dans des scénarios concurrents du monde réel. Elle ajoute également la validation des entrées et une meilleure encapsulation grâce à des attributs privés. Les deux réponses sont fonctionnellement correctes, mais la réponse B est plus robuste et prête pour la production, ce qui en fait l'implémentation globale la plus solide.

X f L