Liste la plus recente de verification des performances IA en Programmation | Orivel

Genres de comparaison

Voir tout 333 Debats 70 Écriture créative 18 Programmation 17 Conception de systèmes 17 Questions éducatives 16 Explication 15 Résumé 17 Génération d’idées 16 Jeu de rôle 15 Rédaction professionnelle 16 Planification 16 Analyse 17 Brainstorming 15 Persuasion 16 Humour 16 Empathie 18 Accompagnement 18

Liste des modeles

Voir tout GPT-5.4 (OpenAI) GPT-5.2 (OpenAI) GPT-5 mini (OpenAI) Claude Opus 4.6 (Anthropic) Claude Sonnet 4.6 (Anthropic) Claude Haiku 4.5 (Anthropic) Gemini 2.5 Pro (Google) Gemini 2.5 Flash (Google) Gemini 2.5 Flash-Lite (Google)

Programmation

Google Gemini 2.5 Pro VS OpenAI GPT-5.2

Implémenter un limiteur de débit concurrent avec fenêtre glissante et files de priorité

Concevez et implémentez un limiteur de débit (rate limiter) sûr pour les threads en Python qui prend en charge les fonctionnalités suivantes : 1. **Limitation de débit par fenêtre glissante** : Plutôt que d'utiliser des fenêtres temporelles fixes, implémentez un véritable algorithme de fenêtre glissante. Chaque client (identifié par une chaîne de caractères) est autorisé au maximum `max_requests` requêtes dans toute fenêtre glissante de `window_seconds` secondes. 2. **Niveaux de priorité** : Chaque requête a un niveau de priorité (entier 1-5, où 1 est la priorité la plus élevée). Lorsque la limite est atteinte pour un client, les requêtes de plus basse priorité (numéro plus élevé) doivent être rejetées en premier. Plus précisément, si une nouvelle requête de priorité P arrive et que la fenêtre est pleine, le limiteur doit vérifier s'il existe dans la fenêtre courante une requête ayant une priorité strictement plus basse (numéro plus élevé) que P. Si c'est le cas, le créneau de la requête la plus basse en priorité (numéro le plus élevé) est « révoqué » et la nouvelle requête de priorité supérieure est admise. La requête révoquée doit être enregistrée afin de pouvoir être rapportée. Si aucune requête de priorité inférieure n'existe pour être révoquée, la nouvelle requête est rejetée. 3. **Tolérance de rafale (burst)** : Chaque client peut optionnellement avoir une tolérance de rafale `burst` (par défaut 0). Cela permet jusqu'à `burst` requêtes supplémentaires au-delà de `max_requests` dans une fenêtre, mais uniquement si au moins la moitié de la durée de la fenêtre s'est écoulée depuis la première requête du client dans la fenêtre courante. 4. **Sécurité vis-à-vis des threads** : Le limiteur doit être sûr pour un usage concurrent depuis plusieurs threads. Démontrez cela avec un scénario de test. 5. **Statistiques** : Le limiteur doit suivre des statistiques par client : total de requêtes admises, total rejetées, total révoquées (éjectées par des requêtes de priorité supérieure), et utilisation courante de la fenêtre (en flottant de 0.0 à 1.0). Implémentez l'interface suivante : ```python class RateLimiter: def __init__(self, max_requests: int, window_seconds: float, default_burst: int = 0): ... def set_client_burst(self, client_id: str, burst: int) -> None: '''Override burst allowance for a specific client.''' ... def allow(self, client_id: str, priority: int = 3, timestamp: float = None) -> bool: ''' Vérifie si une requête est autorisée. Si timestamp est None, utiliser l'heure courante. Retourne True si la requête est admise, False si elle est rejetée. ''' ... def get_stats(self, client_id: str) -> dict: ''' Retourne un dict avec les clés : 'admitted', 'rejected', 'revoked', 'utilization' ''' ... def get_revoked_log(self, client_id: str) -> list: ''' Retourne une liste de tuples (timestamp, priority) pour les requêtes révoquées pour le client donné, dans l'ordre chronologique. ''' ... ``` Fournissez une implémentation complète et exécutable ainsi qu'un script de démonstration qui : - Crée un limiteur avec max_requests=5, window_seconds=10.0, default_burst=2 - Simule une séquence de requêtes de deux clients avec des priorités et timestamps variables qui mette en évidence toutes les fonctionnalités (expiration par fenêtre glissante, révocation par priorité, activation du burst, et rejet) - Affiche les statistiques et les journaux de révoqués pour chaque client à la fin - Inclut un bref test multithread avec au moins 4 threads effectuant des requêtes concurrentes Assurez-vous de gérer les cas limites tels que : - Validation de la valeur de priorité (doit être 1-5) - Requêtes arrivant exactement aux limites de la fenêtre - Révocations multiples en séquence - Activation de la tolérance de rafale précisément au marqueur de la moitié de la fenêtre - IDs de client vides ou inconnus dans les requêtes de statistiques

50

19 Mar 2026 14:46

Programmation

Google Gemini 2.5 Pro VS Anthropic Claude Sonnet 4.6

Implémenter un magasin clé-valeur versionné avec requêtes historiques

Écrivez du code qui implémente un magasin clé-valeur versionné en mémoire prenant en charge les lectures historiques. Le magasin commence vide et traite une séquence de commandes. Chaque commande mutative réussie crée exactement un nouveau numéro de version global, en commençant par 1. Les commandes en lecture seule ne doivent pas créer de version. Les clés et valeurs sont des chaînes sensibles à la casse sans espaces. Les versions sont des entiers positifs. Commands: SET key value Create or overwrite key with value. DELETE key Remove key if it exists. GET key Return the current value for key, or NULL if the key does not exist. GET_VERSION key version Return the value associated with key immediately after the specified global version was created, or NULL if the key did not exist at that version. If version is greater than the latest existing version, treat it as invalid and return INVALID_VERSION. HISTORY key Return all historical states for the key in increasing version order, including deletions, formatted as version:value pairs separated by commas. Use NULL for deleted or absent-after-mutation states. If the key has never been affected by any mutating command, return EMPTY. Input format: The first line contains an integer N, the number of commands. The next N lines each contain one command. Output format: For every GET, GET_VERSION, and HISTORY command, print one line with the result. Behavior details and edge cases: - Every SET always creates a new version, even if the value is unchanged. - Every DELETE always creates a new version, even if the key does not exist. - Versions are global across all keys, not per key. - HISTORY for a key should include only versions where that key was directly affected by SET or DELETE. - If a key was deleted and later set again, both events must appear in HISTORY. - Efficiency matters: assume up to 200000 commands, with many historical queries. Your solution should read from standard input and write to standard output. Include the full working program in one file. You may use any mainstream programming language, but the code should be complete and executable as written.

61

18 Mar 2026 22:33

Programmation

OpenAI GPT-5.2 VS Google Gemini 2.5 Pro

Implémenter un Cache LRU (Least Recently Used)

Implémentez une structure de données de cache LRU (Least Recently Used) en Python. Votre implémentation doit être une classe nommée `LRUCache` qui prend en charge les opérations suivantes : 1. `__init__(self, capacity: int)` — Initialise le cache avec une capacité entière positive. 2. `get(self, key: int) -> int` — Renvoie la valeur associée à la clé si elle existe dans le cache, sinon renvoie -1. L'accès à une clé compte comme une "utilisation". 3. `put(self, key: int, value: int) -> None` — Insère ou met à jour la paire clé-valeur. Si le cache dépasse sa capacité après l'insertion, évince la clé la moins récemment utilisée. Les opérations `get` et `put` doivent s'exécuter en complexité temporelle moyenne de O(1). Fournissez l'implémentation complète de la classe. Démontrez ensuite sa correction en montrant la sortie de la séquence d'opérations suivante : ``` 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 ``` Expliquez brièvement comment votre implémentation atteint une complexité temporelle de O(1) pour les deux opérations.

151

09 Mar 2026 03:54

Liens associes

Classements Liste des modeles Genres de comparaison Debats Comparaisons

Dernieres taches et discussions

Implémenter un limiteur de débit concurrent avec fenêtre glissante et files de priorité

Implémenter un magasin clé-valeur versionné avec requêtes historiques

Implémenter un Cache LRU (Least Recently Used)

Liens associes