$course$/QCM de NSI/Terminale/Diviser pour régner Paradigme diviser pour régner (étapes diviser, régner, combiner),
recherche dichotomique, tri fusion et tri rapide, exponentiation
rapide, complexité par récurrence et théorème maître.

]]> Diviser pour régner — Q01 : Étapes du paradigme diviser pour régner Quelles sont les trois étapes du paradigme diviser pour
régner ?

]]> Le paradigme repose sur l'idée que résoudre un sous-problème
plus petit est plus simple, et que combiner les solutions
partielles donne efficacement la solution complète. C'est
l'idée mère de la recherche dichotomique, du tri fusion, de
l'exponentiation rapide, etc.

]]> 1.0 0.0 0 true true abc Initialiser, itérer, terminer

]]> Erreur : ces étapes décrivent une boucle, pas le paradigme
diviser pour régner qui est typiquement récursif.

]]> Diviser, régner, combiner

]]> Bonne réponse : on divise le problème en sous-problèmes
plus petits, on les résout (récursivement), puis on
combine les solutions partielles pour obtenir la solution
du problème initial.

]]> Trier, fusionner, comparer

]]> Erreur : ces opérations apparaissent dans le tri fusion
(un cas particulier), mais ne sont pas les trois étapes
générales du paradigme.

]]> Identifier, calculer, vérifier

]]> Erreur : ces verbes décrivent une démarche scientifique
générale, pas la stratégie diviser pour régner.

]]> Diviser pour régner — Q02 : Complexité de la recherche dichotomique Quelle est la complexité au pire de la recherche dichotomique
sur un tableau trié de $n$ éléments ?

]]> Pour $n = 10^9$, la dichotomie effectue au plus $30$
comparaisons. C'est l'un des gains algorithmiques les plus
spectaculaires : passer de linéaire à logarithmique.

]]> 1.0 0.0 0 true true abc $O(\log n)$

]]> Bonne réponse : à chaque étape, l'intervalle de recherche
est divisé par deux. Le nombre d'étapes est donc le
logarithme en base $2$ de $n$.

]]> $O(n \log n)$

]]> Erreur : c'est la complexité du tri fusion, pas d'une
recherche.

]]> $O(n)$

]]> Erreur : c'est la complexité de la recherche linéaire.
La dichotomie est plus rapide grâce au tri préalable.

]]> $O(1)$

]]> Erreur : ce serait une recherche en temps constant, ce
qui n'est pas réaliste pour rechercher un élément dans
un tableau de taille variable.

]]> Diviser pour régner — Q03 : Principe du tri fusion Quel est le principe du tri fusion ?

]]> Le tri fusion est l'archétype du tri par diviser pour régner.
Sa complexité $O(n \log n)$ ne dépend pas de l'ordre initial,
ce qui en fait un tri à comportement prévisible.

]]> 1.0 0.0 0 true true abc Chercher le plus petit élément, le placer en début, recommencer

]]> Erreur : c'est le principe du tri par sélection.

]]> Couper le tableau en deux moitiés, trier chaque moitié récursivement, puis fusionner les deux moitiés triées

]]> Bonne réponse : c'est l'application directe du paradigme
diviser pour régner. La fusion de deux tableaux triés
se fait en temps linéaire en parcourant les deux
simultanément.

]]> Insérer chaque élément à sa place dans la portion déjà triée

]]> Erreur : c'est le principe du tri par insertion.

]]> Comparer chaque paire d'éléments adjacents et les permuter si nécessaire

]]> Erreur : c'est le principe du tri à bulles, en $O(n^2)$.

]]> Diviser pour régner — Q04 : Complexité du tri fusion Quelle est la complexité du tri fusion sur un tableau de $n$
éléments ?

]]> Le tri fusion est stable (préserve l'ordre des éléments
égaux) et a une complexité garantie $O(n \log n)$ dans
tous les cas, ce qui le rend prédictible. Son inconvénient
principal : il n'est pas en place.

]]> 1.0 0.0 0 true true abc $O(n \log n)$

]]> Bonne réponse : il y a $\log n$ niveaux de récursion (on
divise par deux à chaque niveau). À chaque niveau, on
parcourt l'ensemble des $n$ éléments lors des fusions.
Total : $n \log n$.

]]> $O(n^2)$

]]> Erreur : c'est la complexité des tris naïfs (sélection,
insertion, bulles). Le tri fusion est meilleur grâce au
paradigme DPR.

]]> $O(2^n)$

]]> Erreur : aucun tri usuel n'est exponentiel.

]]> $O(n)$

]]> Erreur : la fusion seule est en $O(n)$, mais on la
répète sur $\log n$ niveaux de récursion, ce qui donne
$O(n \log n)$ au total.

]]> Diviser pour régner — Q05 : Cas de base du tri fusion Quel est le cas de base du tri fusion ?

]]> Choisir un cas de base à $0$ ou $1$ élément simplifie le
code : on n'a même pas besoin de gérer la division pour ces
cas. Cela rend la fonction parfaitement récursive.

]]> 1.0 0.0 0 true true abc Un tableau de deux éléments

]]> Erreur : un tableau de deux éléments peut être mal
trié. Il faut soit le diviser à nouveau, soit le trier
directement (cas particulier optimisé).

]]> Un tableau trié

]]> Erreur : on ne sait pas a priori si le tableau est trié
(sans le parcourir). Le cas de base du tri fusion est
basé sur la taille, pas sur l'ordre.

]]> Un tableau de longueur paire

]]> Erreur : la parité ne garantit pas qu'un tableau soit
trié. Le tri fusion fonctionne pour toute parité.

]]> Un tableau de zéro ou un élément

]]> Bonne réponse : un tableau vide ou de longueur $1$ est
déjà trié par définition. La récursion s'arrête à ce
niveau, sans nouvelle découpe ni fusion.

]]> Diviser pour régner — Q06 : Principe de l'exponentiation rapide L'exponentiation rapide calcule $a^n$ en exploitant
quelle propriété mathématique ?

]]> Pour calculer $a^{20}$ : la méthode naïve fait $19$
multiplications, l'exponentiation rapide en fait environ
$\log_2(20) \approx 5$. Le gain devient énorme pour de
grands exposants (cryptographie, arithmétique modulaire).

]]> 1.0 0.0 0 true true abc $a^n = a^{n-1} \cdot a$

]]> Erreur : c'est la définition récursive naïve de la
puissance, en $O(n)$. L'exponentiation rapide va beaucoup
plus vite.

]]> $a^n = a + a + \cdots + a$ ($n$ fois)

]]> Erreur : c'est la définition de la multiplication, pas
de la puissance. L'exponentiation rapide ne peut pas
partir d'une somme.

]]> $a^n = (a^{n/2})^2$ si $n$ est pair, et $a^n = a \cdot (a^{(n-1)/2})^2$ si $n$ est impair

]]> Bonne réponse : on divise l'exposant par deux à chaque
étape (au lieu de soustraire $1$). Cela amène la
complexité de $O(n)$ à $O(\log n)$.

]]> $a^n = n \cdot a$

]]> Erreur : c'est la définition de $n \cdot a$, pas de $a^n$.
Confusion entre puissance et produit.

]]> Diviser pour régner — Q07 : Tri fusion en place ? Le tri fusion est-il un tri en place ?

]]> Tris en place : par sélection, par insertion, à bulles, tri
rapide. Tri non en place : tri fusion (mémoire
$O(n)$). Pour de grandes données, cet inconvénient peut
faire préférer le tri rapide.

]]> 1.0 0.0 0 true true abc Oui, il modifie le tableau d'origine sans mémoire supplémentaire

]]> Erreur : le tri fusion utilise des tableaux auxiliaires
(les moitiés gauche et droite, puis le résultat fusionné).
Sa mémoire supplémentaire est en $O(n)$.

]]> Non, il utilise une mémoire supplémentaire proportionnelle à $n$

]]> Bonne réponse : à chaque niveau de récursion, on crée des
tableaux pour les moitiés et la fusion. C'est l'un des
inconvénients du tri fusion, contrairement au tri rapide
ou au tri par insertion.

]]> Oui, mais seulement pour des listes de taille paire

]]> Erreur : la parité n'a aucune influence sur le caractère
en place ou non.

]]> Non, mais il utilise une mémoire constante

]]> Erreur : la mémoire supplémentaire n'est pas constante,
elle est proportionnelle à la taille du tableau.

]]> Diviser pour régner — Q08 : Pré-requis de la recherche dichotomique Quelle est la condition indispensable pour appliquer la
recherche dichotomique ?

]]> Si la liste n'est pas triée et que les recherches sont
occasionnelles, mieux vaut faire une recherche linéaire
qu'un tri préalable. La dichotomie est rentable quand on
prévoit de très nombreuses recherches sur la même liste.

]]> 1.0 0.0 0 true true abc Le tableau doit être trié

]]> Bonne réponse : la dichotomie compare l'élément cherché
au milieu pour décider d'aller à gauche ou à droite. Si
le tableau n'est pas trié, cette comparaison ne donne
aucune information utile, et l'algorithme peut renvoyer
un faux négatif.

]]> Le tableau doit être de taille puissance de $2$

]]> Erreur : la taille n'a pas besoin d'être une puissance
de $2$. La dichotomie fonctionne pour toute taille
$\geq 0$.

]]> Le tableau doit avoir une taille connue à l'avance

]]> Erreur : c'est une caractéristique des tableaux Python
ou C en général, pas une contrainte de la dichotomie.

]]> Le tableau doit contenir uniquement des entiers

]]> Erreur : la dichotomie fonctionne sur tout type
comparable (entiers, flottants, chaînes, dates, etc.).

]]> Diviser pour régner — Q09 : Récursivité et diviser pour régner Pourquoi le paradigme diviser pour régner s'implémente-t-il
naturellement par récursivité ?

]]> Certains algorithmes DPR ont des versions itératives plus
efficaces (recherche dichotomique itérative, exponentiation
rapide itérative), mais la version récursive est souvent
plus claire pédagogiquement.

]]> 1.0 0.0 0 true true abc Parce que la récursivité est le seul moyen de coder une boucle en Python

]]> Erreur : Python permet aussi des boucles for et
while. La récursivité est un choix, pas une
obligation.

]]> Parce que le paradigme nécessite la mémoïsation

]]> Erreur : la mémoïsation concerne la programmation
dynamique, pas le diviser pour régner classique.

]]> Parce que la récursivité est plus rapide que l'itération

]]> Erreur : la récursivité est en réalité souvent un peu
plus lente (surcoût des appels) en Python. Son
intérêt est la lisibilité, pas la vitesse.

]]> Parce qu'on doit résoudre des sous-problèmes de même nature que le problème initial, ce qui s'exprime naturellement par un appel récursif

]]> Bonne réponse : la définition même du paradigme implique
que les sous-problèmes sont de même structure que le
problème principal. Une fonction qui s'appelle
elle-même sur le sous-problème est l'expression la plus
directe.

]]> Diviser pour régner — Q10 : Fusion de deux listes triées Pour fusionner deux listes déjà triées de longueur $n$
chacune en une seule liste triée, quelle est la complexité
de l'opération ?

]]> C'est précisément cette fusion en $O(n)$ par niveau, répétée
sur $\log n$ niveaux, qui donne la complexité globale en
$O(n \log n)$ du tri fusion.

]]> 1.0 0.0 0 true true abc $O(n^2)$

]]> Erreur : on n'a pas besoin de comparer chaque élément à
tous les autres, seulement aux candidats en tête de
chaque liste.

]]> $O(n \log n)$

]]> Erreur : c'est la complexité du tri fusion complet,
pas de la seule fusion. La fusion est l'étape
« combiner » du paradigme.

]]> $O(n)$

]]> Bonne réponse : on parcourt les deux listes
simultanément avec un index pour chacune. Chaque
comparaison fait avancer l'un des deux index. Au total,
on fait $2n$ pas, soit $O(n)$.

]]> $O(1)$

]]> Erreur : il faut quand même parcourir les éléments des
deux listes au moins une fois pour les disposer dans
l'ordre.

]]> Diviser pour régner — Q11 : Nombre de comparaisons en dichotomie Combien de comparaisons effectue au pire une recherche
dichotomique sur un tableau de $1\ 000$ éléments ?

]]> Repère utile : doubler la taille n'ajoute qu'une
comparaison. Pour passer de $1\ 000$ à $2\ 000$, on passe de
$10$ à $11$ comparaisons. C'est ce qui rend les algorithmes
logarithmiques exceptionnellement rapides à grande échelle.

]]> 1.0 0.0 0 true true abc $1$

]]> Erreur : on ne peut pas garantir une seule comparaison
dans le pire cas. Le pire cas atteint $\lceil \log_2 n \rceil$
comparaisons.

]]> $500$

]]> Erreur : la première étape de la dichotomie élimine la
moitié des candidats, mais on continue à diviser
ensuite. Le total est bien plus faible que $500$.

]]> $1\ 000$

]]> Erreur : c'est le nombre maximal de comparaisons d'une
recherche linéaire. La dichotomie est bien plus
rapide.

]]> Environ $10$

]]> Bonne réponse : $\log_2(1\ 000) \approx 9{,}97$. Au
pire, $10$ comparaisons suffisent pour trouver l'élément
ou conclure à son absence.

]]> Diviser pour régner — Q12 : Tri fusion sur un exemple Si l'on applique le tri fusion à la liste $[5, 2, 8, 3, 9, 1]$,
quelle est la première étape ?

]]> Après division récursive, on obtient des sous-listes de
taille $1$ (déjà triées). Puis les fusions remontent en
reconstituant des sous-listes triées de plus en plus
grandes : $[2, 5]$, $[2, 5, 8]$, etc. jusqu'au tableau
complet trié.

]]> 1.0 0.0 0 true true abc Diviser la liste en $[5, 2, 8]$ et $[3, 9, 1]$

]]> Bonne réponse : on coupe la liste au milieu en deux
sous-listes de taille (presque) égale. Chaque moitié
sera triée récursivement avant la fusion finale.

]]> Trouver le plus petit élément ($1$) et le placer en début

]]> Erreur : c'est le tri par sélection. Le tri fusion ne
cherche pas le minimum, il découpe la liste en deux.

]]> Trier la liste avec une fonction sorted intégrée

]]> Erreur : utiliser sorted éviterait l'algorithme
étudié. La question porte sur le déroulement du tri
fusion lui-même.

]]> Comparer $5$ et $2$, les permuter

]]> Erreur : c'est l'opération du tri à bulles. Le tri
fusion ne fait pas de comparaisons adjacentes au début.

]]> Diviser pour régner — Q13 : Complexité de l'exponentiation rapide Quelle est la complexité de l'exponentiation rapide pour
calculer $a^n$ ?

]]> Pour $n = 10^{18}$, la méthode naïve ferait $10^{18} - 1$
multiplications (impossible). L'exponentiation rapide n'en
fait qu'une soixantaine. Indispensable en cryptographie
asymétrique (RSA).

]]> 1.0 0.0 0 true true abc $O(1)$

]]> Erreur : la complexité dépend bien de $n$. Pour $n$
très grand, le calcul nécessite plusieurs étapes.

]]> $O(n)$

]]> Erreur : c'est la complexité de la méthode naïve
($a^n = a \cdot a^{n-1}$, $n - 1$ multiplications).
L'exponentiation rapide divise par deux au lieu de
décrémenter de $1$.

]]> $O(\log n)$

]]> Bonne réponse : à chaque appel récursif, on divise
l'exposant par deux. Il y a donc environ $\log_2 n$
niveaux d'appels, donc autant de multiplications.

]]> $O(n^2)$

]]> Erreur : aucune raison d'avoir une complexité quadratique
pour ce calcul.

]]> Diviser pour régner — Q14 : Récurrence du tri fusion Soit $T(n)$ le nombre d'opérations du tri fusion sur un
tableau de $n$ éléments. Quelle relation de récurrence
vérifie $T(n)$ ?

]]> Cette récurrence est l'archétype du « théorème maître » en
analyse de complexité : elle apparaît dans tous les
algorithmes DPR qui divisent en deux et combinent en
$O(n)$.

]]> 1.0 0.0 0 true true abc $T(n) = T(n/2) + 1$

]]> Erreur : c'est la récurrence de la dichotomie (un
seul appel récursif sur la moitié). Le tri fusion en
fait deux.

]]> $T(n) = T(n-1) + 1$

]]> Erreur : cette récurrence donne $T(n) = O(n)$, ce qui
est trop optimiste pour le tri fusion.

]]> $T(n) = 2 \cdot T(n/2) + n$

]]> Bonne réponse : on appelle deux fois la fonction sur des
moitiés (les $2 \cdot T(n/2)$), puis on fusionne en
$O(n)$ opérations. Le théorème maître donne
$T(n) = O(n \log n)$.

]]> $T(n) = T(n-1) + T(n-2)$

]]> Erreur : c'est la récurrence de Fibonacci. Le tri
fusion ne dépend pas des deux étapes précédentes.

]]> Diviser pour régner — Q15 : Stabilité du tri fusion Le tri fusion est-il un tri stable ?

]]> La stabilité importe quand on trie des données déjà triées
par un autre critère. Par exemple, trier des étudiants par
moyenne après les avoir triés par nom : un tri stable
conserve l'ordre alphabétique parmi les ex-aequo.

]]> 1.0 0.0 0 true true abc Oui, à condition d'utiliser <= plutôt que < dans la fonction de fusion

]]> Bonne réponse : le tri fusion est stable si la fusion
choisit l'élément de gauche en cas d'égalité. Cela
préserve l'ordre relatif des éléments égaux.

]]> La notion de stabilité ne s'applique qu'aux tris itératifs

]]> Erreur : la stabilité est une notion qui s'applique à
tout tri, indépendamment de son implémentation.

]]> Cela dépend de la taille de la liste

]]> Erreur : la stabilité d'un algorithme ne dépend pas de
la taille de l'entrée, mais de sa structure.

]]> Non, le tri fusion ne préserve pas l'ordre des éléments égaux

]]> Erreur : il l'est, à condition d'écrire correctement la
fonction de fusion.

]]> Diviser pour régner — Q16 : Tri fusion vs tri par insertion Pour trier un tableau de $1\ 000\ 000$ éléments, le tri
fusion ($O(n \log n)$) est environ combien de fois plus
rapide que le tri par insertion ($O(n^2)$) ?

]]> Cette différence d'ordre de grandeur explique pourquoi le
choix de l'algorithme est crucial. Sur petites entrées, les
tris simples sont compétitifs ; sur grandes entrées, les
tris en $O(n \log n)$ deviennent indispensables.

]]> 1.0 0.0 0 true true abc Environ $50\ 000$ fois

]]> Bonne réponse : pour $n = 10^6$, $n^2 = 10^{12}$ et
$n \log_2 n \approx 2 \cdot 10^7$. Le rapport est
environ $50\ 000$. C'est la différence entre une seconde
et $14$ heures sur la même machine.

]]> $1\ 000\ 000$ fois

]]> Erreur : ce serait le rapport $n^2 / n = n$, mais on
divise par $n \log n$, pas par $n$.

]]> $2$ fois

]]> Erreur : la différence est bien plus grande. $\log_2 n$
n'est qu'une fraction de $n$ pour de grandes valeurs.

]]> $10$ fois

]]> Erreur : la différence est de plusieurs ordres de
grandeur, pas un seul facteur $10$.

]]> Diviser pour régner — Q17 : Optimisation par mémoïsation Dans une implémentation récursive d'exponentiation
rapide, est-il utile d'ajouter de la mémoïsation ?

]]> La distinction est cruciale : le diviser pour régner peut
avoir des sous-problèmes redondants (cas de Fibonacci) ou
uniques (cas de l'exponentiation rapide). Seul le premier
bénéficie de la mémoïsation.

]]> 1.0 0.0 0 true true abc Oui, cela accélère le calcul

]]> Erreur : à chaque appel, on calcule une seule valeur
intermédiaire (demi = puissance(a, n // 2)), pas la
même plusieurs fois. La mémoïsation n'apporterait rien.

]]> Non, l'exponentiation rapide ne fait pas d'appels redondants

]]> Bonne réponse : à chaque appel, le sous-problème est
unique (un seul exposant intermédiaire est calculé). Il
n'y a donc aucun calcul redondant, contrairement à
Fibonacci naïf.

]]> Oui, mais seulement pour des exposants pairs

]]> Erreur : la mémoïsation n'est utile que s'il y a des
appels redondants, ce qui n'est pas le cas ici.

]]> Cela rendrait l'algorithme plus lent

]]> Erreur : la mémoïsation seule ne ralentit pas
significativement, mais l'avantage est nul ici.

]]> Diviser pour régner — Q18 : Détection d'une erreur dans la dichotomie Dans la fonction suivante :

def recherche(x, tab):
    gauche, droite = 0, len(tab) - 1
    while gauche < droite:        # ← ICI
        milieu = (gauche + droite) // 2
        if tab[milieu] == x:
            return milieu
        elif tab[milieu] < x:
            gauche = milieu + 1
        else:
            droite = milieu - 1
    return -1

Quel est le bug ?

]]> Erreur subtile et classique. Test concret : avec
tab = [5] et x = 5, on a gauche = droite = 0, la
condition gauche < droite est fausse, on sort
immédiatement et on renvoie $-1$ alors que $x$ est présent.

]]> 1.0 0.0 0 true true abc Il manque l'initialisation de milieu avant la boucle

]]> Erreur : milieu est défini à l'intérieur de la boucle,
ce qui est la convention habituelle.

]]> La condition de boucle devrait être gauche <= droite (avec <= au lieu de <)

]]> Bonne réponse : avec < strict, on n'examine pas le
dernier élément quand gauche == droite. La fonction
peut renvoyer $-1$ pour un élément qui est en réalité
présent.

]]> Le calcul de milieu est incorrect

]]> Erreur : le calcul (gauche + droite) // 2 est
standard et correct. Le bug est ailleurs.

]]> La fonction devrait être récursive pour fonctionner

]]> Erreur : la dichotomie peut s'écrire en itératif comme
en récursif. La forme itérative est même souvent
préférée.

]]> Diviser pour régner — Q19 : Tri rapide vs tri fusion Quelle est la principale différence entre le tri rapide
(quicksort) et le tri fusion ?

]]> Choisir entre les deux dépend du contexte : tri rapide pour
gagner de la mémoire (et accepter le risque du pire cas),
tri fusion pour la prévisibilité. Les bibliothèques
standard utilisent souvent des tris hybrides comme
Timsort.

]]> 1.0 0.0 0 true true abc Le tri rapide est toujours plus rapide que le tri fusion

]]> Erreur : ce n'est pas systématique. Sur certaines
entrées (déjà triées avec mauvais pivot), il est même
beaucoup plus lent.

]]> Le tri rapide est en place mais sa complexité au pire est $O(n^2)$, alors que le tri fusion est $O(n \log n)$ garanti mais pas en place

]]> Bonne réponse : le tri rapide partitionne autour d'un
pivot et est en place, mais avec un mauvais pivot, il
dégénère à $O(n^2)$. Le tri fusion garantit
$O(n \log n)$ mais utilise plus de mémoire.

]]> Le tri rapide est plus simple à comprendre

]]> Erreur : ces deux algorithmes ont une difficulté
comparable. Ce n'est pas la raison de leur distinction.

]]> Le tri rapide ne fonctionne que sur les entiers

]]> Erreur : les deux fonctionnent sur tout type comparable.

]]> Diviser pour régner — Q20 : Découpage déséquilibré Que se passe-t-il si le découpage en sous-problèmes est très
déséquilibré (par exemple, une moitié contenant $1$
élément et l'autre $n-1$ éléments) ?

]]> C'est pour cette raison que le choix du pivot est
crucial dans le tri rapide. Des stratégies sont utilisées
(médian de trois, pivot aléatoire) pour éviter les pires
cas pratiques.

]]> 1.0 0.0 0 true true abc La complexité reste $O(n)$

]]> Erreur : un découpage déséquilibré ne réduit pas la
taille suffisamment vite pour rester en $O(n)$.

]]> La complexité reste en $O(n \log n)$

]]> Erreur : la complexité $O(n \log n)$ suppose un
découpage équilibré (en deux moitiés de même taille).
Un découpage déséquilibré dégrade fortement la
performance.

]]> La complexité dégénère à $O(n^2)$

]]> Bonne réponse : avec ce découpage, on a $n$ niveaux de
récursion (au lieu de $\log n$), chacun coûtant $O(n)$.
Le total devient $O(n^2)$. C'est exactement ce qui se
produit avec un mauvais pivot dans le tri rapide.

]]> L'algorithme ne termine pas

]]> Erreur : tant que le découpage diminue strictement la
taille du sous-problème, l'algorithme termine. Le
problème est la performance, pas la terminaison.

]]> Diviser pour régner — Q21 : Application du théorème maître Soit la récurrence $T(n) = 4 \cdot T(n/2) + n$. Quelle est la
complexité asymptotique de $T(n)$ ?

]]> Le théorème maître donne $T(n) = O(n^{\log_b a})$ pour la
récurrence $T(n) = a T(n/b) + O(n^c)$ quand $\log_b a > c$.
Ici $a = 4$, $b = 2$, $c = 1$ : on a $\log_2 4 = 2 > 1$,
donc $O(n^2)$.

]]> 1.0 0.0 0 true true abc $O(n)$

]]> Erreur : avec $4$ sous-problèmes de taille $n/2$ chacun,
la complexité dépasse $O(n)$. À chaque niveau on
quadruple le nombre d'appels.

]]> $O(n^4)$

]]> Erreur : $4^{\log_2 n} = n^{\log_2 4} = n^2$, pas $n^4$.

]]> $O(n \log n)$

]]> Erreur : c'est le résultat pour $T(n) = 2 T(n/2) + n$,
pas $4 T(n/2) + n$.

]]> $O(n^2)$

]]> Bonne réponse : avec $4$ appels sur des moitiés, on a un
arbre d'appels qui croît comme $4^{\log_2 n} = n^2$.
C'est en effet la complexité du tri par sélection
version DPR sans optimisation.

]]> Diviser pour régner — Q22 : Profondeur de la pile en tri fusion Pour trier un tableau de $1\ 000$ éléments par tri fusion
récursif, quelle est la profondeur maximale de la pile
d'appels ?

]]> C'est une autre force du diviser pour régner avec
découpage équilibré : la profondeur logarithmique évite
tout problème de débordement de pile, même pour des
milliards d'éléments.

]]> 1.0 0.0 0 true true abc $500$

]]> Erreur : confusion possible avec « la moitié ». La
profondeur n'est pas $n/2$ mais bien $\log n$.

]]> Environ $10$

]]> Bonne réponse : $\log_2(1\ 000) \approx 10$. La pile
d'appels reste donc très peu profonde, ce qui évite
les RecursionError même pour de grandes entrées.

]]> $1$

]]> Erreur : un seul appel ne suffit pas à diviser
$1\ 000$ éléments jusqu'au cas de base.

]]> $1\ 000$

]]> Erreur : on ne descend pas $1\ 000$ niveaux. Le
découpage divise par deux à chaque niveau, donc la
profondeur croît comme $\log n$.

]]> Diviser pour régner — Q23 : Exponentiation modulaire Pour calculer $a^n \mod m$ avec de très grands entiers
(cryptographie), la méthode efficace est :

]]> L'exponentiation modulaire rapide est l'opération
fondamentale du chiffrement RSA. Elle permet de calculer
$a^n \mod m$ pour des entiers de plusieurs milliers de
bits, en quelques millisecondes.

]]> 1.0 0.0 0 true true abc Appliquer l'exponentiation rapide en réduisant modulo $m$ à chaque multiplication

]]> Bonne réponse : $(a \cdot b) \mod m = ((a \mod m) \cdot (b \mod m)) \mod m$,
donc on peut réduire à chaque étape sans changer le
résultat final. Cela maintient les entiers
intermédiaires petits ($< m^2$), tout en bénéficiant
de la complexité $O(\log n)$.

]]> Calculer $a^n$ entièrement, puis prendre le modulo

]]> Erreur : pour $a = 1024$ et $n = 10^9$, $a^n$ a plus
d'un milliard de chiffres et n'est pas calculable en
pratique. Il faut prendre le modulo à chaque étape.

]]> Utiliser une recherche dichotomique sur les diviseurs de $m$

]]> Erreur : la recherche dichotomique n'a aucun rapport
avec ce calcul.

]]> Utiliser le tri fusion sur les chiffres décimaux

]]> Erreur : aucun rapport entre tri et exponentiation
modulaire.

]]> Diviser pour régner — Q24 : Analyse d'un nouvel algorithme DPR On invente un algorithme qui, pour un tableau de $n$
éléments, le découpe en trois tiers, traite chaque tiers
récursivement, puis fait un travail $O(n)$ pour combiner.
Quelle est sa complexité ?

]]> En général, $a$ sous-problèmes de taille $n/b$ avec une
combinaison en $O(n)$ donne $O(n \log n)$ tant que
$\log_b a = 1$. C'est la « zone d'équilibre » du théorème
maître.

]]> 1.0 0.0 0 true true abc $O(n^3)$

]]> Erreur : on découpe en trois, mais chaque sous-problème
fait $1/3$ de la taille originale, pas $n/2$. Le
résultat reste $O(n \log n)$.

]]> $O(n)$

]]> Erreur : la combinaison à elle seule est en $O(n)$, mais
il y a aussi $\log_3 n$ niveaux à parcourir.

]]> $O(3^n)$

]]> Erreur : la complexité exponentielle apparaît avec des
appels qui ne réduisent pas la taille. Ici, on divise
la taille à chaque étape.

]]> $O(n \log_3 n)$

]]> Bonne réponse : la récurrence est
$T(n) = 3 T(n/3) + O(n)$. Le théorème maître donne
$T(n) = O(n \log n)$ (le facteur $\log_3$ étant
équivalent à $\log_2$ à une constante près).

]]> Diviser pour régner — Q25 : Reconnaître un algorithme DPR Parmi les algorithmes suivants, lequel n'est pas un
algorithme diviser pour régner ?

]]> Pour identifier un DPR, chercher : (1) un découpage en
sous-problèmes plus petits de même nature, (2) une
résolution récursive, (3) une étape de combinaison. Le tri
par insertion ne fait pas de découpage récursif, donc ce
n'est pas un DPR.

]]> 1.0 0.0 0 true true abc Le tri par insertion

]]> Bonne réponse : le tri par insertion ne divise pas le
problème. Il itère sur les éléments et place chacun à
sa place dans la portion déjà triée. C'est un
algorithme itératif classique, pas un DPR.

]]> L'exponentiation rapide

]]> Erreur : c'est un DPR. On réduit l'exposant de moitié
à chaque appel.

]]> La recherche dichotomique

]]> Erreur : c'est aussi un DPR. On divise l'intervalle de
recherche par deux à chaque étape.

]]> Le tri fusion

]]> Erreur : c'est un cas d'école du paradigme. On découpe
en deux moitiés, on trie chaque moitié récursivement,
on fusionne.

]]> Diviser pour régner — Q26 : Code de l'exponentiation rapide Quel code Python implémente correctement
l'exponentiation rapide récursive de $a$ à la
puissance $n$ (avec $n \geq 0$) ?

]]> Idée centrale : sauvegarder le résultat de
puissance(a, n // 2) dans une variable. Sans cette
mémorisation, l'algorithme dégénère en
exponentiation naïve. C'est l'illustration la plus
simple du diviser pour régner sur un seul
sous-problème.

]]> 1.0 0.0 0 true true abc def puissance(a, n): if n == 0: return 1 if n % 2 == 0: return puissance(a, n // 2) * puissance(a, n // 2) return a * puissance(a, n // 2) * puissance(a, n // 2)]]> Erreur : on calcule deux fois la même puissance
au lieu de la stocker dans une variable. La
complexité retombe à $O(n)$, ce qui annule l'avantage
de l'exponentiation rapide. Bug classique du
débutant.

]]> def puissance(a, n): if n == 0: return 1 return a * puissance(a, n - 1)]]> Erreur : c'est l'exponentiation naïve, en
$O(n)$ multiplications. Elle décrémente l'exposant
de $1$ à chaque étape au lieu de le diviser par
deux. La question demandait l'exponentiation
rapide.

]]> def puissance(a, n): return a ** n]]> Erreur : on utilise l'opérateur Python intégré, ce
qui n'illustre pas le paradigme étudié. La question
portait sur l'écriture explicite de
l'exponentiation rapide.

]]> def puissance(a, n): if n == 0: return 1 demi = puissance(a, n // 2) if n % 2 == 0: return demi * demi return a * demi * demi]]> Bonne réponse : on calcule une seule fois la
puissance pour la moitié de l'exposant, puis on
multiplie ce résultat par lui-même (et par a
supplémentaire si n est impair). Complexité
$O(\log n)$ multiplications.

]]> Diviser pour régner — Q27 : Partition du tri rapide Dans le tri rapide, l'opération de
partitionnement autour d'un pivot consiste à :

]]> Conséquence : si le pivot est mal choisi (extremum), la
partition peut produire deux moitiés très
déséquilibrées (par exemple $0$ et $n-1$ éléments), ce
qui dégrade la complexité à $O(n^2)$. C'est pourquoi
le choix du pivot (médiane, aléatoire) est crucial.

]]> 1.0 0.0 0 true true abc Réorganiser le tableau de sorte que tous les
éléments inférieurs au pivot soient à sa
gauche, et tous les éléments supérieurs à sa
droite ; le pivot lui-même est alors à sa position
finale dans le tableau trié

]]> Bonne réponse : c'est l'étape clé du tri rapide.
Une fois le pivot positionné, on trie récursivement
chacune des deux moitiés. La partition se fait en
$O(n)$ avec un parcours linéaire.

]]> Diviser le tableau en deux parties de taille égale

]]> Erreur : c'est ce que fait le tri fusion, pas
le tri rapide. Le tri rapide partitionne autour
d'une valeur (le pivot), pas autour de la position
médiane. Les deux moitiés peuvent être de tailles
très différentes.

]]> Compter le nombre d'inversions dans le tableau

]]> Erreur : compter les inversions est une opération
d'analyse, pas une étape du tri rapide. Aucun lien
avec le partitionnement.

]]> Trier la liste avant de choisir un pivot

]]> Erreur : ce serait absurde, puisque le but du tri
rapide est précisément de trier. La partition est
une étape préliminaire au tri, sans tri
préalable.

]]> Diviser pour régner — Q28 : DPR sans combinaison coûteuse La recherche dichotomique satisfait la récurrence
$T(n) = T(n/2) + O(1)$. Pourquoi obtient-on
$O(\log n)$ et non $O(n \log n)$ comme dans le tri
fusion ?

]]> Schéma général : pour la récurrence
$T(n) = a \cdot T(n/b) + O(n^c)$ : si $a < b^c$, le
coût est dominé par la combinaison, complexité
$O(n^c)$ ; si $a = b^c$, on a $O(n^c \log n)$ ; si
$a > b^c$, on a $O(n^{\log_b a})$. Pour la
dichotomie : $a = 1$, $b = 2$, $c = 0$, donc
$a = b^c = 1$, complexité $O(\log n)$.

]]> 1.0 0.0 0 true true abc Parce qu'il n'y a qu'un seul sous-problème à
chaque appel (au lieu de deux), et que la
combinaison se fait en temps constant $O(1)$
(au lieu de $O(n)$)

]]> Bonne réponse : la dichotomie ne fait qu'un seul
appel récursif (sur la moitié pertinente) et la
combinaison se résume à un test d'égalité ou de
comparaison. La somme géométrique des coûts donne
$O(\log n)$. Au tri fusion, on a deux appels et une
fusion en $O(n)$, ce qui donne $O(n \log n)$.

]]> Parce que la recherche dichotomique n'est pas un
algorithme diviser pour régner

]]> Erreur : elle relève bien du paradigme. Elle
divise l'espace de recherche par deux à chaque
appel, illustration classique du DPR.

]]> Parce que la recherche dichotomique fonctionne
uniquement sur des tableaux de taille puissance de
deux

]]> Erreur : la recherche dichotomique fonctionne pour
toute taille. Cette propriété n'a aucun rapport
avec sa complexité.

]]> Parce que les comparaisons sont gratuites en Python

]]> Erreur : les comparaisons coûtent du temps comme
toute opération. Mais elles sont en nombre
constant à chaque appel récursif, ce qui fait la
différence avec une fusion en $O(n)$.

]]> Diviser pour régner — Q29 : Trace du tri fusion On applique le tri fusion à la liste
[5, 2, 8, 3]. Quelles sont les listes
passées à la fusion finale (la dernière
étape, qui produit la liste triée
complète) ?

]]> Schéma global du tri fusion : une phase
descendante de découpage récursif (jusqu'aux
singletons), suivie d'une phase remontante
de fusions successives. Pour $n = 4$, la
structure d'appels forme un arbre binaire
complet de hauteur $\log_2 4 = 2$. À chaque
niveau, le coût total des fusions est en
$O(n)$, d'où la complexité globale en
$O(n \log n)$.

]]> 1.0 0.0 0 true true abc [2, 3, 5, 8] et []

]]> Erreur : la fusion combine deux
moitiés non vides. Une moitié vide
signifierait qu'on a fait un seul tri
récursif suivi d'une fusion sans
contrepartie, ce qui n'est pas le
tri fusion.

]]> [5], [2], [8], [3]

]]> Erreur : ce sont les listes singletons
obtenues à la fin du découpage. La
fusion finale ne combine que deux
listes, pas quatre. Quatre singletons
impliqueraient deux fusions
intermédiaires avant la fusion finale.

]]> [5, 2] et [8, 3]

]]> Erreur : ce sont les deux moitiés
obtenues après le premier découpage,
mais avant les tris récursifs. À la
fusion finale, ces moitiés ont déjà
été triées et sont devenues [2, 5]
et [3, 8].

]]> [2, 5] et [3, 8]

]]> Bonne réponse : on découpe d'abord en
[5, 2] et [8, 3]. On trie
récursivement chaque moitié : [5, 2]
devient [2, 5] après fusion de [5]
et [2] ; [8, 3] devient [3, 8]
après fusion de [8] et [3]. La
fusion finale combine [2, 5] et
[3, 8] pour produire [2, 3, 5, 8].

]]> Diviser pour régner — Q30 : Code de la fonction de fusion Quelle fonction Python implémente
correctement la fusion de deux listes
déjà triées en une seule liste triée ?

]]> Cette fonction est le cœur du tri fusion :
la qualité de l'algorithme global vient
de l'efficacité linéaire de la fusion.
Variante intéressante : implémenter la
fusion en place dans la liste
d'origine, ce qui économise de la
mémoire. C'est cependant plus délicat à
coder et n'apporte pas de gain en
complexité asymptotique.

]]> 1.0 0.0 0 true true abc def fusion(a, b): return a + b]]> Erreur : la simple concaténation ne
trie pas. Si a = [1, 4, 7] et b =
[2, 3, 5], on obtiendrait
[1, 4, 7, 2, 3, 5], qui n'est pas
trié. Il faut entrelacer les deux
listes par comparaisons.

]]> def fusion(a, b): return sorted(a + b)]]> Cette version fonctionne mais
n'illustre pas l'algorithme : on délègue
au tri intégré, qui ne tire pas parti
du fait que a et b sont déjà
triées. Complexité : $O((n+m) \log(n+m))$
au lieu de $O(n + m)$.

]]> def fusion(a, b): resultat = [] for x in a: for y in b: if x <= y: resultat.append(x) else: resultat.append(y) return resultat]]> Erreur : la double boucle imbriquée a
une complexité $O(n \cdot m)$ au lieu
de $O(n + m)$. De plus, on ajoute des
éléments en double (chaque élément de
a est comparé à chaque élément de
b, et chaque comparaison ajoute une
valeur). Le résultat n'est ni trié, ni
de la bonne taille.

]]> def fusion(a, b): i, j = 0, 0 resultat = [] while i < len(a) and j < len(b): if a[i] <= b[j]: resultat.append(a[i]) i += 1 else: resultat.append(b[j]) j += 1 resultat.extend(a[i:]) resultat.extend(b[j:]) return resultat]]> Bonne réponse : on utilise deux indices
i et j pour parcourir les deux
listes en parallèle. À chaque tour, on
ajoute le plus petit des deux éléments
de tête, et on avance l'indice
correspondant. Quand l'une des listes
est épuisée, on copie simplement le
reste de l'autre. Complexité : $O(n + m)$
où $n$ et $m$ sont les longueurs des
deux listes. Le <= (plutôt que <)
dans la comparaison garantit la
stabilité du tri.

]]> Diviser pour régner — Q31 : Code du partitionnement Dans le tri rapide, l'étape de
partitionnement réorganise un tableau
autour d'un pivot. Quel code Python
implémente correctement cette étape (avec
le pivot pris comme dernier élément du
sous-tableau, schéma de Lomuto) ?

]]> Le schéma de Lomuto est le plus simple à
retenir, mais celui de Hoare (avec
deux indices qui se rapprochent l'un de
l'autre) est en général un peu plus
efficace en pratique. Le choix du pivot
est crucial : avec un mauvais pivot
(extremum), la complexité dégénère à
$O(n^2)$. Stratégies courantes : pivot
aléatoire, médiane de trois, etc.

]]> 1.0 0.0 0 true true abc def partitionner(tab, debut, fin): gauche = [x for x in tab if x <= tab[fin]] droite = [x for x in tab if x > tab[fin]] return gauche + droite]]> Cette version fonctionne logiquement
(elle produit une liste partitionnée),
mais elle crée deux nouvelles listes,
ce qui contredit l'esprit du tri
rapide qui est de trier en place
avec une mémoire $O(\log n)$ pour la
pile. De plus, la signature ne renvoie
pas l'indice du pivot.

]]> def partitionner(tab, debut, fin): pivot = tab[fin] i = debut - 1 for j in range(debut, fin): if tab[j] <= pivot: i += 1 tab[i], tab[j] = tab[j], tab[i] tab[i + 1], tab[fin] = tab[fin], tab[i + 1] return i + 1]]> Bonne réponse : c'est le schéma de
Lomuto. L'indice i représente la
frontière entre les éléments « plus
petits que le pivot » (avant i) et
ceux « plus grands » (entre i et
j). À la fin, on place le pivot à sa
position définitive (entre les deux
zones), et la fonction renvoie cette
position. Complexité : $O(n)$ pour le
partitionnement seul, $O(n \log n)$ en
moyenne pour le tri complet.

]]> def partitionner(tab, debut, fin): return tab[fin]]]> Erreur : ce code ne fait que renvoyer
le pivot sans réorganiser le tableau.
Le partitionnement doit déplacer
activement les éléments selon leur
comparaison au pivot.

]]> def partitionner(tab, debut, fin): tab.sort() return len(tab) // 2]]> Erreur : trier le tableau entier
court-circuite tout l'intérêt du tri
rapide. Et le partitionnement ne doit
pas trier mais réarranger autour du
pivot.

]]>