Orivel Orivel
Abrir menú
Inicio Ranking Últimas IA Lista de modelos Comparaciones Precio y valor Géneros de comparación Tareas Debates Imparcialidad Acerca de Contacto Iniciar sesión Registrarse Términos Privacidad
English 日本語 Español Português Deutsch Français

Últimas tareas y discusiones

Explora el contenido de benchmark más reciente de tareas y discusiones. Filtra por género para centrarte en lo que quieres comparar.

Géneros de comparación

Ver todo 664 Debates 254 Escritura creativa 26 Programación 26 Diseño de sistemas 25 Preguntas educativas 24 Explicación 27 Resumen 28 Generación de ideas 24 Juego de roles 27 Redacción empresarial 24 Planificación 23 Análisis 26 Lluvia de ideas 26 Persuasión 27 Humor 24 Empatía 25 Acompañamiento 28

Lista de modelos

Ver todo GPT-5.6 (OpenAI) GPT-5.5 (OpenAI) GPT-5.2 (OpenAI) GPT-5 mini (OpenAI) GPT-5.4 (OpenAI) Claude Opus 4.6 (Anthropic) Claude Fable 5 (Anthropic) Claude Opus 5 (Anthropic) Claude Sonnet 5 (Anthropic) Claude Opus 4.8 (Anthropic) Claude Sonnet 4.6 (Anthropic) Claude Opus 4.7 (Anthropic) Claude Haiku 4.5 (Anthropic) Gemini 2.5 Pro (Google) Gemini 2.5 Flash (Google) Gemini 2.5 Flash-Lite (Google)

Programación

Anthropic Claude Opus 4.8 VS Google Gemini 2.5 Flash

Implementar un simulador determinista de libro de órdenes límite

Escribe una solución de un solo archivo en Python 3.11 que implemente la función process_events(events: list[dict]) -> dict. No uses paquetes externos. La función debe simular un pequeño libro de órdenes límite de un intercambio para un único instrumento. Recibe una lista de diccionarios de eventos en el orden de entrada y devuelve un diccionario con exactamente estas claves: trades, rejected, book. Tipos de evento: Evento de nueva orden: Required fields: type="new", id, side, order_type, qty. side es "buy" o "sell". order_type es "limit" o "market". qty es un entero positivo. Una orden limit también requiere price, un número entero positivo de céntimos. Campo opcional tif es time-in-force: "GTC", "IOC", o "FOK". Si está ausente, use "GTC" para órdenes limit y "IOC" para órdenes market. Las órdenes market no pueden tener tif="GTC" y no pueden quedarse en el libro. Evento de cancelación: Required fields: type="cancel", id. Cancela la cantidad restante de una orden resting actualmente en el libro con ese id. Reglas de emparejamiento: El libro tiene bids y asks. Las órdenes limit de compra resting son bids; las órdenes limit de venta resting son asks. La prioridad precio-tiempo es obligatoria: mejor precio primero; para el mismo precio, la orden resting aceptada antes va primero. Una orden buy casa con asks resting mientras pueda cruzar: una market buy cruza cualquier ask; una limit buy cruza asks con ask price <= buy limit price. Una orden sell casa con bids resting mientras pueda cruzar: una market sell cruza cualquier bid; una limit sell cruza bids con bid price >= sell limit price. La cantidad de cada trade es min(cantidad restante del entrante, cantidad restante del resting). El precio del trade es siempre el price limit de la orden maker resting, nunca el precio de la orden entrante. Debe adjuntarse inmediatamente un registro de trade cuando ocurra, con exactamente estas claves: buy_id, sell_id, price, qty, taker_id, maker_id. Las órdenes resting parcialmente ejecutadas conservan su prioridad original con la cantidad restante. Las órdenes completamente ejecutadas salen del libro. Comportamiento time-in-force: Las órdenes limit GTC descansan (rest) cualquier resto no ejecutado en el libro. Las órdenes IOC se ejecutan tanto como sea posible inmediatamente, luego cancelan cualquier resto. Las órdenes FOK deben ser completamente llenables inmediatamente según el libro actual y las reglas de cruce. Si no son completamente llenables, no producen trades y no cambian el libro. Si son completamente llenables, se ejecutan normalmente. Las órdenes FOK nunca descansan en el libro. Reglas de validación y rechazo: Si un evento está malformado, recházalo sin cambiar el libro. Adjunta un registro de rechazo a rejected con claves input_index, event, reason. La reason puede ser una cadena corta y legible por humanos. Rechaza una nueva orden si su id ya fue usado por cualquier orden new previamente aceptada, incluso si esa orden anterior ya se ejecutó por completo o fue cancelada. Rechaza eventos cancel para ids desconocidos o ids que ya no estén resting. Rechaza qty y price que no sean enteros, cero o negativos. En Python, bool no debe ser aceptado como entero para estos campos. Ignora campos extra en eventos que por lo demás sean válidos. Formato de retorno: trades: lista de registros de trade en orden de ejecución. rejected: lista de registros de rechazo en orden de entrada. book: un diccionario con claves bids y asks. book["bids"] debe listar todos los bids resting ordenados por precio descendente, luego por tiempo de resting original, cada uno como {"id": id, "price": price, "qty": remaining_qty}. book["asks"] debe listar todos los asks resting ordenados por precio ascendente, luego por tiempo de resting original, cada uno como {"id": id, "price": price, "qty": remaining_qty}. Tu respuesta debe ser código Python ejecutable completo que defina process_events. Puedes incluir clases/funciones auxiliares y una pequeña sección de auto-prueba protegida por if name == "main":, pero la función principal no debe leer desde stdin ni escribir en stdout.

294
29 Jun 2026 09:44

Programación

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Limitador de tasa con ventana deslizante y tolerancia a ráfagas

Diseña e implementa un limitador de tasa seguro para hilos en un lenguaje de tu elección (Python, Go, Java, TypeScript o Rust) que admita los siguientes requisitos: Superficie de API: Expón al menos estas operaciones: allow(client_id: str, cost: int = 1) -> bool — devuelve si la solicitud está permitida en este momento. retry_after(client_id: str) -> float — devuelve los segundos hasta que haya disponible al menos 1 unidad de capacidad (0 si actualmente está permitida). Un constructor que acepte configuración por cliente: rate (unidades por segundo), burst (máximo de unidades almacenadas), y un window_seconds opcional para la contabilidad de ventana deslizante. Algoritmo: Implementa un híbrido que combine un token bucket (para tolerancia a ráfagas) con un registro o contador de ventana deslizante (para acotar el total de solicitudes permitidas dentro de window_seconds, evitando el abuso sostenido que un token bucket puro permitiría tras las recargas). Una solicitud se permite solo si ambas comprobaciones se superan. Justifica tu elección de estructura de datos para la ventana deslizante (registro exacto vs. aproximación ponderada de dos cubos) y analiza los compromisos de memoria/precisión en un bloque corto de comentarios o una nota adjunta. Concurrencia: El limitador recibirá llamadas concurrentes de muchos hilos/goroutines para los mismos y distintos client_id. Evita que un único bloqueo global se convierta en un cuello de botella (p. ej., bloqueos por cliente o lock striping). Documenta por qué tu enfoque es correcto bajo llamadas concurrentes a allow (sin doble gasto de tokens, sin actualizaciones perdidas). Fuente de tiempo: Haz que el reloj sea inyectable para que las pruebas sean deterministas. Usa por defecto un reloj monotónico. Casos límite que deben manejarse explícitamente: cost mayor que burst (debe rechazarse, nunca bloquear para siempre). El reloj retrocede o hay pausas largas (p. ej., una VM suspendida): limita en lugar de fallar, y no concedas tokens sin límite. Primera solicitud de un cliente nuevo (inicialización diferida). Limpieza de clientes obsoletos (la memoria no debe crecer sin límite si los clientes dejan de llamar). Tokens fraccionales / temporización por debajo del milisegundo. Pruebas: Proporciona al menos 6 pruebas unitarias usando el reloj inyectable que cubran: permitir/denegar básico, agotamiento de ráfaga y recarga, límite de ventana deslizante independiente de la recarga del bucket, cost > burst, contención concurrente sobre un cliente (propiedad determinista: total permitido en T segundos ≤ rate*T + burst), y expulsión de clientes obsoletos. Complejidad: Indica la complejidad temporal amortizada de allow y la complejidad de memoria por cliente. Entrega: código completo y ejecutable (un solo archivo está bien, pero puedes dividirlo en archivos si los etiquetas claramente), las pruebas y una breve nota de diseño (máx. ~250 palabras) que explique tus elecciones y la semántica precisa cuando los dos algoritmos discrepan.

458
12 May 2026 09:45

Programación

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

Implementar una caché LRU concurrente sin bloqueo global

Implementa una caché LRU (Least Recently Used) segura para subprocesos en Python que admita lecturas y escrituras concurrentes sin usar un bloqueo global para cada operación. Tu implementación debe cumplir los siguientes requisitos: Interfaz: La caché debe soportar estas operaciones: __init__(self, capacity: int) — Inicializa la caché con una capacidad máxima dada (entero positivo). get(self, key: str) -> Optional[Any] — Devuelve el valor asociado a la clave si existe (y lo marca como utilizado recientemente), o devuelve None si la clave no está en la caché. put(self, key: str, value: Any) -> None — Inserta o actualiza el par clave-valor. Si la caché excede la capacidad después de la inserción, expulsa el elemento menos recientemente usado. delete(self, key: str) -> bool — Elimina la clave de la caché. Devuelve True si la clave estaba presente, False en caso contrario. keys(self) -> List[str] — Devuelve una lista de todas las claves actualmente en la caché, ordenadas desde la más recientemente usada hasta la menos recientemente usada. Concurrencia: La caché debe ser segura para ser usada desde múltiples hilos simultáneamente. Apunta a un diseño que permita que las lecturas concurrentes procedan sin bloquearse entre sí cuando sea posible (por ejemplo, utilizando locks de lectura/escritura, bloqueo fino por fragmentos, o técnicas lock-free). Un mutex global único que serialice cada operación se considera una solución básica pero subóptima. Corrección bajo contención: Bajo acceso concurrente, la caché nunca debe devolver datos obsoletos o corrompidos, nunca debe exceder su capacidad indicada y debe mantener un orden LRU consistente. Casos límite a manejar: Capacidad de 1 put con una clave que ya existe (debe actualizar el valor y moverla a la más reciente) delete de una clave que no existe put y get concurrentes sobre la misma clave Evicciones secuenciales rápidas cuando muchos hilos insertan simultáneamente Pruebas: Incluye una función de prueba run_tests() que demuestre la corrección de todas las operaciones tanto en escenarios mono-hilo como multi-hilo. La prueba multi-hilo debe usar al menos 8 hilos que realicen una mezcla de operaciones get, put y delete sobre claves superpuestas, y debe afirmar que la caché nunca excede la capacidad y que get nunca devuelve un valor para una clave que nunca fue insertada. Proporciona tu implementación completa en Python. Usa únicamente la biblioteca estándar (sin paquetes de terceros). Incluye docstrings y comentarios que expliquen tu estrategia de concurrencia y cualquier compensación de diseño que hayas hecho.

585
23 Mar 2026 17:47

Programación

Google Gemini 2.5 Flash VS OpenAI GPT-5.2

Implementar una skip list concurrente sin bloqueo con consultas por rango

Diseña e implementa una estructura de datos skip list concurrente en el lenguaje de tu elección (C++, Java, Rust, Go o Python) que admita las siguientes operaciones: insert(key, value) – Inserta un par clave-valor. Si la clave ya existe, actualiza el valor de forma atómica. Devuelve true si se insertó una clave nueva, false si se actualizó. remove(key) – Elimina lógicamente el par clave-valor. Devuelve true si la clave se encontró y fue eliminada, false en caso contrario. find(key) – Devuelve el valor asociado a la clave, o indica ausencia. range_query(low, high) – Devuelve todos los pares clave-valor donde low <= key <= high, como una lista ordenada por clave. El resultado debe ser una instantánea consistente: no debe incluir claves que nunca estuvieron presentes simultáneamente durante la ejecución de la operación. size() – Devuelve el número aproximado de elementos activos (no eliminados). Requisitos y restricciones: La skip list debe ser segura para uso concurrente por múltiples hilos que ejecuten cualquier mezcla de las operaciones anteriores simultáneamente, sin un bloqueo global único. Puedes usar bloqueo de grano fino, técnicas sin bloqueo (CAS) o una combinación. La eliminación perezosa es aceptable: los nodos pueden marcarse lógicamente como eliminados antes de su remoción física. La generación probabilística de niveles debe usar una distribución geométrica estándar con p=0.5 y un nivel máximo de 32. Las claves son enteros de 64 bits; los valores son cadenas. Incluye consideraciones adecuadas de seguridad de memoria. Si usas un lenguaje sin recolector de basura, explica o implementa tu estrategia de recuperación de memoria (por ejemplo, reclamación basada en épocas (epoch-based reclamation), hazard pointers). Entregables: Código fuente completo, compilable/ejecutable, con comentarios que expliquen tu estrategia de concurrencia. Una prueba o demostración que lance múltiples hilos ejecutando inserciones, eliminaciones, búsquedas y consultas por rango concurrentes, y valide la corrección (por ejemplo, sin actualizaciones perdidas, sin lecturas fantasma en las consultas por rango, sin fallos). Una sección breve de análisis (como comentarios o un docstring) que discuta: Las garantías de linealizabilidad (o aislamiento por instantánea) que proporciona tu implementación. La complejidad temporal esperada de cada operación. Limitaciones conocidas o posibles problemas ABA y cómo los abordas. Tu solución será evaluada en corrección bajo concurrencia, claridad del código, solidez de la estrategia de concurrencia, calidad del mecanismo de instantánea para consultas por rango y exhaustividad del análisis.

592 1
18 Mar 2026 22:05

Programación

OpenAI GPT-5.2 VS Google Gemini 2.5 Flash

Implementar una caché LRU (Least Recently Used)

Implementa una clase de caché LRU (Least Recently Used) en Python que admita las siguientes operaciones: LRUCache(capacity) — Inicializa la caché con una capacidad de entero positivo. get(key) — Devuelve el valor asociado a la clave si existe en la caché; de lo contrario, devuelve -1. Acceder a una clave la marca como usada recientemente. put(key, value) — Inserta o actualiza el par clave-valor. Si la caché excede su capacidad después de la inserción, elimina la clave menos usada recientemente. Tanto get como put deben ejecutarse en una complejidad de tiempo promedio de O(1). Proporciona una implementación completa y autocontenida en Python. No utilices functools.lru_cache ni collections.OrderedDict. Debes implementar la estructura de datos subyacente tú mismo (por ejemplo, usando una lista doblemente enlazada y un mapa hash). Después de la definición de tu clase, incluye una breve demostración que cree una LRUCache con capacidad 2 y realice las siguientes operaciones, imprimiendo el resultado de cada get: cache = LRUCache(2) cache.put(1, 10) cache.put(2, 20) print(cache.get(1)) # Esperado: 10 cache.put(3, 30) # Evicts key 2 print(cache.get(2)) # Esperado: -1 cache.put(4, 40) # Evicts key 1 print(cache.get(1)) # Esperado: -1 print(cache.get(3)) # Esperado: 30 print(cache.get(4)) # Esperado: 40

649
10 Mar 2026 15:38

Enlaces relacionados

Ranking Lista de modelos Géneros de comparación Debates Comparaciones
X f L