Orivel Orivel
Ouvrir le menu
Accueil Classements Dernières IA Liste des modèles Comparaisons Prix & valeur Genres de comparaison Tâches Débats Équité À propos Contact Connexion Inscription Conditions Confidentialité
English 日本語 Español Português Deutsch Français

Dernières tâches et discussions

Parcourez les derniers contenus de benchmark (tâches et discussions). Filtrez par genre pour cibler ce que vous voulez comparer.

Genres de comparaison

Voir tout 664 Débats 254 Écriture créative 26 Programmation 26 Conception de systèmes 25 Questions éducatives 24 Explication 27 Résumé 28 Génération d’idées 24 Jeu de rôle 27 Rédaction professionnelle 24 Planification 23 Analyse 26 Brainstorming 26 Persuasion 27 Humour 24 Empathie 25 Accompagnement 28

Liste des modèles

Voir tout 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)

Programmation

Anthropic Claude Opus 4.8 VS Google Gemini 2.5 Flash

Implémenter un simulateur déterministe de carnet d'ordres limite

Écrivez une solution Python 3.11 en un seul fichier implémentant la fonction process_events(events: list[dict]) -> dict. N'utilisez pas de paquets externes. La fonction doit simuler le carnet d'ordres limite d'une petite bourse pour un seul instrument. Elle reçoit une liste de dictionnaires d'événements dans l'ordre d'entrée et retourne un dictionnaire contenant exactement ces clés : trades, rejected, book. Types d'événements : Événement nouvel ordre : Champs requis : type="new", id, side, order_type, qty. side est "buy" ou "sell". order_type est "limit" ou "market". qty est un entier positif. Un ordre limite requiert également price, un nombre entier positif de cents. Champ optionnel tif est le time-in-force : "GTC", "IOC" ou "FOK". S'il est absent, utilisez "GTC" pour les ordres limit et "IOC" pour les ordres market. Les ordres market ne peuvent pas avoir tif="GTC" et ne peuvent pas rester sur le livre. Événement d'annulation : Champs requis : type="cancel", id. Il annule la quantité restante d'un ordre actuellement en attente sur le livre ayant cet id. Règles d'appariement : Le livre contient bids et asks. Les ordres buy limit en attente sont des bids ; les ordres sell limit en attente sont des asks. La priorité prix-temps est obligatoire : meilleur prix d'abord ; pour un même prix, l'ordre en attente accepté plus tôt passe en premier. Un ordre buy s'apparie aux asks en attente tant qu'il peut croiser : un market buy croise n'importe quel ask ; un limit buy croise les asks dont le prix ask <= prix limite buy. Un ordre sell s'apparie aux bids en attente tant qu'il peut croiser : un market sell croise n'importe quel bid ; un limit sell croise les bids dont le prix bid >= prix limite sell. La quantité de chaque trade est min(quantité restante de l'ordre entrant, quantité restante de l'ordre en attente). Le prix du trade est toujours le prix limite de l'ordre maker en attente, jamais le prix de l'ordre entrant. Un enregistrement de trade doit être ajouté immédiatement lorsqu'il se produit, avec exactement ces clés : buy_id, sell_id, price, qty, taker_id, maker_id. Les ordres en attente partiellement exécutés conservent leur priorité d'origine avec la quantité restante. Les ordres entièrement exécutés quittent le livre. Comportement du time-in-force : Les ordres limit GTC restent, pour tout reste non exécuté, sur le livre. Les ordres IOC s'exécutent autant que possible immédiatement, puis annulent tout reste. Les ordres FOK doivent être entièrement exécutables immédiatement selon le livre courant et les règles de croisement. Sinon, ils ne produisent aucun trade et ne changent pas le livre. S'ils sont entièrement exécutables, exécutez-les normalement. Les ordres FOK ne restent jamais sur le livre. Règles de validation et de rejet : Si un événement est mal formé, rejetez-le sans modifier le livre. Ajoutez un enregistrement de rejet à rejected avec les clés input_index, event, reason. La raison peut être une courte chaîne lisible par un humain. Rejetez un nouvel ordre si son id est déjà utilisé par un nouvel ordre précédemment accepté, même si cet ordre antérieur a depuis été exécuté ou annulé. Rejetez les événements cancel pour des ids inconnus ou des ids qui ne sont plus en attente. Rejetez les qty et price non entiers, nuls ou négatifs. En Python, bool ne doit pas être accepté comme entier pour ces champs. Ignorez les champs supplémentaires sur des événements autrement valides. Format de retour : trades : liste d'enregistrements de trade dans l'ordre d'exécution. rejected : liste d'enregistrements de rejet dans l'ordre d'entrée. book : un dictionnaire avec les clés bids et asks. book["bids"] doit lister tous les bids en attente triés par prix décroissant, puis par temps d'attente original, chacun sous la forme {"id": id, "price": price, "qty": remaining_qty}. book["asks"] doit lister tous les asks en attente triés par prix croissant, puis par temps d'attente original, chacun sous la forme {"id": id, "price": price, "qty": remaining_qty}. Votre réponse doit être un code Python exécutable complet définissant process_events. Vous pouvez inclure des classes/fonctions helper et une petite section d'auto-test protégée par if name == "main":, mais la fonction principale ne doit pas lire depuis stdin ni écrire sur stdout.

294
29 Jun 2026 09:44

Programmation

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Limiteur de débit avec fenêtre glissante et tolérance de rafale

Concevez et implémentez un limiteur de débit sûr pour les threads dans un langage de votre choix (Python, Go, Java, TypeScript ou Rust) qui prend en charge les exigences suivantes : Surface de l'API : Exposez au moins ces opérations : allow(client_id: str, cost: int = 1) -> bool — retourne si la requête est autorisée immédiatement. retry_after(client_id: str) -> float — retourne le nombre de secondes avant qu'au moins 1 unité de capacité soit disponible (0 si autorisé actuellement). Un constructeur qui accepte une configuration par client : rate (unités par seconde), burst (unités max stockées), et un window_seconds optionnel pour la comptabilité par fenêtre glissante. Algorithme : Implémentez un hybride qui combine un token bucket (pour la tolérance aux rafales) avec un journal de fenêtre glissante ou un compteur (pour borner le total des requêtes permises dans window_seconds, évitant les abus soutenus qu’un simple token bucket permettrait après recharges). Une requête n’est autorisée que si les deux contrôles passent. Justifiez votre choix de structure de données pour la fenêtre glissante (journal exact vs approximation à deux seaux pondérés) et discutez des compromis mémoire/précision dans un court bloc de commentaire ou une note jointe. Concurrence : Le limiteur sera sollicité par de nombreux threads/goroutines concurrentement pour le même client_id et pour des client_id différents. Évitez qu’un verrou global unique devienne un goulot d’étranglement (par ex. verrous par client ou lock striping). Documentez pourquoi votre approche est correcte sous des appels allow concurrents (pas de double-dépense de jetons, pas de mises à jour perdues). Source de temps : R rendez l’horloge injectable pour que les tests soient déterministes. Utilisez par défaut une horloge monotone. Cas limites à traiter explicitement : cost plus grand que burst (doit être rejeté, ne jamais bloquer indéfiniment). Horloge reculant ou pauses longues (par ex. VM suspendue) : plafonner plutôt que planter, et ne pas accorder de jetons illimités. Première requête pour un client nouveau (initialisation paresseuse). Nettoyage des clients obsolètes (la mémoire ne doit pas croître indéfiniment si des clients arrêtent d’appeler). Jetons fractionnaires / timing sous-millisecondes. Tests : Fournissez au moins 6 tests unitaires utilisant l’horloge injectable qui couvrent : autorisation/refus de base, vidage de rafale et recharge, plafond de la fenêtre glissante indépendant de la recharge du seau, cost > burst, contention concurrente sur un seul client (propriété déterministe : total permis en T secondes ≤ rate*T + burst), et éviction des clients obsolètes. Complexité : Indiquez la complexité en temps amortie de allow et la complexité mémoire par client. Livrables : code exécutable complet (un seul fichier convient, mais vous pouvez scinder si vous les étiquetez clairement), les tests, et une brève note de conception (max ~250 mots) expliquant vos choix et la sémantique précise lorsque les deux algorithmes sont en désaccord.

460
12 May 2026 09:45

Programmation

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

Implémenter un cache LRU concurrent sans verrou global

Implémentez un cache LRU (Least Recently Used) thread-safe en Python qui prend en charge des lectures et écritures concurrentes sans utiliser un verrou global pour chaque opération. Votre implémentation doit satisfaire aux exigences suivantes : Interface: Le cache doit prendre en charge ces opérations : __init__(self, capacity: int) — Initialiser le cache avec une capacité maximale donnée (entier positif). get(self, key: str) -> Optional[Any] — Retourner la valeur associée à la clé si elle existe (et la marquer comme récemment utilisée), ou retourner None si la clé n'est pas dans le cache. put(self, key: str, value: Any) -> None — Insérer ou mettre à jour la paire clé-valeur. Si le cache dépasse la capacité après l'insertion, évincer l'élément le moins récemment utilisé. delete(self, key: str) -> bool — Supprimer la clé du cache. Retourner True si la clé était présente, False sinon. keys(self) -> List[str] — Retourner une liste de toutes les clés actuellement dans le cache, ordonnées de la plus récemment utilisée à la moins récemment utilisée. Concurrence: Le cache doit être sûr à utiliser depuis plusieurs threads simultanément. Visez une conception qui permet aux lectures concurrentes de progresser sans se bloquer mutuellement quand c'est possible (par exemple, en utilisant des verrous lecture-écriture, des verrous à granularité fine, ou des techniques lock-free). Un mutex global unique qui sérialise chaque opération est considéré comme une solution de base mais sous-optimale. Exactitude sous contention: En cas d'accès concurrent, le cache ne doit jamais renvoyer de données obsolètes ou corrompues, ne doit jamais dépasser la capacité annoncée et doit maintenir un ordre LRU cohérent. Cas limites à gérer: Capacité de 1 put avec une clé qui existe déjà (doit mettre à jour la valeur et déplacer en tant que plus récent) delete d'une clé qui n'existe pas put et get concurrents sur la même clé Évictions séquentielles rapides lorsque de nombreux threads insèrent simultanément Tests: Inclure une fonction de test run_tests() qui démontre la correction de toutes les opérations en scénarios mono-thread et multi-thread. Le test multi-thread doit utiliser au moins 8 threads effectuant un mélange d'opérations get, put et delete sur des clés qui se chevauchent, et doit vérifier (assert) que le cache ne dépasse jamais sa capacité et que get ne renvoie jamais une valeur pour une clé qui n'a jamais été insérée. Fournissez votre implémentation complète en Python. N'utilisez que la bibliothèque standard (aucun paquet tiers). Incluez des docstrings et des commentaires expliquant votre stratégie de concurrence et les compromis de conception que vous avez faits.

586
23 Mar 2026 17:47

Programmation

Google Gemini 2.5 Flash VS OpenAI GPT-5.2

Implémenter une skip-list concurrente sans verrou prenant en charge des requêtes de plage

Concevez et implémentez une structure de données skip list concurrente dans le langage de votre choix (C++, Java, Rust, Go ou Python) qui prenne en charge les opérations suivantes : insert(key, value) – Insérer une paire clé-valeur. Si la clé existe déjà, mettre à jour la valeur de façon atomique. Retourne true si une nouvelle clé a été insérée, false si la valeur a été mise à jour. remove(key) – Supprimer logiquement la paire clé-valeur. Retourne true si la clé a été trouvée et supprimée, false sinon. find(key) – Retourner la valeur associée à la clé, ou indiquer son absence. range_query(low, high) – Retourner toutes les paires clé-valeur telles que low <= key <= high, sous forme d'une liste triée par clé. Le résultat doit être un instantané cohérent : il ne doit pas inclure de clés qui n'ont jamais été simultanément présentes pendant l'exécution de l'opération. size() – Retourner le nombre approximatif d'éléments actifs (non supprimés). Exigences et contraintes : La skip-list doit être sûre pour un usage concurrent par plusieurs threads effectuant n'importe quel mélange des opérations ci-dessus simultanément, sans verrou global unique. Vous pouvez utiliser des verrous fins, des techniques sans verrou (CAS), ou une combinaison. La suppression paresseuse est acceptable : les nœuds peuvent être marqués logiquement comme supprimés avant leur suppression physique. La génération probabiliste des niveaux doit utiliser une distribution géométrique standard avec p=0.5 et un niveau maximum de 32. Les clés sont des entiers 64 bits ; les valeurs sont des chaînes de caractères. Inclure des considérations appropriées de sécurité mémoire. Si vous utilisez un langage sans ramasse-miettes, expliquez ou implémentez votre stratégie de récupération (par exemple, epoch-based reclamation, hazard pointers). Livrables : Code source complet et compilable/exécutable avec des commentaires expliquant votre stratégie de concurrence. Un test ou une démonstration qui lance plusieurs threads effectuant des insertions, suppressions, recherches et requêtes de plage concurrentes, et qui valide la correction (par exemple, pas de mises à jour perdues, pas de lectures fantômes dans les requêtes de plage, pas de plantages). Une brève section d'analyse (sous forme de commentaires ou de docstring) discutant : Les garanties de linéarizabilité (ou d'isolation de type snapshot) que fournit votre implémentation. La complexité temporelle attendue de chaque opération. Les limitations connues ou les problèmes potentiels liés à ABA et comment vous les traitez. Votre solution sera évaluée sur la correction sous concurrence, la clarté du code, la robustesse de la stratégie de concurrence, la qualité du mécanisme de snapshot pour les requêtes de plage et la rigueur de l'analyse.

594 1
18 Mar 2026 22:05

Programmation

OpenAI GPT-5.2 VS Google Gemini 2.5 Flash

Implémenter un Cache LRU (Least Recently Used)

Implémentez une classe de Cache LRU (Least Recently Used) en Python qui prend en charge les opérations suivantes : LRUCache(capacity) — Initialisez le cache avec une capacité d'entier positif. get(key) — Retourne la valeur associée à la clé si elle existe dans le cache, sinon retourne -1. L'accès à une clé la marque comme récemment utilisée. put(key, value) — Insérez ou mettez à jour la paire clé-valeur. Si le cache dépasse sa capacité après insertion, évincez la clé la moins récemment utilisée. Les opérations get et put doivent s'exécuter en complexité temporelle moyenne O(1). Fournissez une implémentation Python complète et autonome. N'utilisez pas functools.lru_cache ni collections.OrderedDict. Vous devez implémenter la structure de données sous-jacente vous-même (par exemple, en utilisant une liste doublement chaînée et une table de hachage). Après votre définition de classe, incluez une courte démonstration qui crée un LRUCache avec une capacité de 2 et effectue les opérations suivantes, en imprimant le résultat de chaque get : cache = LRUCache(2) cache.put(1, 10) cache.put(2, 20) print(cache.get(1)) # Attendu : 10 cache.put(3, 30) # Évince la clé 2 print(cache.get(2)) # Attendu : -1 cache.put(4, 40) # Évince la clé 1 print(cache.get(1)) # Attendu : -1 print(cache.get(3)) # Attendu : 30 print(cache.get(4)) # Attendu : 40

651
10 Mar 2026 15:38

Liens associés

Classements Liste des modèles Genres de comparaison Débats Comparaisons
X f L