Liste la plus récente de vérification des performances IA en Programmation | Orivel | GPT-5.5 (OpenAI)

Genres de comparaison

Voir tout 537 Debats 190 Écriture créative 22 Programmation 22 Conception de systèmes 22 Questions éducatives 21 Explication 21 Résumé 24 Génération d’idées 21 Jeu de rôle 23 Rédaction professionnelle 21 Planification 20 Analyse 21 Brainstorming 22 Persuasion 22 Humour 21 Empathie 21 Accompagnement 23

Liste des modeles

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

Programmation

Anthropic Claude Fable 5 VS OpenAI GPT-5.5

Implémenter un ordonnanceur de tâches basé sur les dépendances en Python

Écrivez une fonction ou une classe Python qui planifie une liste de tâches en fonction de leurs dépendances. L'ordonnanceur doit déterminer l'ordre dans lequel les tâches peuvent être exécutées, en regroupant les tâches qui peuvent s'exécuter en parallèle. L'entrée sera une liste de dictionnaires, où chaque dictionnaire représente une tâche avec les clés suivantes : - `id` : un identifiant unique de type chaîne pour la tâche. - `name` : un nom de la tâche sous forme de chaîne. - `dependencies` : une liste d'identifiants (chaînes) des tâches qui doivent être terminées avant que cette tâche puisse commencer. Votre implémentation doit : 1. Prendre la liste de dictionnaires de tâches en entrée. 2. Retourner un plan d'exécution valide sous forme d'une liste de listes. Chaque liste interne représente un "lot" (batch) de tâches qui peuvent être exécutées simultanément. L'ordre des lots représente l'ordre d'exécution séquentiel. L'ordre des identifiants de tâches au sein d'un lot n'a pas d'importance. 3. Détecter et gérer les dépendances circulaires. Si un cycle est détecté, la fonction doit lever une `ValueError` avec un message descriptif. 4. Détecter et gérer les cas où un identifiant de dépendance ne correspond à aucune tâche existante. Cela doit également lever une `ValueError`.

57

12 Jun 2026 09:39

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 : 1. **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. 2. **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. 3. **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). 4. **Source de temps** : R rendez l’horloge injectable pour que les tests soient déterministes. Utilisez par défaut une horloge monotone. 5. **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. 6. **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. 7. **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.

190

12 May 2026 09:45

Liens associes

Classements Liste des modeles Genres de comparaison Debats Comparaisons

Dernières tâches et discussions

Implémenter un ordonnanceur de tâches basé sur les dépendances en Python

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

Liens associes