Orivel Orivel
Abrir menu

Implemente um armazenamento chave-valor versionado com consultas históricas

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

Escreva um código que implemente um armazenamento chave-valor versionado em memória com suporte a leituras históricas. O armazenamento começa vazio e processa uma sequência de comandos. Cada comando mutante bem-sucedido cria exatamente um novo número de versão global, começando em 1. Comandos somente de leitura não devem criar uma versão. Chaves e valores são strings sensíveis a maiúsculas/minúsculas sem espaços. Versões são inteiros positivos. Comandos: SET key value Cria ou sobrescreve a chave com o valor. DEL...

Mostrar mais

Escreva um código que implemente um armazenamento chave-valor versionado em memória com suporte a leituras históricas. O armazenamento começa vazio e processa uma sequência de comandos. Cada comando mutante bem-sucedido cria exatamente um novo número de versão global, começando em 1. Comandos somente de leitura não devem criar uma versão. Chaves e valores são strings sensíveis a maiúsculas/minúsculas sem espaços. Versões são inteiros positivos. Comandos: SET key value Cria ou sobrescreve a chave com o valor. DELETE key Remove a chave se ela existir. GET key Retorna o valor atual da chave, ou NULL se a chave não existir. GET_VERSION key version Retorna o valor associado à chave imediatamente após a criação da versão global especificada, ou NULL se a chave não existia nessa versão. Se version for maior que a última versão existente, trate-o como inválido e retorne INVALID_VERSION. HISTORY key Retorna todos os estados históricos da chave em ordem crescente de versões, incluindo deleções, formatados como pares version:value separados por vírgulas. Use NULL para estados deletados ou ausentes após uma mutação. Se a chave nunca foi afetada por qualquer comando mutante, retorne EMPTY. Formato de entrada: A primeira linha contém um inteiro N, o número de comandos. As próximas N linhas contêm cada uma um comando. Formato de saída: Para cada comando GET, GET_VERSION e HISTORY, imprima uma linha com o resultado. Detalhes de comportamento e casos limítrofes: - Cada SET sempre cria uma nova versão, mesmo que o valor não tenha mudado. - Cada DELETE sempre cria uma nova versão, mesmo se a chave não existir. - As versões são globais entre todas as chaves, não por chave. - HISTORY de uma chave deve incluir apenas as versões em que essa chave foi diretamente afetada por SET ou DELETE. - Se uma chave foi deletada e depois definida novamente, ambos os eventos devem aparecer em HISTORY. - Eficiência importa: assuma até 200000 comandos, com muitas consultas históricas. Sua solução deve ler da entrada padrão e escrever na saída padrão. Inclua o programa completo funcionando em um único arquivo. Você pode usar qualquer linguagem de programação mainstream, mas o código deve ser completo e executável como está escrito.

Informacao complementar

Esta tarefa foi projetada para testar o tratamento cuidadoso da semântica de versões, casos limítrofes e escolhas de estruturas de dados escaláveis, em vez de apenas análise básica.

Politica de avaliacao

Uma boa resposta fornece um programa executável completo que segue corretamente as regras de versão global, distingue comandos somente de leitura de comandos mutantes, trata versões inválidas e chaves ausentes exatamente como especificado e escala para entradas grandes sem copiar ingênua do estado completo por versão. Respostas fortes também mantêm a implementação clara e robusta, com parsing correto e busca histórica eficiente.

Respostas

import sys import bisect def solve(): """ Implementa uma loja de chave-valor com versionamento que lê comandos do stdin e escreve resultados no stdout. """ try: n_str = sys.stdin.readline() if not n_str: return n = int(n_str.strip()) except (ValueError, IndexError): return # A estrutura de dados principal. # Um dicionário mapeando cada chave a uma lista de seus estados históricos. # Cada estado é uma tupla: (versão, valor). # A lista para cada chave é mantida ordenada por versão. # Um valor None representa uma exclusão....

Mostrar resposta completa

import sys import bisect def solve(): """ Implementa uma loja de chave-valor com versionamento que lê comandos do stdin e escreve resultados no stdout. """ try: n_str = sys.stdin.readline() if not n_str: return n = int(n_str.strip()) except (ValueError, IndexError): return # A estrutura de dados principal. # Um dicionário mapeando cada chave a uma lista de seus estados históricos. # Cada estado é uma tupla: (versão, valor). # A lista para cada chave é mantida ordenada por versão. # Um valor None representa uma exclusão. store = {} global_version = 0 for _ in range(n): line = sys.stdin.readline() if not line: continue parts = line.strip().split() command = parts[0] if command == "SET": # Cria ou sobrescreve uma chave com um valor, criando uma nova versão. key, value = parts[1], parts[2] global_version += 1 if key not in store: store[key] = [] store[key].append((global_version, value)) elif command == "DELETE": # Remove uma chave, criando uma nova versão. # Isso se aplica mesmo que a chave não exista. key = parts[1] global_version += 1 if key not in store: store[key] = [] store[key].append((global_version, None)) elif command == "GET": # Retorna o valor atual de uma chave. key = parts[1] if key not in store or not store[key]: print("NULL") else: # A última entrada na lista de histórico é o estado atual. _version, value = store[key][-1] print(value if value is not None else "NULL") elif command == "GET_VERSION": # Retorna o valor de uma chave em uma versão histórica específica. key, version_str = parts[1], parts[2] version = int(version_str) if version <= 0 or version > global_version: print("INVALID_VERSION") elif key not in store or not store[key]: print("NULL") else: history = store[key] # Cria uma lista apenas com os números de versão para busca eficiente. versions = [v for v, _val in history] # Encontra o ponto de inserção para a versão solicitada. # bisect_right encontra o índice onde a versão seria inserida # para manter a ordem. Isso significa que todos os elementos à esquerda deste # índice têm versões menores ou iguais à versão solicitada. idx = bisect.bisect_right(versions, version) if idx == 0: # Nenhuma versão histórica é <= à versão solicitada. print("NULL") else: # O estado que queremos está no índice anterior (idx - 1). _v, value = history[idx - 1] print(value if value is not None else "NULL") elif command == "HISTORY": # Retorna todos os estados históricos de uma chave. key = parts[1] if key not in store or not store[key]: print("EMPTY") else: history = store[key] result_parts = [] for v, val in history: str_val = val if val is not None else "NULL" result_parts.append(f"{v}:{str_val}") print(",".join(result_parts)) if __name__ == "__main__": solve()

Resultado

#2

Votos de vitoria

1 / 3

Pontuacao media

81
Modelos avaliadores Anthropic Claude Opus 4.6

Pontuacao total

79

Comentario geral

A Resposta A fornece uma implementação correta e completa do armazenamento chave-valor versionado. Ela lida com todos os comandos adequadamente, usa bisect para consultas históricas eficientes e inclui comentários claros e docstrings. No entanto, tem uma preocupação de desempenho: em GET_VERSION, ela cria uma nova lista de números de versão a cada chamada de consulta (`versions = [v for v, _val in history]`), o que é O(k) por consulta, onde k é o número de entradas de histórico para essa chave. Para 200.000 comandos com muitas consultas históricas, isso pode ser um gargalo de desempenho significativo. Ela também usa readline() em um loop, o que é mais lento do que a leitura em lote para entradas grandes. O código também não lida corretamente com a verificação de versão <= 0 para GET_VERSION - a especificação diz que as versões são inteiros positivos, e a versão 0 ou negativa deveria, argumentavelmente, ser INVALID_VERSION, o que a Resposta A lida. No geral, é uma solução sólida com um problema de eficiência notável.

Ver detalhes da avaliacao

Correcao

Peso 35%
85

A Resposta A lida corretamente com todos os comandos: SET, DELETE, GET, GET_VERSION, HISTORY. Ela usa corretamente bisect_right para consultas históricas, lida com NULL para chaves excluídas, retorna EMPTY para chaves nunca afetadas e verifica versões inválidas, incluindo versão <= 0. Todos os casos extremos mencionados na especificação parecem ser tratados corretamente.

Completude

Peso 20%
80

A Resposta A implementa todos os cinco comandos conforme especificado, lida com todos os casos extremos mencionados na solicitação, incluindo valores SET inalterados que criam novas versões, DELETE em chaves inexistentes que criam versões e formatação de HISTORY adequada. A solução é completa e executável.

Qualidade do codigo

Peso 20%
75

A Resposta A tem boa qualidade de código com nomes de variáveis claros, uma docstring e comentários inline úteis explicando a lógica. O código é bem estruturado e fácil de seguir. O uso de bisect é limpo, embora a criação de lista temporária em GET_VERSION seja um padrão desnecessário.

Valor pratico

Peso 15%
65

A Resposta A funciona corretamente, mas tem um problema de desempenho significativo: GET_VERSION cria uma nova lista de versões a cada chamada, tornando-a O(k) por consulta, mesmo antes da busca binária. Combinada com a leitura linha por linha e chamadas de impressão individuais, essa solução pode ter dificuldades com o limite declarado de 200.000 comandos com muitas consultas históricas.

Seguimento de instrucoes

Peso 10%
80

A Resposta A segue todas as instruções: lê da entrada padrão, escreve na saída padrão, é um programa executável completo em um arquivo, lida com todos os comandos e casos extremos especificados e usa uma abordagem de estrutura de dados eficiente (listas de histórico por chave com busca binária).

Modelos avaliadores Google Gemini 2.5 Flash

Pontuacao total

90

Comentario geral

A Resposta A fornece uma solução robusta e bem estruturada. Implementa corretamente todos os comandos, lida com casos extremos como chaves inexistentes e versões inválidas (incluindo versões não positivas para GET_VERSION) e utiliza estruturas de dados e algoritmos eficientes (como `bisect` para pesquisas históricas). A análise de entrada é padrão e robusta para processamento linha a linha. O código é claro, bem comentado e Pythonic.

Ver detalhes da avaliacao

Correcao

Peso 35%
95

A solução implementa corretamente todos os comandos e lida com os casos extremos especificados. Também interpreta corretamente 'As versões são inteiros positivos' tratando versões não positivas em GET_VERSION como INVALID_VERSION, o que é uma interpretação robusta dos requisitos implícitos do prompt.

Completude

Peso 20%
90

O programa está totalmente completo, executável e cobre todas as funcionalidades e formatos de entrada/saída exigidos. A leitura de entrada é robusta para processamento linha a linha.

Qualidade do codigo

Peso 20%
85

O código é bem estruturado, usa nomes de variáveis claros e inclui comentários úteis. Ele aproveita o módulo `bisect` para pesquisa binária eficiente e Pythonic, contribuindo para um código mais limpo e de fácil manutenção.

Valor pratico

Peso 15%
85

A solução usa estruturas de dados eficientes (dicionário de listas de tuplas) e algoritmos (pesquisa binária) para consultas históricas, tornando-a escalável. Seu tratamento robusto de entrada e verificações abrangentes de erros aprimoram sua utilidade prática.

Seguimento de instrucoes

Peso 10%
90

A solução segue meticulosamente todas as instruções explícitas, incluindo regras de versionamento, formatos de saída e considerações de eficiência. Também interpreta corretamente os requisitos implícitos, como o tratamento de versões não positivas como inválidas.

Modelos avaliadores OpenAI GPT-5.4

Pontuacao total

75

Comentario geral

A Resposta A é um programa executável completo e captura o modelo principal de histórico versionado para SET, DELETE, GET, GET_VERSION e HISTORY. Sua semântica está em grande parte alinhada com o prompt, incluindo versionamento global e registro de exclusões. No entanto, sua implementação GET_VERSION reconstrói uma lista de números de versão a cada consulta, o que adiciona sobrecarga desnecessária e prejudica a escalabilidade para a configuração de entrada grande declarada. Ele também trata versões não positivas como inválidas, o que é razoável, mas não explicitamente exigido além de as versões serem inteiros positivos. No geral, está correto em casos típicos, mas menos eficiente do que o esperado para consultas históricas intensivas.

Ver detalhes da avaliacao

Correcao

Peso 35%
77

A lógica para SET, DELETE, GET, GET_VERSION e HISTORY está em grande parte correta, incluindo versões globais e marcadores de exclusão. As consultas históricas retornam o estado mais recente em ou antes da versão solicitada, e versões futuras inválidas são tratadas. A principal ressalva de correção não é funcional em casos normais, mas está ligada a suposições de tratamento de borda e estilo de implementação de consulta.

Completude

Peso 20%
83

A resposta fornece um programa completo e funcional de arquivo único, lê a entrada padrão, escreve na saída padrão e cobre todos os comandos e saídas necessários. Ele também inclui o comportamento histórico necessário e o histórico de afetação direta apenas. Está completo para a tarefa, com apenas uma ambiguidade menor de caso de borda em torno de versões não positivas inválidas.

Qualidade do codigo

Peso 20%
68

O código é legível e razoavelmente organizado, com comentários claros e fluxo de controle direto. No entanto, a construção de uma lista de versões nova dentro de cada chamada GET_VERSION é uma fraqueza de design evitável, e a impressão linha por linha é menos otimizada para saída intensiva. A qualidade é sólida, mas não especialmente forte para um benchmark sensível ao desempenho.

Valor pratico

Peso 15%
61

O programa funcionará para muitas entradas comuns, mas chamadas repetidas de GET_VERSION em históricos grandes incorrerão em sobrecarga extra pela reconstrução de arrays de versão a cada vez. Isso o torna menos adequado para a carga de trabalho de alto volume descrita no prompt. É prático como uma linha de base, mas não ideal para as restrições do benchmark.

Seguimento de instrucoes

Peso 10%
87

A resposta segue a instrução de fornecer código executável completo e adere estritamente à semântica de comando e formato de saída especificados. Respeita o versionamento global e a criação de versão apenas por mutação. O tratamento de borda menor em torno de versões inválidas não prejudica materialmente a conformidade.

import sys from bisect import bisect_right def main(): input_data = sys.stdin.buffer.read().split() idx = 0 n = int(input_data[idx]); idx += 1 # For each key, store a list of (version, value_or_None) sorted by version history = {} # key -> list of (version, value) current_version = 0 output = [] for _ in range(n): cmd = input_data[idx].decode(); idx += 1 if cmd == 'SET': key = input_data[idx].decode(); idx += 1 value = input_data[idx].decode(); idx += 1 current_version += 1 if key not in history:...

Mostrar resposta completa

import sys from bisect import bisect_right def main(): input_data = sys.stdin.buffer.read().split() idx = 0 n = int(input_data[idx]); idx += 1 # For each key, store a list of (version, value_or_None) sorted by version history = {} # key -> list of (version, value) current_version = 0 output = [] for _ in range(n): cmd = input_data[idx].decode(); idx += 1 if cmd == 'SET': key = input_data[idx].decode(); idx += 1 value = input_data[idx].decode(); idx += 1 current_version += 1 if key not in history: history[key] = [] history[key].append((current_version, value)) elif cmd == 'DELETE': key = input_data[idx].decode(); idx += 1 current_version += 1 if key not in history: history[key] = [] history[key].append((current_version, None)) elif cmd == 'GET': key = input_data[idx].decode(); idx += 1 if key not in history or not history[key]: output.append('NULL') else: val = history[key][-1][1] output.append(val if val is not None else 'NULL') elif cmd == 'GET_VERSION': key = input_data[idx].decode(); idx += 1 version = int(input_data[idx]); idx += 1 if version > current_version: output.append('INVALID_VERSION') else: if key not in history or not history[key]: output.append('NULL') else: h = history[key] # Find the last entry with version <= requested version # Binary search on versions lo, hi = 0, len(h) - 1 res_idx = -1 while lo <= hi: mid = (lo + hi) // 2 if h[mid][0] <= version: res_idx = mid lo = mid + 1 else: hi = mid - 1 if res_idx == -1: output.append('NULL') else: val = h[res_idx][1] output.append(val if val is not None else 'NULL') elif cmd == 'HISTORY': key = input_data[idx].decode(); idx += 1 if key not in history or not history[key]: output.append('EMPTY') else: parts = [] for ver, val in history[key]: parts.append(f"{ver}:{val if val is not None else 'NULL'}") output.append(','.join(parts)) print('\n'.join(output)) main()

Resultado

#1 | Vencedor

Votos de vitoria

2 / 3

Pontuacao media

80
Modelos avaliadores Anthropic Claude Opus 4.6

Pontuacao total

81

Comentario geral

A Resposta B fornece uma implementação correta e completa com melhores características de desempenho. Ela lê toda a entrada de uma vez usando sys.stdin.buffer.read(), o que é significativamente mais rápido para entradas grandes. Implementa a busca binária manualmente em vez de usar bisect, evitando a necessidade de criar uma lista temporária de versões em cada chamada GET_VERSION - ela busca diretamente na lista de histórico. Coleta toda a saída e imprime de uma vez, o que também é mais eficiente. No entanto, não verifica se a versão <= 0 em GET_VERSION (embora a especificação diga que as versões são inteiros positivos, então este caso extremo pode não aparecer na prática). O código é ligeiramente menos legível devido ao rastreamento manual de índice para análise, mas este é um padrão comum para programação competitiva e código crítico de desempenho.

Ver detalhes da avaliacao

Correcao

Peso 35%
85

A Resposta B lida corretamente com todos os comandos com a lógica apropriada. A busca binária manual encontra corretamente a última entrada com versão <= versão solicitada. Ela lida com NULL para exclusões, EMPTY para chaves não afetadas e INVALID_VERSION para versões além da atual. Preocupação menor: ela não verifica explicitamente se a versão <= 0, mas isso é improvável de aparecer em casos de teste válidos, dado que a especificação diz que as versões são inteiros positivos.

Completude

Peso 20%
80

A Resposta B implementa todos os cinco comandos conforme especificado e lida com os casos extremos chave. É um programa completo e executável que cobre a especificação completa. A única lacuna menor é a falta de tratamento explícito para versão <= 0 em GET_VERSION.

Qualidade do codigo

Peso 20%
70

A Resposta B usa um estilo de programação competitiva menos legível, mas comum, com rastreamento manual de índice para análise. A busca binária manual é ligeiramente mais difícil de ler do que usar bisect. No entanto, o código ainda é razoavelmente claro e bem organizado. Falta comentários e documentação em comparação com a Resposta A.

Valor pratico

Peso 15%
85

A Resposta B é bem otimizada para a escala declarada: leitura de entrada em lote via buffer, busca binária direta na lista de histórico sem alocações temporárias e saída em lote. Essas otimizações a tornam prática para a restrição de 200.000 comandos e representam uma boa engenharia para cenários sensíveis ao desempenho.

Seguimento de instrucoes

Peso 10%
80

A Resposta B segue todas as instruções: lê de stdin, escreve para stdout, é um programa completo e executável em um arquivo, lida com todos os comandos e casos extremos especificados e usa estruturas de dados eficientes. A nota de eficiência na solicitação é bem abordada pela abordagem otimizada de I/O e busca.

Modelos avaliadores Google Gemini 2.5 Flash

Pontuacao total

77

Comentario geral

A Resposta B fornece uma solução em grande parte correta com estruturas de dados eficientes. No entanto, tem um pequeno problema de correção ao não tratar explicitamente versões não positivas para GET_VERSION como inválidas. A estratégia de análise de entrada (lendo toda a entrada de uma vez) é menos robusta para entradas muito grandes em comparação com o processamento linha a linha, e a implementação manual da busca binária é menos idiomática do que usar o módulo `bisect`. O código também carece de comentários, o que reduz sua legibilidade.

Ver detalhes da avaliacao

Correcao

Peso 35%
80

A solução está em grande parte correta, mas falha em tratar explicitamente versões não positivas para GET_VERSION. Embora o prompt afirme 'Versões são inteiros positivos', ele não define explicitamente o comportamento para versões não positivas. No entanto, tratá-las como INVALID_VERSION (como faz a Resposta A) é o comportamento mais robusto e esperado para entrada inválida.

Completude

Peso 20%
85

O programa está totalmente completo e executável. No entanto, sua estratégia de leitura de entrada (lendo toda a entrada de uma vez) pode ser menos eficiente em termos de memória e robusta para entradas extremamente grandes em comparação com o processamento linha a linha, embora possa ser aceitável para a contagem de comandos especificada.

Qualidade do codigo

Peso 20%
65

O código carece de comentários, tornando-o mais difícil de entender rapidamente. Ele implementa uma busca binária manual em vez de usar o módulo `bisect`, que é menos idiomático em Python e potencialmente mais propenso a erros. O mecanismo de análise de entrada também é um pouco menos limpo.

Valor pratico

Peso 15%
75

A solução usa estruturas de dados e algoritmos eficientes para escalabilidade. No entanto, o tratamento de entrada menos robusto e a verificação de caso de borda ausente para GET_VERSION diminuem ligeiramente seu valor prático em comparação com a Resposta A.

Seguimento de instrucoes

Peso 10%
75

A solução segue a maioria das instruções relativas à implementação de comandos e formato de saída. No entanto, ela perde a instrução implícita de tratar versões não positivas como inválidas para GET_VERSION, o que é implícito por 'Versões são inteiros positivos'.

Modelos avaliadores OpenAI GPT-5.4

Pontuacao total

84

Comentario geral

A Resposta B é um programa executável completo que implementa corretamente a semântica de versão global exigida, consultas históricas, rastreamento de exclusões e formatação de saída. É notavelmente mais forte em escalabilidade, usando entrada com buffer, saída acumulada e busca binária diretamente no histórico de cada chave sem recriar arrays auxiliares por consulta. A estrutura é concisa e prática para um grande número de comandos. Um pequeno problema é que ele apenas sinaliza versões maiores que a mais recente como inválidas e não rejeita explicitamente versões não positivas, mas esta é uma lacuna de caso de borda menor em relação a uma solução de outra forma forte.

Ver detalhes da avaliacao

Correcao

Peso 35%
84

A implementação modela corretamente os incrementos de versão global apenas em mutações, rastreia o histórico por chave e retorna valores atuais e históricos adequados, incluindo exclusões. A formatação do HISTÓRICO também segue a solicitação. A principal lacuna menor é que versões não positivas não são explicitamente tratadas como inválidas, embora versões futuras sejam tratadas corretamente.

Completude

Peso 20%
85

A resposta é uma solução executável completa em um arquivo com todos os comandos necessários implementados e comportamento de saída coberto. Ele lida com os principais casos de borda da solicitação, incluindo exclusões de chaves ausentes e versões futuras inválidas. Apenas o caso de borda de versão não positiva não é explicitamente abordado.

Qualidade do codigo

Peso 20%
78

O código é conciso, organizado e usa entrada com buffer eficiente e saída em lote. Sua busca binária manual funciona diretamente no histórico armazenado e evita alocações extras por consulta. Há uma pequena importação não utilizada porque bisect_right é importado, mas não usado, mas, no geral, a qualidade da implementação é mais forte e mais consciente do desempenho.

Valor pratico

Peso 15%
86

A solução é bem adequada à escala declarada, usando entrada com buffer tokenizada, agregação de saída e consulta histórica logarítmica sem cópias desnecessárias. Essas escolhas a tornam muito mais prática para centenas de milhares de comandos com muitas consultas históricas.

Seguimento de instrucoes

Peso 10%
88

A resposta segue o formato solicitado e fornece um programa executável completo que corresponde de perto ao comportamento especificado. Ele respeita as regras de versão global e a semântica de histórico de afetação direta. O único pequeno problema de conformidade é não marcar explicitamente versões não positivas como inválidas.

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

1 / 3

Pontuacao media

81
Ver esta resposta

Votos de vitoria

2 / 3

Pontuacao media

80
Ver esta resposta

Resultados da avaliacao

Modelos avaliadores OpenAI GPT-5.4

Motivo do vencedor

A resposta B vence porque corresponde ao comportamento exigido, sendo ao mesmo tempo mais escalável e eficiente na implementação para as restrições de entrada grande do benchmark. Ambas as respostas estão amplamente corretas, mas B evita reconstruir arrays de versão por consulta, usa padrões de I/O mais rápidos e é, portanto, mais prático para muitas consultas históricas. A é aceitável, no entanto, sua abordagem GET_VERSION é menos eficiente e mais fraca para as expectativas de desempenho declaradas.

Modelos avaliadores Google Gemini 2.5 Flash

Motivo do vencedor

A Resposta A é superior devido à sua correção completa, especialmente no tratamento do caso de borda de versões não positivas para GET_VERSION, que a Resposta B não aborda. A Resposta A também demonstra melhor qualidade de código ao utilizar o módulo `bisect` da biblioteca padrão do Python para busca eficiente e fornecer comentários claros. Seu método de tratamento de entrada também é geralmente mais robusto para entradas grandes.

Modelos avaliadores Anthropic Claude Opus 4.6

Motivo do vencedor

A Resposta B vence principalmente pelo valor prático e eficiência. Ambas as soluções estão funcionalmente corretas e tratam os requisitos principais adequadamente. No entanto, a Resposta B é significativamente mais eficiente: (1) lê toda a entrada de uma vez via leitura de buffer, (2) realiza busca binária diretamente na lista de histórico sem criar listas temporárias, (3) agrupa toda a saída em uma única chamada de impressão. Essas otimizações são importantes dadas as restrições de até 200.000 comandos com muitas consultas históricas. O GET_VERSION da Resposta A cria uma nova list comprehension a cada chamada, o que representa um overhead O(k) por consulta. Embora a Resposta A tenha uma legibilidade de código e documentação ligeiramente melhores, a diferença de desempenho é significativa para os requisitos de escala declarados.

X f L