Orivel Orivel
Abrir menu

Implemente uma classe TokenBucket de limitador de taxa

Compare respostas de modelos para esta tarefa benchmark em Programação e revise pontuacoes, comentarios e exemplos relacionados.

Entre ou cadastre-se para usar curtidas e favoritos. Cadastrar

X f L

Indice

Visao geral da tarefa

Generos de Comparacao

Programação

Modelo criador da tarefa

Modelos participantes

Modelos avaliadores

Enunciado da tarefa

Implemente uma classe `TokenBucket` numa linguagem de programação de sua escolha (por exemplo, Python, JavaScript, Java, C++). A classe deve ter: 1. Um construtor que aceite dois argumentos: - `capacity`: Um inteiro que representa o número máximo de tokens que o bucket pode conter. - `refill_rate`: Um número que representa a taxa na qual tokens são adicionados ao bucket por segundo. 2. Um método `allow_request()`: - Este método não recebe argumentos. - Deve retornar `True` se uma requisição for per...

Mostrar mais

Implemente uma classe `TokenBucket` numa linguagem de programação de sua escolha (por exemplo, Python, JavaScript, Java, C++). A classe deve ter: 1. Um construtor que aceite dois argumentos: - `capacity`: Um inteiro que representa o número máximo de tokens que o bucket pode conter. - `refill_rate`: Um número que representa a taxa na qual tokens são adicionados ao bucket por segundo. 2. Um método `allow_request()`: - Este método não recebe argumentos. - Deve retornar `True` se uma requisição for permitida (isto é, se houver pelo menos um token no bucket), e `False` caso contrário. - Se uma requisição for permitida, deve consumir um token do bucket. Sua implementação deve ser autocontida e não deve depender de bibliotecas externas para a lógica principal. Você deve gerenciar o estado do bucket (número atual de tokens e o tempo da última verificação) dentro da instância da classe.

Informacao complementar

O algoritmo do token bucket é um método comum para limitação de taxa. Funciona da seguinte maneira: - O bucket tem uma `capacity` fixa. - Tokens são adicionados ao bucket a uma `refill_rate` constante. - Se o bucket estiver cheio, quaisquer novos tokens adicionados são descartados. - Cada requisição entrante tenta consumir um token do bucket. - Se um token estiver disponível, a requisição é permitida e a contagem de tokens é decrementada. - Se não houver tokens disponíveis, a requisição é negada. Este algoritmo pe...

Mostrar mais

O algoritmo do token bucket é um método comum para limitação de taxa. Funciona da seguinte maneira: - O bucket tem uma `capacity` fixa. - Tokens são adicionados ao bucket a uma `refill_rate` constante. - Se o bucket estiver cheio, quaisquer novos tokens adicionados são descartados. - Cada requisição entrante tenta consumir um token do bucket. - Se um token estiver disponível, a requisição é permitida e a contagem de tokens é decrementada. - Se não houver tokens disponíveis, a requisição é negada. Este algoritmo permite rajadas de requisições até a `capacity` do bucket e, em seguida, regula (throttle) as requisições à `refill_rate` no longo prazo. Sua implementação deve calcular com precisão o número de tokens a adicionar com base no tempo decorrido desde que a última requisição foi processada.

Politica de avaliacao

Uma resposta de alta qualidade fornecerá uma implementação correta, robusta e bem escrita da classe `TokenBucket`. - **Correctness:** A lógica principal deve ser implementada corretamente. Isso inclui calcular com precisão o número de tokens a adicionar com base no tempo decorrido, garantir que a contagem de tokens nunca exceda a capacity e consumir corretamente tokens para requisições permitidas. - **Robustness:** A solução deve lidar com casos de borda, como a primeira requisição feita, múltiplas requisições oco...

Mostrar mais

Uma resposta de alta qualidade fornecerá uma implementação correta, robusta e bem escrita da classe `TokenBucket`. - **Correctness:** A lógica principal deve ser implementada corretamente. Isso inclui calcular com precisão o número de tokens a adicionar com base no tempo decorrido, garantir que a contagem de tokens nunca exceda a capacity e consumir corretamente tokens para requisições permitidas. - **Robustness:** A solução deve lidar com casos de borda, como a primeira requisição feita, múltiplas requisições ocorrendo em sucessão muito rápida e longos períodos de inatividade entre requisições. O cálculo para reabastecimento de tokens deve ser preciso e não deve sofrer de imprecisões em ponto flutuante que se acumulem ao longo do tempo. - **Code Quality:** O código deve ser limpo, legível e idiomático para a linguagem escolhida. Deve ser bem estruturado, com nomes de variáveis claros e comentários onde a lógica não for óbvia. - **State Management:** A implementação deve gerenciar corretamente seu estado interno (por exemplo, o número de tokens e o timestamp da última atualização) através de múltiplas chamadas para `allow_request()`.

Respostas

import time class TokenBucket: """Um limitador de taxa de balde de tokens. Os tokens são adicionados a uma `refill_rate` (tokens por segundo) constante até a `capacity`. Cada chamada para `allow_request()` tenta consumir um token. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Número máximo de tokens que o balde pode conter. refill_rate: Número de tokens adicionados ao balde por segundo. """ self.capacity: int = capacity self.refill_rate: float = refill_rate self.tokens: float =...

Mostrar resposta completa

import time class TokenBucket: """Um limitador de taxa de balde de tokens. Os tokens são adicionados a uma `refill_rate` (tokens por segundo) constante até a `capacity`. Cada chamada para `allow_request()` tenta consumir um token. """ def __init__(self, capacity: int, refill_rate: float) -> None: """ Args: capacity: Número máximo de tokens que o balde pode conter. refill_rate: Número de tokens adicionados ao balde por segundo. """ self.capacity: int = capacity self.refill_rate: float = refill_rate self.tokens: float = float(capacity) # começa cheio self.last_refill_time: float = time.monotonic() def _refill(self) -> None: """Adiciona tokens com base no tempo decorrido desde o último reabastecimento.""" 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: """Tenta consumir um token. Returns: True se a solicitação for permitida (um token estava disponível e foi consumido), False caso contrário. """ self._refill() if self.tokens >= 1: self.tokens -= 1 return True return False # --------------------------------------------------------------------------- # Demonstração rápida / teste de fumaça # --------------------------------------------------------------------------- if __name__ == "__main__": bucket = TokenBucket(capacity=5, refill_rate=2) # 5 máx, 2 tokens/seg # Rajada: deve permitir 5 solicitações imediatamente for i in range(7): result = bucket.allow_request() print(f"Solicitação {i + 1}: {'permitida' if result else 'negada'}") # Espera um pouco para os tokens serem reabastecidos print("\nDormindo 1.5 segundos...") time.sleep(1.5) # deve reabastecer ~3 tokens for i in range(5): result = bucket.allow_request() print(f"Solicitação {i + 1}: {'permitida' if result else 'negada'}")

Resultado

#2

Votos de vitoria

0 / 3

Pontuacao media

79
Modelos avaliadores Anthropic Claude Sonnet 4.6

Pontuacao total

80

Comentario geral

A Resposta A fornece uma implementação limpa, correta e bem documentada da classe TokenBucket. Utiliza time.monotonic() para um tempo preciso, reabastece corretamente os tokens com base no tempo decorrido, limita os tokens à capacidade e consome um token por solicitação permitida. O código é legível, com boas docstrings e inclui uma demonstração/teste de fumaça útil. No entanto, falta segurança de thread (nenhum mecanismo de bloqueio), o que é uma omissão notável para um limitador de taxa que seria tipicamente usado em ambientes concorrentes. Também falta validação de entrada para os argumentos do construtor.

Ver detalhes da avaliacao

Correcao

Peso 35%
85

A lógica principal está correta: os tokens são reabastecidos com base no tempo decorrido usando time.monotonic(), limitados à capacidade e um token é consumido por solicitação permitida. No entanto, a falta de segurança de thread significa que a implementação pode produzir resultados incorretos em uso concorrente devido a condições de corrida.

Completude

Peso 20%
75

A implementação abrange todos os elementos necessários: construtor com capacidade e taxa de reabastecimento, método allow_request() e gerenciamento de estado interno. Inclui uma demonstração executável. No entanto, faltam segurança de thread e validação de entrada, que são importantes para uma implementação completa.

Qualidade do codigo

Peso 20%
80

O código é limpo, legível e bem documentado com docstrings claras e dicas de tipo. Os nomes das variáveis são descritivos. A separação da lógica de reabastecimento em um método privado é um bom design. Dedução menor pela falta de convenções de nomenclatura de atributos privados.

Valor pratico

Peso 15%
70

A implementação é praticamente útil para cenários de thread única e inclui uma demonstração útil. No entanto, a falta de segurança de thread limita significativamente seu valor prático em aplicações do mundo real onde os limitadores de taxa são tipicamente usados em ambientes concorrentes.

Seguimento de instrucoes

Peso 10%
90

Segue todas as instruções: implementa a classe TokenBucket em Python, o construtor aceita capacidade e taxa de reabastecimento, allow_request() não aceita argumentos e retorna True/False enquanto consome um token. Usa apenas a biblioteca padrão (módulo time). O estado é gerenciado dentro da instância.

Modelos avaliadores Google Gemini 2.5 Pro

Pontuacao total

82

Comentario geral

A Resposta A fornece uma implementação correta e bem escrita para um ambiente de thread única. Seus pontos fortes são código limpo com dicas de tipo Python modernas, lógica clara e uma excelente demonstração executável que verifica seu comportamento. No entanto, sua principal fraqueza é a falta de segurança de thread, o que a torna inadequada para a maioria das aplicações do mundo real de um limitador de taxa, onde requisições concorrentes são comuns.

Ver detalhes da avaliacao

Correcao

Peso 35%
80

A implementação é logicamente correta para um contexto de thread única. O cálculo de reabastecimento de tokens e a limitação de capacidade são implementados corretamente. No entanto, não é correta em um ambiente concorrente, que é um caso de uso comum para este algoritmo.

Completude

Peso 20%
90

A resposta é muito completa, fornecendo não apenas a implementação da classe, mas também um script de demonstração executável em `if __name__ == "__main__":`. Esta demonstração mostra efetivamente o comportamento de rajada e reabastecimento, tornando-a fácil de entender e verificar.

Qualidade do codigo

Peso 20%
85

A qualidade do código é alta. Utiliza recursos modernos do Python, como dicas de tipo, possui docstrings claras e segue boas convenções de nomenclatura. A lógica é bem estruturada com um método auxiliar privado para reabastecimento.

Valor pratico

Peso 15%
60

O valor prático é limitado porque a implementação não é segura para threads. Limitadores de taxa são quase sempre usados em ambientes concorrentes (como servidores web), onde esta implementação estaria sujeita a condições de corrida e não funcionaria de forma confiável.

Seguimento de instrucoes

Peso 10%
100

A resposta segue perfeitamente todas as instruções do prompt, implementando a classe, construtor e método especificados com a lógica correta. A solução é autocontida.

Modelos avaliadores OpenAI GPT-5.4

Pontuacao total

75

Comentario geral

A Resposta A fornece uma implementação Python correta e legível de um token bucket. Utiliza um relógio monotónico, rastreia o estado interno corretamente, reabastece com base no tempo decorrido, limita os tokens à capacidade e consome um token por pedido permitido. As principais fraquezas são a falta de validação de entrada, nenhuma proteção para acesso concorrente e uma abordagem básica baseada em ponto flutuante sem abordar as preocupações de precisão mencionadas na solicitação. A demonstração incluída é útil, mas não necessária para a tarefa principal.

Ver detalhes da avaliacao

Correcao

Peso 35%
78

A lógica de reabastecimento e consumo está correta: o tempo decorrido é medido com um relógio monotónico, os tokens são adicionados proporcionalmente, limitados à capacidade e um token é consumido quando disponível. Lida corretamente com o primeiro uso e longos períodos de inatividade. A pontuação é prejudicada porque não aborda parâmetros inválidos e usa acumulação direta de ponto flutuante sem qualquer mitigação.

Completude

Peso 20%
70

Inclui o construtor necessário, o estado interno e o método allow_request, e a implementação é autocontida. No entanto, não cobre a validação de parâmetros nem discute condições de contorno, como capacidade inválida ou taxa de reabastecimento.

Qualidade do codigo

Peso 20%
76

O código é limpo, legível e idiomático, com boa nomenclatura e docstrings úteis. A estrutura é simples e fácil de seguir. Perde alguns pontos porque o estado público é exposto diretamente e o código de demonstração extra não faz parte da implementação principal.

Valor pratico

Peso 15%
66

É utilizável para cenários simples de thread única e demonstra o comportamento com um teste rápido. Em cenários mais realistas, a falta de validação e segurança de thread reduz a utilidade operacional.

Seguimento de instrucoes

Peso 10%
88

Segue bem a tarefa implementando uma classe TokenBucket autocontida com o construtor e o comportamento allow_request necessários. O único pequeno problema é a inclusão de código de demonstração extra além da resposta principal solicitada.

import time import threading class TokenBucket: """ Um simples limitador de taxa de balde de tokens. Args: capacity (int): número máximo de tokens no balde. refill_rate (float): tokens adicionados por segundo. Methods: allow_request() -> bool: retorna True e consome um token se disponível, caso contrário False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity must be > 0") if refill_rate < 0: raise ValueError("refill_rate must be >= 0") self.capacity = float(capacity)...

Mostrar resposta completa

import time import threading class TokenBucket: """ Um simples limitador de taxa de balde de tokens. Args: capacity (int): número máximo de tokens no balde. refill_rate (float): tokens adicionados por segundo. Methods: allow_request() -> bool: retorna True e consome um token se disponível, caso contrário False. """ def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity must be > 0") if refill_rate < 0: raise ValueError("refill_rate must be >= 0") self.capacity = float(capacity) self.refill_rate = float(refill_rate) # tokens atuais podem ser fracionários para contabilizar o reabastecimento parcial self._tokens = float(capacity) self._last_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """Reabastece tokens com base no tempo decorrido desde o último reabastecimento.""" now = time.monotonic() elapsed = now - self._last_time if elapsed <= 0: return added = elapsed * self.refill_rate # limita tokens à capacidade self._tokens = min(self.capacity, self._tokens + added) self._last_time = now def allow_request(self): """ Tenta consumir um token. Returns: bool: True se um token estava disponível e foi consumido, False caso contrário. """ with self._lock: self._refill() if self._tokens >= 1.0: self._tokens -= 1.0 return True return False # Exemplo de uso: # bucket = TokenBucket(capacity=10, refill_rate=1.5) # 1.5 tokens por segundo # if bucket.allow_request(): # # process request # else: # # reject or throttle request

Resultado

#1 | Vencedor

Votos de vitoria

3 / 3

Pontuacao media

86
Modelos avaliadores Anthropic Claude Sonnet 4.6

Pontuacao total

87

Comentario geral

A Resposta B fornece uma implementação correta, robusta e de qualidade de produção da classe TokenBucket. Inclui toda a lógica principal da Resposta A, mas adiciona melhorias importantes: segurança de thread via threading.Lock(), validação de entrada com mensagens de erro significativas para argumentos inválidos do construtor e convenções de nomenclatura privada (_tokens, _last_time, _lock) para melhor encapsulamento. A proteção contra elapsed <= 0 é um toque defensivo menor. O código é limpo, bem documentado e segue as convenções do Python. A única fraqueza menor é a falta de uma demonstração executável, mas os comentários de exemplo de uso compensam parcialmente.

Ver detalhes da avaliacao

Correcao

Peso 35%
90

A lógica principal está correta e adicionalmente protegida por um threading.Lock(), prevenindo condições de corrida em ambientes concorrentes. A validação de entrada garante que o objeto esteja sempre em um estado válido. A proteção elapsed <= 0 é uma verificação defensiva menor, mas sensata.

Completude

Peso 20%
85

A implementação abrange todos os elementos necessários e vai além com segurança de thread, validação de entrada e encapsulamento adequado. Os comentários de exemplo de uso fornecem orientação. A única lacuna menor é a ausência de uma demonstração executável, mas isso é uma preocupação menor.

Qualidade do codigo

Peso 20%
85

O código é limpo, legível e bem estruturado. Usa convenções de nomenclatura privada (_tokens, _last_time, _lock) para melhor encapsulamento, inclui docstrings claras e segue as convenções do Python. A docstring de nível de classe é abrangente. Ligeiramente melhor que A em termos de encapsulamento e programação defensiva.

Valor pratico

Peso 15%
85

A implementação é altamente prática para uso no mundo real. A segurança de thread a torna adequada para aplicações concorrentes, a validação de entrada evita o uso indevido e a API limpa facilita a integração. Os comentários de exemplo de uso auxiliam ainda mais na adoção prática.

Seguimento de instrucoes

Peso 10%
90

Segue todas as instruções: implementa a classe TokenBucket em Python, o construtor aceita capacidade e taxa de recarga, allow_request() não aceita argumentos e retorna True/False enquanto consome um token. Usa apenas a biblioteca padrão (módulos time, threading). O estado é gerenciado dentro da instância.

Modelos avaliadores Google Gemini 2.5 Pro

Pontuacao total

85

Comentario geral

A Resposta B fornece uma implementação robusta e prática do algoritmo token bucket. Seus pontos fortes são a segurança de thread, alcançada com um lock, e a inclusão de validação de entrada, tornando-a adequada para uso em ambientes concorrentes e semelhantes à produção. Embora o código seja bem estruturado, faltam dicas de tipo e uma demonstração executável, o que teria melhorado sua clareza e completude.

Ver detalhes da avaliacao

Correcao

Peso 35%
90

A implementação é logicamente correta tanto para contextos single-threaded quanto multi-threaded devido ao uso de um lock. Isso torna a solução correta em uma gama muito mais ampla e realista de cenários.

Completude

Peso 20%
65

A resposta fornece a classe necessária, mas inclui apenas um trecho comentado para uso de exemplo. Falta uma demonstração executável ou casos de teste para verificar sua funcionalidade, tornando-a menos completa que a Resposta A.

Qualidade do codigo

Peso 20%
80

A qualidade do código é boa, com docstrings claras, nomes de variáveis sensatos e a inclusão de validação de entrada, que é uma boa prática. No entanto, faltam dicas de tipo, que são padrão em Python moderno para melhorar a legibilidade e a manutenibilidade.

Valor pratico

Peso 15%
95

O valor prático é extremamente alto. Ao incluir um lock de thread, a implementação é thread-safe e pronta para ser usada em aplicações multi-threaded do mundo real. A adição de validação de entrada aumenta ainda mais sua praticidade e robustez.

Seguimento de instrucoes

Peso 10%
100

A resposta segue perfeitamente todas as instruções do prompt, implementando a classe, construtor e método especificados com a lógica correta. A solução é autônoma, pois `threading` faz parte da biblioteca padrão.

Modelos avaliadores OpenAI GPT-5.4

Pontuacao total

84

Comentario geral

A Resposta B fornece uma implementação Python correta e mais robusta. Utiliza um relógio monotónico, valida as entradas do construtor, gere o estado de forma limpa, limita os recarregamentos corretamente e consome tokens de forma segura. Também adiciona segurança de thread com um bloqueio, tornando-a mais prática em aplicações reais. O seu único inconveniente menor é que ainda depende de aritmética de ponto flutuante sem qualquer mitigação especial para acumulação de precisão a longo prazo, mas, no geral, é mais forte e mais orientada para a produção.

Ver detalhes da avaliacao

Correcao

Peso 35%
84

A lógica principal do balde de tokens está correta e as atualizações de estado são feitas de forma consistente. Recarrega corretamente com base no tempo monotónico decorrido, limita à capacidade e consome um token por pedido bem-sucedido. A validação de entrada fortalece a correção e o bloqueio evita inconsistências relacionadas com corridas em uso multithreaded. Redução menor apenas porque ainda usa aritmética de ponto flutuante simples.

Completude

Peso 20%
82

Implementa totalmente a classe e os métodos solicitados, gere o estado interno corretamente e permanece autocontido. Também abrange o tratamento de casos de ponta importantes através da validação do construtor e padrões de acesso seguros, tornando-o mais completo do que o requisito base.

Qualidade do codigo

Peso 20%
83

O código está bem estruturado, legível e prático, com nomes claros, comentários concisos e bom encapsulamento através de atributos sublinhados. O uso do bloqueio está limpo e a implementação mantém o foco na própria classe.

Valor pratico

Peso 15%
85

Está mais próximo do uso em produção porque valida as entradas e é seguro sob acesso concorrente. A implementação ainda é compacta e fácil de adotar diretamente em aplicações, o que lhe confere um forte valor prático.

Seguimento de instrucoes

Peso 10%
92

Segue as instruções muito bem: fornece uma classe TokenBucket autocontida com o construtor, gestão de estado e comportamento allow_request necessários. A resposta mantém o foco e alinha-se estreitamente com a implementação esperada apenas de código.

Resumo comparativo

Para cada tarefa e discussao, a classificacao final e definida por agregacao de rankings por avaliador (rank medio + desempate por Borda). A pontuacao media e exibida como referencia.

Avaliadores: 3

Votos de vitoria

0 / 3

Pontuacao media

79
Ver esta resposta

Votos de vitoria

3 / 3

Pontuacao media

86
Ver esta resposta

Resultados da avaliacao

Modelos avaliadores OpenAI GPT-5.4

Motivo do vencedor

A Resposta B vence porque corresponde ao comportamento exigido do balde de tokens, sendo ao mesmo tempo mais robusta e prática. Comparada com a Resposta A, adiciona validação de entrada e segurança de thread, o que melhora materialmente a fiabilidade sem comprometer a clareza. Ambas as respostas estão corretas na lógica central, mas a B satisfaz melhor as expectativas do benchmark em termos de robustez e valor prático.

Modelos avaliadores Google Gemini 2.5 Pro

Motivo do vencedor

A Resposta B é a vencedora porque fornece uma implementação thread-safe, que é um requisito crítico para um limitador de taxa em quase qualquer aplicação prática. O requisito da solicitação para uma solução 'robusta' que lida com 'múltiplas solicitações ocorrendo em sucessão muito rápida' implica fortemente a necessidade de controle de concorrência. Embora a Resposta A tenha uma melhor apresentação com uma demonstração executável e dicas de tipo, sua falta de thread-safety é uma falha fundamental em robustez para este problema específico. A solução da Resposta B é mais robusta e tem um valor prático significativamente maior, tornando-a a solução de engenharia superior.

Modelos avaliadores Anthropic Claude Sonnet 4.6

Motivo do vencedor

A Resposta B vence porque inclui segurança de threads através de threading.Lock(), que é crítica para um limitador de taxa usado em cenários concorrentes do mundo real. Também adiciona validação de entrada e melhor encapsulamento através de atributos privados. Ambas as respostas estão funcionalmente corretas, mas a Resposta B é mais robusta e pronta para produção, tornando-a a implementação mais forte no geral.

X f L