Respuesta A: Google Gemini 2.5 Pro
import sys import bisect def solve(): """ Implementa una tienda de clave-valor versionada que lee comandos de stdin y escribe resultados en stdout. """ try: n_str = sys.stdin.readline() if not n_str: return n = int(n_str.strip()) except (ValueError, IndexError): return # La estructura de datos principal. # Un diccionario que mapea cada clave a una lista de sus estados históricos. # Cada estado es una tupla: (versión, valor). # La lista para cada clave se mantiene ordenada por versión. # Un valor de None representa una elimin...
Mostrar respuesta completa ▼
import sys import bisect def solve(): """ Implementa una tienda de clave-valor versionada que lee comandos de stdin y escribe resultados en stdout. """ try: n_str = sys.stdin.readline() if not n_str: return n = int(n_str.strip()) except (ValueError, IndexError): return # La estructura de datos principal. # Un diccionario que mapea cada clave a una lista de sus estados históricos. # Cada estado es una tupla: (versión, valor). # La lista para cada clave se mantiene ordenada por versión. # Un valor de None representa una eliminación. 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": # Crea o sobrescribe una clave con un valor, creando una nueva versión. 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": # Elimina una clave, creando una nueva versión. # Esto se aplica incluso si la clave no existe. key = parts[1] global_version += 1 if key not in store: store[key] = [] store[key].append((global_version, None)) elif command == "GET": # Devuelve el valor actual de una clave. key = parts[1] if key not in store or not store[key]: print("NULL") else: # La última entrada en la lista de historial es el estado actual. _version, value = store[key][-1] print(value if value is not None else "NULL") elif command == "GET_VERSION": # Devuelve el valor de una clave en una versión 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] # Crea una lista solo con los números de versión para una búsqueda eficiente. versions = [v for v, _val in history] # Encuentra el punto de inserción para la versión solicitada. # bisect_right encuentra el índice donde la versión se insertaría # para mantener el orden. Esto significa que todos los elementos a la izquierda de este # índice tienen versiones menores o iguales a la versión solicitada. idx = bisect.bisect_right(versions, version) if idx == 0: # Ninguna versión histórica es <= a la versión solicitada. print("NULL") else: # El estado que queremos está en el índice anterior (idx - 1). _v, value = history[idx - 1] print(value if value is not None else "NULL") elif command == "HISTORY": # Devuelve todos los estados históricos de una clave. 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
Votos ganadores
1 / 3
Puntuacion media
Puntuacion total
Comentario general
La respuesta A proporciona una implementación correcta y completa de la tienda clave-valor versionada. Maneja todos los comandos adecuadamente, utiliza bisect para búsquedas históricas eficientes e incluye comentarios y docstrings claros. Sin embargo, tiene un problema de rendimiento: en GET_VERSION, crea una nueva lista de números de versión en cada llamada de consulta (`versions = [v for v, _val in history]`), lo que es O(k) por consulta, donde k es el número de entradas de historial para esa clave. Para 200.000 comandos con muchas consultas históricas, esto podría ser un cuello de botella de rendimiento significativo. También utiliza readline() en un bucle, lo que es más lento que la lectura masiva para entradas grandes. El código tampoco maneja correctamente la verificación de versión <= 0 para GET_VERSION: la especificación dice que las versiones son enteros positivos, y la versión 0 o negativa debería ser argumentablemente INVALID_VERSION, lo que la Respuesta A sí maneja. En general, es una solución sólida con un problema de eficiencia notable.
Ver detalle de evaluacion ▼
Correccion
Peso 35%La respuesta A maneja correctamente todos los comandos: SET, DELETE, GET, GET_VERSION, HISTORY. Utiliza correctamente bisect_right para búsquedas históricas, maneja NULL para claves eliminadas, devuelve EMPTY para claves nunca afectadas y verifica versiones inválidas, incluidas versiones <= 0. Todos los casos extremos mencionados en la especificación parecen manejarse correctamente.
Integridad
Peso 20%La respuesta A implementa los cinco comandos según lo especificado, maneja todos los casos extremos mencionados en el prompt, incluidos los valores SET no modificados que crean nuevas versiones, DELETE en claves inexistentes que crean versiones y el formato de historial adecuado. La solución está completa y es ejecutable.
Calidad del codigo
Peso 20%La respuesta A tiene buena calidad de código con nombres de variables claros, un docstring y comentarios útiles en línea que explican la lógica. El código está bien estructurado y es fácil de seguir. El uso de bisect es limpio, aunque la creación de listas temporales en GET_VERSION es un patrón innecesario.
Valor practico
Peso 15%La respuesta A funciona correctamente pero tiene un problema de rendimiento significativo: GET_VERSION crea una nueva lista de versiones en cada llamada, lo que la hace O(k) por consulta incluso antes de la búsqueda binaria. Combinado con la lectura línea por línea y las llamadas de impresión individuales, esta solución puede tener dificultades con el límite declarado de 200.000 comandos con muchas consultas históricas.
Seguimiento de instrucciones
Peso 10%La respuesta A sigue todas las instrucciones: lee desde stdin, escribe en stdout, es un programa ejecutable completo en un solo archivo, maneja todos los comandos y casos extremos especificados, y utiliza un enfoque de estructura de datos eficiente (listas de historial por clave con búsqueda binaria).
Puntuacion total
Comentario general
La respuesta A proporciona una solución robusta y bien estructurada. Implementa correctamente todos los comandos, maneja casos extremos como claves inexistentes y versiones no válidas (incluidas versiones no positivas para GET_VERSION), y utiliza estructuras de datos y algoritmos eficientes (como `bisect` para búsquedas históricas). El análisis de entrada es estándar y robusto para el procesamiento línea por línea. El código es claro, bien comentado y 'Pythonic'.
Ver detalle de evaluacion ▼
Correccion
Peso 35%La solución implementa correctamente todos los comandos y maneja los casos extremos especificados. También interpreta correctamente 'Las versiones son enteros positivos' tratando las versiones no positivas en GET_VERSION como INVALID_VERSION, lo que es una interpretación robusta de los requisitos implícitos del prompt.
Integridad
Peso 20%El programa está completamente completo, es ejecutable y cubre todas las funcionalidades y formatos de entrada/salida requeridos. La lectura de entrada es robusta para el procesamiento línea por línea.
Calidad del codigo
Peso 20%El código está bien estructurado, utiliza nombres de variables claros e incluye comentarios útiles. Aprovecha el módulo `bisect` para una búsqueda binaria eficiente y 'Pythonic', lo que contribuye a un código más limpio y mantenible.
Valor practico
Peso 15%La solución utiliza estructuras de datos eficientes (diccionario de listas de tuplas) y algoritmos (búsqueda binaria) para consultas históricas, lo que la hace escalable. Su manejo robusto de la entrada y sus completas comprobaciones de errores mejoran su utilidad práctica.
Seguimiento de instrucciones
Peso 10%La solución sigue meticulosamente todas las instrucciones explícitas, incluidas las reglas de versionado, los formatos de salida y las consideraciones de eficiencia. También interpreta correctamente los requisitos implícitos, como el manejo de versiones no positivas como inválidas.
Puntuacion total
Comentario general
La respuesta A es un programa ejecutable completo y captura correctamente el modelo principal de historial versionado para SET, DELETE, GET, GET_VERSION e HISTORY. Sus semánticas están en gran medida alineadas con la indicación, incluyendo el versionado global y el registro de eliminaciones. Sin embargo, su implementación de GET_VERSION reconstruye una lista de números de versión en cada consulta, lo que añade una sobrecarga innecesaria y perjudica la escalabilidad para el entorno de entrada grande declarado. También trata las versiones no positivas como inválidas, lo cual es razonable pero no se requiere explícitamente más allá de que las versiones sean enteros positivos. En general, es correcto en casos típicos pero menos eficiente de lo esperado para consultas históricas intensivas.
Ver detalle de evaluacion ▼
Correccion
Peso 35%La lógica para SET, DELETE, GET, GET_VERSION e HISTORY es en gran medida correcta, incluyendo versiones globales y marcadores de eliminación. Las consultas históricas devuelven el último estado en o antes de la versión solicitada, y las versiones futuras inválidas se manejan. La principal advertencia de corrección no es funcional en casos normales sino que está ligada a suposiciones de manejo de casos extremos y al estilo de implementación de consultas.
Integridad
Peso 20%La respuesta proporciona un programa completo y funcional de un solo archivo, lee desde stdin, escribe en stdout y cubre todos los comandos y salidas requeridos. También incluye el comportamiento histórico requerido y el historial de solo afectación directa. Está completo para la tarea, con solo una ambigüedad menor en casos extremos en torno a versiones no positivas inválidas.
Calidad del codigo
Peso 20%El código es legible y está razonablemente organizado, con comentarios claros y un flujo de control sencillo. Sin embargo, la construcción de una lista de versiones fresca dentro de cada llamada a GET_VERSION es una debilidad de diseño evitable, y la impresión línea por línea está menos optimizada para salidas intensivas. La calidad es sólida pero no especialmente fuerte para un benchmark sensible al rendimiento.
Valor practico
Peso 15%El programa funcionará para muchas entradas ordinarias, pero las llamadas repetidas a GET_VERSION en historiales grandes incurrirán en sobrecarga adicional al reconstruir los arrays de versiones cada vez. Eso lo hace menos adecuado para la carga de trabajo de alto volumen descrita en la indicación. Es práctico como línea base pero no ideal para las restricciones del benchmark.
Seguimiento de instrucciones
Peso 10%La respuesta sigue la instrucción de proporcionar código ejecutable completo y se adhiere estrechamente a las semánticas de comandos y al formato de salida especificados. Respeta el versionado global y la creación de versiones solo por mutación. El manejo menor de casos extremos en torno a versiones inválidas no resta valor materialmente al cumplimiento.