Orivel Orivel
Abrir menu

Implementar una clase TokenBucket para un limitador de tasa

Compara respuestas de modelos para esta tarea benchmark de Programación y revisa puntuaciones, comentarios y ejemplos relacionados.

Inicia sesion o registrate para usar me gusta y favoritos. Registrarse

X f L

Indice

Resumen de la tarea

Generos de Comparacion

Programación

Modelo creador de la tarea

Modelos participantes

Modelos evaluadores

Enunciado de la tarea

Implementa una clase `TokenBucket` en el lenguaje de programación de tu elección (por ejemplo, Python, JavaScript, Java, C++). La clase debe tener: 1. Un constructor que acepte dos argumentos: - `capacity`: Un entero que representa el número máximo de tokens que el cubo puede contener. - `refill_rate`: Un número que representa la tasa a la que se añaden tokens al cubo por segundo. 2. Un método `allow_request()`: - Este método no toma argumentos. - Debe devolver `True` si se permite una solicitud (e...

Mostrar mas

Implementa una clase `TokenBucket` en el lenguaje de programación de tu elección (por ejemplo, Python, JavaScript, Java, C++). La clase debe tener: 1. Un constructor que acepte dos argumentos: - `capacity`: Un entero que representa el número máximo de tokens que el cubo puede contener. - `refill_rate`: Un número que representa la tasa a la que se añaden tokens al cubo por segundo. 2. Un método `allow_request()`: - Este método no toma argumentos. - Debe devolver `True` si se permite una solicitud (es decir, si hay al menos un token en el cubo), y `False` en caso contrario. - Si se permite una solicitud, debe consumir un token del cubo. Tu implementación debe ser autocontenida y no debe depender de librerías externas para la lógica principal. Debes gestionar el estado del cubo (número actual de tokens y el tiempo de la última comprobación) dentro de la instancia de la clase.

Informacion complementaria

El algoritmo del token bucket es un método común para la limitación de tasa. Funciona de la siguiente manera: - El cubo tiene una `capacity` fija. - Se añaden tokens al cubo a una `refill_rate` constante. - Si el cubo está lleno, los nuevos tokens que se añadan se descartan. - Cada solicitud entrante intenta consumir un token del cubo. - Si hay un token disponible, la solicitud se permite y el recuento de tokens se decrementa. - Si no hay tokens disponibles, la solicitud es denegada. Este algoritmo permite ráfagas...

Mostrar mas

El algoritmo del token bucket es un método común para la limitación de tasa. Funciona de la siguiente manera: - El cubo tiene una `capacity` fija. - Se añaden tokens al cubo a una `refill_rate` constante. - Si el cubo está lleno, los nuevos tokens que se añadan se descartan. - Cada solicitud entrante intenta consumir un token del cubo. - Si hay un token disponible, la solicitud se permite y el recuento de tokens se decrementa. - Si no hay tokens disponibles, la solicitud es denegada. Este algoritmo permite ráfagas de solicitudes hasta la `capacity` del cubo y, luego, limita las solicitudes a la `refill_rate` a largo plazo. Tu implementación debe calcular con precisión el número de tokens a añadir en función del tiempo transcurrido desde que se procesó la última solicitud.

Politica de evaluacion

- **Correctness:** La lógica principal debe estar implementada correctamente. Esto incluye calcular con precisión el número de tokens a añadir según el tiempo transcurrido, asegurar que el recuento de tokens nunca exceda la capacidad y consumir correctamente tokens para las solicitudes permitidas. - **Robustness:** La solución debe manejar casos límite, como la primera solicitud realizada, múltiples solicitudes que ocurren en rápida sucesión y períodos largos de inactividad entre solicitudes. El cálculo para el rea...

Mostrar mas

- **Correctness:** La lógica principal debe estar implementada correctamente. Esto incluye calcular con precisión el número de tokens a añadir según el tiempo transcurrido, asegurar que el recuento de tokens nunca exceda la capacidad y consumir correctamente tokens para las solicitudes permitidas. - **Robustness:** La solución debe manejar casos límite, como la primera solicitud realizada, múltiples solicitudes que ocurren en rápida sucesión y períodos largos de inactividad entre solicitudes. El cálculo para el reabastecimiento de tokens debe ser preciso y no debe sufrir de inexactitudes de coma flotante que se acumulen con el tiempo. - **Code Quality:** El código debe ser limpio, legible e idiomático para el lenguaje elegido. Debe estar bien estructurado, con nombres de variables claros y comentarios donde la lógica no sea obvia. - **State Management:** La implementación debe gestionar correctamente su estado interno (por ejemplo, el número de tokens y la marca temporal de la última actualización) a lo largo de múltiples llamadas a `allow_request()`.

Respuestas

import time class TokenBucket: """Un limitador de velocidad de cubo de tokens. Los tokens se agregan a una `refill_rate` (tokens por segundo) constante hasta `capacity`. Cada llamada a `allow_request()` intenta consumir un token. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Número máximo de tokens que el cubo puede contener. refill_rate: Número de tokens agregados al cubo por segundo. """ self.capacity: int = capacity self.refill_rate: float = refill_rate self.tokens: float = f...

Mostrar respuesta completa

import time class TokenBucket: """Un limitador de velocidad de cubo de tokens. Los tokens se agregan a una `refill_rate` (tokens por segundo) constante hasta `capacity`. Cada llamada a `allow_request()` intenta consumir un token. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Número máximo de tokens que el cubo puede contener. refill_rate: Número de tokens agregados al cubo por segundo. """ self.capacity: int = capacity self.refill_rate: float = refill_rate self.tokens: float = float(capacity) # comienza lleno self.last_refill_time: float = time.monotonic() def _refill(self) -> None: """Agrega tokens según el tiempo transcurrido desde el último relleno.""" 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: """Intenta consumir un token. Returns: True si la solicitud se permite (un token estaba disponible y se consumió), False en caso contrario. """ self._refill() if self.tokens >= 1: self.tokens -= 1 return True return False # --------------------------------------------------------------------------- # Demostración rápida / prueba de humo # --------------------------------------------------------------------------- if __name__ == "__main__": bucket = TokenBucket(capacity=5, refill_rate=2) # 5 máx., 2 tokens/seg # Ráfaga: debería permitir 5 solicitudes inmediatamente for i in range(7): result = bucket.allow_request() print(f"Solicitud {i + 1}: {'permitida' if result else 'denegada'}") # Esperar un poco para que los tokens se rellenen print("\nDurmiendo 1.5 segundos...") time.sleep(1.5) # debería rellenar ~3 tokens for i in range(5): result = bucket.allow_request() print(f"Solicitud {i + 1}: {'permitida' if result else 'denegada'}")

Resultado

#2

Votos ganadores

0 / 3

Puntuacion media

79
Modelos evaluadores Anthropic Claude Sonnet 4.6

Puntuacion total

80

Comentario general

La respuesta A proporciona una implementación limpia, correcta y bien documentada de la clase TokenBucket. Utiliza time.monotonic() para una temporización precisa, rellena correctamente los tokens en función del tiempo transcurrido, limita los tokens a la capacidad y consume un token por solicitud permitida. El código es legible, con buenos docstrings, e incluye una útil demostración/prueba de humo. Sin embargo, carece de seguridad de hilos (no hay mecanismo de bloqueo), lo cual es una omisión notable para un limitador de velocidad que normalmente se usaría en entornos concurrentes. También carece de validación de entrada para los argumentos del constructor.

Ver detalle de evaluacion

Correccion

Peso 35%
85

La lógica central es correcta: los tokens se recargan en función del tiempo transcurrido utilizando time.monotonic(), se limitan a la capacidad y se consume un token por solicitud permitida. Sin embargo, la falta de seguridad de hilos significa que la implementación podría producir resultados incorrectos en el uso concurrente debido a condiciones de carrera.

Integridad

Peso 20%
75

La implementación cubre todos los elementos requeridos: constructor con capacidad y tasa de recarga, método allow_request() y gestión del estado interno. Incluye una demostración ejecutable. Sin embargo, carece de seguridad de hilos y validación de entrada, que son importantes para una implementación completa.

Calidad del codigo

Peso 20%
80

El código es limpio, legible y está bien documentado con docstrings claros y anotaciones de tipo. Los nombres de las variables son descriptivos. La separación de la lógica de recarga en un método privado es un buen diseño. Deducción menor por la falta de convenciones de nomenclatura de atributos privados.

Valor practico

Peso 15%
70

La implementación es prácticamente útil para escenarios de un solo hilo e incluye una demostración útil. Sin embargo, la falta de seguridad de hilos limita significativamente su valor práctico en aplicaciones del mundo real donde los limitadores de velocidad se usan típicamente en entornos concurrentes.

Seguimiento de instrucciones

Peso 10%
90

Sigue todas las instrucciones: implementa la clase TokenBucket en Python, el constructor acepta capacidad y tasa_de_recarga, allow_request() no toma argumentos y devuelve True/False mientras consume un token. Utiliza solo la biblioteca estándar (módulo time). El estado se gestiona dentro de la instancia.

Modelos evaluadores Google Gemini 2.5 Pro

Puntuacion total

82

Comentario general

La respuesta A proporciona una implementación correcta y bien escrita para un entorno de un solo hilo. Sus puntos fuertes son el código limpio con sugerencias de tipos de Python modernas, una lógica clara y una excelente demostración ejecutable que verifica su comportamiento. Sin embargo, su principal debilidad es la falta de seguridad en los hilos, lo que la hace inadecuada para la mayoría de las aplicaciones del mundo real de un limitador de velocidad donde las solicitudes concurrentes son comunes.

Ver detalle de evaluacion

Correccion

Peso 35%
80

La implementación es lógicamente correcta para un contexto de un solo hilo. El cálculo de recarga de tokens y la limitación de capacidad se implementan correctamente. Sin embargo, no es correcta en un entorno concurrente, que es un caso de uso común para este algoritmo.

Integridad

Peso 20%
90

La respuesta es muy completa, proporcionando no solo la implementación de la clase sino también un script de demostración ejecutable en `if __name__ == "__main__":`. Esta demostración muestra eficazmente el comportamiento de ráfaga y recarga, lo que facilita su comprensión y verificación.

Calidad del codigo

Peso 20%
85

La calidad del código es alta. Utiliza características modernas de Python como sugerencias de tipos, tiene docstrings claros y sigue buenas convenciones de nomenclatura. La lógica está bien estructurada con un método auxiliar privado para la recarga.

Valor practico

Peso 15%
60

El valor práctico es limitado porque la implementación no es segura en cuanto a hilos. Los limitadores de velocidad se utilizan casi siempre en entornos concurrentes (como servidores web), donde esta implementación estaría sujeta a condiciones de carrera y no funcionaría de manera fiable.

Seguimiento de instrucciones

Peso 10%
100

La respuesta sigue perfectamente todas las instrucciones del prompt, implementando la clase, el constructor y el método especificados con la lógica correcta. La solución es autónoma.

Modelos evaluadores OpenAI GPT-5.4

Puntuacion total

75

Comentario general

La respuesta A proporciona una implementación de Python correcta y legible de un bucket de tokens. Utiliza un reloj monotónico, rastrea el estado interno correctamente, se recarga en función del tiempo transcurrido, limita los tokens a la capacidad y consume un token por solicitud permitida. Las principales debilidades son la falta de validación de entrada, la ausencia de protección para el acceso concurrente y un enfoque básico basado en flotantes sin abordar las preocupaciones de precisión mencionadas en la indicación. La demostración incluida es útil pero no necesaria para la tarea principal.

Ver detalle de evaluacion

Correccion

Peso 35%
78

La lógica de recarga y consumo es correcta: el tiempo transcurrido se mide con un reloj monotónico, los tokens se agregan proporcionalmente, se limitan a la capacidad y se consume un token cuando está disponible. Maneja el primer uso y los períodos de inactividad prolongados correctamente. La puntuación se ve afectada porque no aborda parámetros inválidos y utiliza una acumulación de punto flotante directa sin ninguna mitigación.

Integridad

Peso 20%
70

Incluye el constructor requerido, el estado interno y el método allow_request, y la implementación es autocontenida. Sin embargo, no cubre la validación de parámetros ni discute condiciones extremas como capacidad o tasa de recarga inválidas.

Calidad del codigo

Peso 20%
76

El código es limpio, legible e idiomático, con buenos nombres y docstrings útiles. La estructura es simple y fácil de seguir. Pierde algunos puntos porque el estado público se expone directamente y el código de demostración adicional no forma parte de la implementación principal.

Valor practico

Peso 15%
66

Es utilizable para escenarios simples de un solo hilo y demuestra el comportamiento con una prueba rápida. En entornos más realistas, la falta de validación y seguridad de hilos reduce la utilidad operativa.

Seguimiento de instrucciones

Peso 10%
88

Sigue bien la tarea al implementar una clase TokenBucket autocontenida con el comportamiento requerido del constructor y allow_request. El único pequeño problema es la inclusión de código de demostración adicional más allá de la respuesta principal solicitada.

Respuesta B: OpenAI GPT-5 mini

import time import threading class TokenBucket: """ Un limitador de velocidad de cubo de tokens simple. Args: capacity (int): número máximo de tokens en el cubo. refill_rate (float): tokens agregados por segundo. Methods: allow_request() -> bool: devuelve True y consume un token si está disponible, de lo contrario False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("la capacidad debe ser > 0") if refill_rate < 0: raise ValueError("la tasa de recarga debe ser >= 0") self.capacit...

Mostrar respuesta completa

import time import threading class TokenBucket: """ Un limitador de velocidad de cubo de tokens simple. Args: capacity (int): número máximo de tokens en el cubo. refill_rate (float): tokens agregados por segundo. Methods: allow_request() -> bool: devuelve True y consume un token si está disponible, de lo contrario False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("la capacidad debe ser > 0") if refill_rate < 0: raise ValueError("la tasa de recarga debe ser >= 0") self.capacity = float(capacity) self.refill_rate = float(refill_rate) # los tokens actuales pueden ser fraccionarios para tener en cuenta la recarga parcial self._tokens = float(capacity) self._last_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """Recargar tokens según el tiempo transcurrido desde la última recarga.""" now = time.monotonic() elapsed = now - self._last_time if elapsed <= 0: return added = elapsed * self.refill_rate # limitar los tokens a la capacidad self._tokens = min(self.capacity, self._tokens + added) self._last_time = now def allow_request(self): """ Intentar consumir un token. Returns: bool: True si había un token disponible y se consumió, False en caso contrario. """ with self._lock: self._refill() if self._tokens >= 1.0: self._tokens -= 1.0 return True return False # Ejemplo de uso: # bucket = TokenBucket(capacity=10, refill_rate=1.5) # 1.5 tokens por segundo # if bucket.allow_request(): # # procesar solicitud # else: # # rechazar o limitar la solicitud

Resultado

#1 | Ganador

Votos ganadores

3 / 3

Puntuacion media

86
Modelos evaluadores Anthropic Claude Sonnet 4.6

Puntuacion total

87

Comentario general

La respuesta B proporciona una implementación correcta, robusta y de calidad de producción de la clase TokenBucket. Incluye toda la lógica principal de la Respuesta A, pero añade mejoras importantes: seguridad de hilos mediante threading.Lock(), validación de entradas con mensajes de error significativos para argumentos de constructor no válidos, y convenciones de nombres privados (_tokens, _last_time, _lock) para una mejor encapsulación. La protección contra elapsed <= 0 es un pequeño toque defensivo. El código está limpio, bien documentado y sigue las convenciones de Python. La única debilidad menor es la falta de una demostración ejecutable, pero los comentarios de ejemplo de uso compensan parcialmente.

Ver detalle de evaluacion

Correccion

Peso 35%
90

La lógica principal es correcta y además está protegida por un threading.Lock(), lo que evita condiciones de carrera en entornos concurrentes. La validación de entradas garantiza que el objeto esté siempre en un estado válido. La protección contra elapsed <= 0 es una verificación defensiva menor pero sensata.

Integridad

Peso 20%
85

La implementación cubre todos los elementos requeridos y va más allá con seguridad de hilos, validación de entradas y encapsulación adecuada. Los comentarios de ejemplo de uso proporcionan orientación. La única brecha menor es la ausencia de una demostración ejecutable, pero esto es una preocupación menor.

Calidad del codigo

Peso 20%
85

El código es limpio, legible y está bien estructurado. Utiliza convenciones de nombres privados (_tokens, _last_time, _lock) para una mejor encapsulación, incluye docstrings claros y sigue las convenciones de Python. El docstring a nivel de clase es completo. Ligeramente mejor que A en términos de encapsulación y programación defensiva.

Valor practico

Peso 15%
85

La implementación es muy práctica para el uso en el mundo real. La seguridad de hilos la hace adecuada para aplicaciones concurrentes, la validación de entradas evita el mal uso y la API limpia facilita su integración. Los comentarios de ejemplo de uso ayudan aún más a la adopción práctica.

Seguimiento de instrucciones

Peso 10%
90

Sigue todas las instrucciones: implementa la clase TokenBucket en Python, el constructor acepta capacity y refill_rate, allow_request() no acepta argumentos y devuelve True/False mientras consume un token. Utiliza solo la biblioteca estándar (módulos time, threading). El estado se gestiona dentro de la instancia.

Modelos evaluadores Google Gemini 2.5 Pro

Puntuacion total

85

Comentario general

La respuesta B proporciona una implementación robusta y práctica del algoritmo del cubo de tokens. Sus puntos fuertes son la seguridad de hilos, lograda mediante un bloqueo, y la inclusión de validación de entradas, lo que la hace adecuada para entornos concurrentes y similares a la producción. Si bien el código está bien estructurado, carece de sugerencias de tipo y una demostración ejecutable, lo que habría mejorado su claridad y completitud.

Ver detalle de evaluacion

Correccion

Peso 35%
90

La implementación es lógicamente correcta tanto para contextos de un solo hilo como de múltiples hilos debido al uso de un bloqueo. Esto hace que la solución sea correcta en un rango de escenarios mucho más amplio y realista.

Integridad

Peso 20%
65

La respuesta proporciona la clase requerida pero solo incluye un fragmento comentado para el uso de ejemplo. Carece de una demostración ejecutable o casos de prueba para verificar su funcionalidad, lo que la hace menos completa que la Respuesta A.

Calidad del codigo

Peso 20%
80

La calidad del código es buena, con docstrings claras, nombres de variables sensatos y la inclusión de validación de entradas, lo cual es una buena práctica. Sin embargo, carece de sugerencias de tipo, que son estándar en Python moderno para mejorar la legibilidad y la mantenibilidad.

Valor practico

Peso 15%
95

El valor práctico es extremadamente alto. Al incluir un bloqueo de hilos, la implementación es segura para hilos y está lista para ser utilizada en aplicaciones multihilo del mundo real. La adición de validación de entradas mejora aún más su practicidad y robustez.

Seguimiento de instrucciones

Peso 10%
100

La respuesta sigue perfectamente todas las instrucciones de la indicación, implementando la clase, el constructor y el método especificados con la lógica correcta. La solución es autónoma, ya que `threading` forma parte de la biblioteca estándar.

Modelos evaluadores OpenAI GPT-5.4

Puntuacion total

84

Comentario general

La respuesta B proporciona una implementación de Python correcta y más robusta. Utiliza un reloj monotónico, valida las entradas del constructor, gestiona el estado de forma limpia, limita los recargos correctamente y consume tokens de forma segura. También añade seguridad para hilos con un bloqueo, lo que la hace más práctica en aplicaciones reales. Su único inconveniente menor es que todavía se basa en aritmética de punto flotante sin ninguna mitigación especial para la acumulación de precisión a largo plazo, pero en general es más sólida y orientada a la producción.

Ver detalle de evaluacion

Correccion

Peso 35%
84

La lógica principal del cubo de tokens es correcta y las actualizaciones de estado se realizan de forma coherente. Se recarga correctamente en función del tiempo monotónico transcurrido, se limita a la capacidad y consume un token por solicitud exitosa. La validación de entradas refuerza la corrección y el bloqueo evita inconsistencias relacionadas con condiciones de carrera en el uso multihilo. La reducción menor se debe únicamente a que todavía utiliza aritmética de punto flotante simple.

Integridad

Peso 20%
82

Implementa completamente la clase y los métodos solicitados, gestiona el estado interno correctamente y se mantiene autónoma. También cubre un manejo importante de casos extremos a través de la validación del constructor y patrones de acceso seguros, lo que la hace más completa que el requisito básico.

Calidad del codigo

Peso 20%
83

El código está bien estructurado, es legible y práctico, con nombres claros, comentarios concisos y buena encapsulación a través de atributos con guion bajo. El uso del bloqueo está integrado de forma limpia y la implementación se centra en la propia clase.

Valor practico

Peso 15%
85

Está más cerca del uso en producción porque valida las entradas y es segura bajo acceso concurrente. La implementación sigue siendo compacta y fácil de adoptar directamente en aplicaciones, lo que le confiere un gran valor práctico.

Seguimiento de instrucciones

Peso 10%
92

Sigue muy bien las instrucciones: proporciona una clase TokenBucket autónoma con el constructor, el manejo del estado y el comportamiento de allow_request requeridos. La respuesta se mantiene centrada y se alinea estrechamente con la implementación esperada solo de código.

Resumen comparativo

Para cada tarea y discusion, el orden final se decide por agregacion de rangos por evaluador (rango promedio + desempate Borda). La puntuacion media se muestra como referencia.

Evaluadores: 3

Votos ganadores

0 / 3

Puntuacion media

79
Ver esta respuesta

Votos ganadores

3 / 3

Puntuacion media

86
Ver esta respuesta

Resultados de evaluacion

Modelos evaluadores OpenAI GPT-5.4

Motivo del ganador

La respuesta B gana porque coincide con el comportamiento requerido del bucket de tokens y, al mismo tiempo, es más robusta y práctica. En comparación con la respuesta A, añade validación de entrada y seguridad de hilos, lo que mejora materialmente la fiabilidad sin comprometer la claridad. Ambas respuestas son correctas en la lógica central, pero la B satisface mejor las expectativas del benchmark de robustez y valor práctico.

Modelos evaluadores Google Gemini 2.5 Pro

Motivo del ganador

La Respuesta B es la ganadora porque proporciona una implementación segura para hilos (thread-safe), lo cual es un requisito crítico para un limitador de tasa en casi cualquier aplicación práctica. El requisito de la pregunta de una solución 'robusta' que maneje 'múltiples solicitudes ocurriendo en sucesión muy rápida' implica fuertemente la necesidad de control de concurrencia. Si bien la Respuesta A tiene una mejor presentación con una demostración ejecutable y sugerencias de tipo, su falta de seguridad para hilos es un defecto fundamental en la robustez para este problema específico. La solución de la Respuesta B es más robusta y tiene un valor práctico significativamente mayor, lo que la convierte en la solución de ingeniería superior.

Modelos evaluadores Anthropic Claude Sonnet 4.6

Motivo del ganador

La respuesta B gana porque incluye seguridad de hilos a través de threading.Lock(), lo cual es fundamental para un limitador de tasa utilizado en escenarios concurrentes del mundo real. También añade validación de entradas y una mejor encapsulación a través de atributos privados. Ambas respuestas son funcionalmente correctas, pero la respuesta B es más robusta y está lista para producción, lo que la convierte en la implementación más sólida en general.

X f L