$course$/QCM de NSI/Terminale/Listes, piles, files Structures de données linéaires : listes chaînées, piles
(LIFO) et files (FIFO). Opérations de base, complexité,
implémentations possibles, applications classiques (parcours,
parenthésage, parcours en largeur, etc.).

]]> Listes, piles, files — Q01 : Définition d'une pile Quel est le principe d'une pile (stack) ?

]]> Les piles sont fondamentales en informatique : pile
d'appels de fonctions, gestion d'historique (Ctrl+Z),
analyse syntaxique de parenthèses, parcours en
profondeur d'un graphe.

]]> 1.0 0.0 0 true true abc Tri automatique des éléments

]]> Erreur : aucun tri. Les éléments sont stockés dans
leur ordre d'arrivée, accessible uniquement par
le sommet.

]]> Premier entré, premier sorti (FIFO)

]]> Erreur : c'est le principe d'une file (queue),
pas d'une pile. Confusion classique entre les deux.

]]> Accès aléatoire à n'importe quel élément

]]> Erreur : ce serait un tableau classique. Une pile
impose un accès uniquement par le sommet.

]]> Dernier entré, premier sorti (LIFO)

]]> Bonne réponse : LIFO (Last In, First Out). On
ajoute (push) et on retire (pop) toujours par le
sommet. C'est le comportement d'une pile
d'assiettes : on prend toujours celle du haut.

]]> Listes, piles, files — Q02 : Définition d'une file Quel est le principe d'une file (queue) ?

]]> Les files sont utilisées pour : tâches en attente
(imprimante, ordonnanceur), parcours en largeur d'un graphe,
buffers de communication, et tout système où l'on
veut respecter l'ordre d'arrivée.

]]> 1.0 0.0 0 true true abc Élimination automatique des doublons

]]> Erreur : aucune dédoublonnage automatique.

]]> Dernier entré, premier sorti (LIFO)

]]> Erreur : c'est le principe d'une pile, pas
d'une file.

]]> Premier entré, premier sorti (FIFO)

]]> Bonne réponse : FIFO (First In, First Out). On
ajoute en queue (enfilement) et on retire en tête
(défilement). C'est le comportement d'une file
d'attente au supermarché.

]]> Accès direct au milieu de la structure

]]> Erreur : la file impose l'accès uniquement aux
extrémités.

]]> Listes, piles, files — Q03 : Opérations sur une pile Quelles sont les deux opérations principales d'une
pile ?

]]> Toutes ces opérations s'effectuent en temps constant
O(1) avec une bonne implémentation. C'est l'avantage
principal des piles et files par rapport aux
structures plus complexes.

]]> 1.0 0.0 0 true true abc push et pop

]]> Bonne réponse : push(x) (empiler) ajoute x au
sommet ; pop() (dépiler) retire et renvoie
l'élément du sommet. On a aussi souvent peek()
ou top() (consulter sans retirer) et
is_empty() (tester la vacuité).

]]> lire(i) et ecrire(i, x)

]]> Erreur : ce sont des opérations d'accès indexé,
propres à un tableau ; une pile n'accède qu'à son
sommet.

]]> enqueue et dequeue

]]> Erreur : ce sont les opérations d'une file,
pas d'une pile.

]]> add et remove

]]> Erreur : ces noms sont génériques. Les noms
standard sur une pile sont plus spécifiques.

]]> Listes, piles, files — Q04 : Opérations sur une file Quelles sont les opérations principales d'une file ?

]]> Les noms varient selon les langages et les ouvrages : enfiler et defiler en français, enqueue et dequeue en anglais. Le concept reste le même.

]]> 1.0 0.0 0 true true abc push et pop

]]> Erreur : ce sont les opérations d'une pile,
pas d'une file.

]]> sort et reverse (listes)

]]> Erreur : opérations sur les listes, pas sur les
files.

]]> min et max

]]> Erreur : ce sont des opérations d'agrégation, pas
de file.

]]> enqueue et dequeue

]]> Bonne réponse : enqueue(x) ajoute x à la queue ;
dequeue() retire et renvoie l'élément en tête.
Comme pour la pile, ces opérations sont en O(1).

]]> Listes, piles, files — Q05 : Application classique des piles Pour vérifier qu'une expression contient des
parenthèses bien équilibrées (par exemple
((a + b) * c)), quelle structure est la plus adaptée ?

]]> Cet exemple illustre bien le LIFO : la dernière
parenthèse ouverte est celle qui doit être fermée en
premier. L'algorithme s'étend aux crochets [],
accolades {}, balises HTML, etc.

]]> 1.0 0.0 0 true true abc Une file (FIFO)

]]> Erreur : la file ne convient pas. Pour
l'équilibrage, on a besoin d'accéder à la
parenthèse ouvrante la plus récente, ce qui est
du LIFO.

]]> Un tableau trié

]]> Erreur : aucun rapport avec un tri. C'est l'ordre
d'apparition qui compte, ce qui est une pile.

]]> Un dictionnaire

]]> Erreur : le dictionnaire n'est pas adapté à un
ordre temporel. La pile est la bonne structure.

]]> Une pile (LIFO)

]]> Bonne réponse : on empile les parenthèses
ouvrantes ; à chaque parenthèse fermante, on
dépile et on vérifie la correspondance. À la fin,
la pile doit être vide. C'est l'algorithme
standard.

]]> Listes, piles, files — Q06 : Application classique des files Pour gérer une file d'impression (les documents
arrivés en premier sont imprimés en premier), quelle
structure utiliser ?

]]> D'autres situations relèvent de la file : clients servis à un guichet, processus en attente du processeur, paquets en attente dans un routeur.

]]> 1.0 0.0 0 true true abc Une pile

]]> Erreur : avec une pile, le dernier document arrivé
serait imprimé en premier, ce qui est injuste.

]]> Un dictionnaire

]]> Erreur : pas de notion d'ordre temporel naturelle
dans un dictionnaire.

]]> Une liste triée par taille

]]> Erreur : trier par taille fausserait l'ordre
d'arrivée. Sauf si on veut une politique
spécifique (le plus petit d'abord), mais ce n'est
pas FIFO.

]]> Une file

]]> Bonne réponse : la file (FIFO) garantit que
l'ordre d'arrivée est respecté. C'est exactement
l'usage typique : ordonnanceur du système
d'exploitation, file d'impression, tampon
réseau.

]]> Listes, piles, files — Q07 : Pile en Python En Python, une manière simple d'implémenter une pile
utilise :

]]> Pour une pile « propre », on préférera implémenter une
classe Pile avec méthodes empiler, depiler,
est_vide, etc. Cela cache la liste sous-jacente et
empêche les usages aberrants (accès indexé direct).

]]> 1.0 0.0 0 true true abc Une liste avec append() et pop()

]]> Bonne réponse : lst.append(x) ajoute en fin
(sommet) et lst.pop() retire la fin (sommet),
tous deux en O(1) amorti. Simple et efficace.

]]> Une simple chaîne de caractères mutable

]]> Erreur : les chaînes sont immuables en Python.
Empiler créerait une nouvelle chaîne à chaque
opération, c'est inefficace.

]]> Un simple entier

]]> Un entier est une valeur
unique : il ne peut pas
contenir une suite
d'éléments empilés
successivement.

]]> Un dictionnaire

]]> Erreur : le dictionnaire n'a pas de notion d'ordre
en place pour cet usage.

]]> Listes, piles, files — Q08 : Implémenter une file rapide en Python On veut implémenter en Python une file dont les opérations enfiler et defiler restent rapides, même avec un très grand nombre d'éléments. Quelle implémentation convient ?

]]> Une file s'implémente classiquement avec un tableau ou avec deux piles. Les deux piles évitent tout décalage : chaque élément est empilé une fois, déversé une fois et dépilé une fois.

]]> 1.0 0.0 0 true true abc Une seule liste, avec append pour enfiler et pop(0) pour défiler

]]> Erreur : pop(0) retire le premier élément et oblige à décaler tous les autres d'une case, ce qui coûte un temps proportionnel à la taille de la file à chaque défilement.

]]> Une seule liste, avec insert(0, x) pour enfiler et pop() pour défiler

]]> Erreur : insert(0, x) place l'élément au début de la liste et décale tous les autres, ce qui coûte un temps proportionnel à la taille de la file à chaque enfilement.

]]> Un p-uplet, reconstruit avec + à chaque enfilement et chaque défilement

]]> Erreur : un p-uplet ne se modifie pas. Chaque opération fabrique un nouveau p-uplet en recopiant tous les éléments, ce qui coûte un temps proportionnel à la taille de la file.

]]> Deux listes utilisées comme piles : une d'entrée, une de sortie

]]> Bonne réponse : on empile en entrée avec append et on dépile en sortie avec pop(). Quand la pile de sortie est vide, on y déverse la pile d'entrée, ce qui remet les éléments dans l'ordre d'arrivée. Chaque élément n'est déplacé qu'une fois, si bien que le coût moyen par opération reste constant.

]]> Listes, piles, files — Q09 : Pile d'appels Quel rôle joue la pile d'appels (call stack) lors
de l'exécution d'un programme ?

]]> C'est précisément la pile d'appels qui sature en cas
de récursion infinie, provoquant le célèbre
RecursionError ou stack overflow. Sa taille est
typiquement limitée à quelques dizaines de milliers
d'appels.

]]> 1.0 0.0 0 true true abc Stocker les fichiers ouverts

]]> Erreur : les fichiers sont gérés par le système
d'exploitation, pas par la pile d'appels.

]]> Empiler le contexte de chaque appel de fonction

]]> Bonne réponse : c'est exactement le rôle d'une
pile au sens LIFO. Quand une fonction A appelle B,
le contexte de A reste empilé sous celui de B,
jusqu'à ce que B se termine et qu'on dépile pour
revenir à A.

]]> Compter les variables globales

]]> Erreur : aucun rapport. La pile d'appels gère les
contextes locaux.

]]> Stocker les données complètes d'une base de données

]]> Une base de données est
stockée sur le disque
dans des structures
dédiées, sans rapport
avec la pile d'appels
gérée par
l'interpréteur.

]]> Listes, piles, files — Q10 : Liste chaînée Qu'est-ce qu'une liste chaînée ?

]]> Variantes : listes simplement chaînées (un seul
pointeur next), doublement chaînées (next et
previous), circulaires (le dernier pointe vers le
premier). Chaque variante a ses cas d'usage.

]]> 1.0 0.0 0 true true abc Une liste reliée à une base de données

]]> Erreur : aucun rapport avec une base de données.

]]> Une liste chiffrée

]]> Erreur : « chaînée » et « chiffrée » sont des
mots différents. Aucun rapport avec la
cryptographie.

]]> Une liste qui ne peut pas être modifiée

]]> Erreur : ce serait une liste immuable. Une liste
chaînée peut tout à fait être modifiée.

]]> Des maillons reliant chaque valeur au suivant

]]> Bonne réponse : contrairement à un tableau (mémoire
contiguë), une liste chaînée est composée de
maillons qui se référencent. Ajouter ou supprimer
en tête se fait en O(1), mais l'accès indexé
coûte O(n).

]]> Listes, piles, files — Q11 : Complexité des opérations sur une pile Quelle est la complexité des opérations push et pop
sur une pile, pour une bonne implémentation ?

]]> Avec une liste Python, append et pop() (sans
argument) sont en O(1) amorti. Avec une liste
chaînée et un pointeur sur le sommet, c'est aussi
O(1). Pas de surprise.

]]> 1.0 0.0 0 true true abc O(n²) pour les deux

]]> Erreur : excessif.

]]> O(n) pour les deux

]]> Erreur : c'est trop coûteux. Les piles sont
réputées efficaces parce que ces opérations sont
en temps constant.

]]> O(\log n) pour les deux

]]> Erreur : pas de raison logarithmique. C'est un
accès direct.

]]> O(1) pour les deux

]]> Bonne réponse : push et pop agissent toujours
au sommet, donc en temps constant. C'est ce qui
rend les piles si utiles dans les algorithmes
comme la conversion infixe → postfixe ou le parcours en profondeur.

]]> Listes, piles, files — Q12 : Accès indexé dans une liste chaînée Quelle est la complexité d'accéder au k-ième élément
d'une liste chaînée simplement chaînée ?

]]> C'est le compromis fondamental : une liste chaînée
offre des insertions/suppressions efficaces (O(1)
en tête, O(n) ailleurs), mais un accès indexé lent.
Pour un accès rapide, utiliser un tableau.

]]> 1.0 0.0 0 true true abc O(k)

]]> Bonne réponse : il faut suivre les pointeurs un
par un depuis la tête. Pour atteindre l'élément
k, il faut k étapes : le coût est linéaire
en k.

]]> O(\log k)

]]> Erreur : pas de division par deux possible. C'est
plutôt linéaire.

]]> O(1)

]]> Erreur : les listes chaînées n'offrent pas
d'accès indexé en temps constant, contrairement
aux tableaux. Il faut parcourir.

]]> O(k²)

]]> Erreur : excessif.

]]> Listes, piles, files — Q13 : Évaluation d'une expression postfixée L'évaluation d'une expression en notation postfixée
(par exemple 2 3 + 4 *) utilise :

]]> Cette technique évite la gestion explicite des parenthèses : l'ordre d'écriture fixe à lui seul l'ordre des calculs.

]]> 1.0 0.0 0 true true abc Une pile

]]> Bonne réponse : on empile chaque opérande et l'on
dépile à chaque opérateur. Pour 2 3 + 4 , on empile 2,
puis 3 ; on rencontre +, on dépile 3 et 2,
on calcule 5, on empile 5 ; on empile 4 ;
on rencontre , on dépile 4 et 5, on calcule
20. Résultat : 20.

]]> Un arbre binaire de syntaxe

]]> Erreur : on peut représenter une expression par
un arbre, mais l'évaluation postfixée utilise une
pile.

]]> Un dictionnaire

]]> Le dictionnaire associe
des clés à des valeurs ;
il ne reflète pas l'ordre
temporel d'arrivée des
opérandes nécessaire à
l'évaluation d'une
expression postfixée.

]]> Une file

]]> Erreur : la file ne fonctionne pas pour ce cas. La
notation postfixée demande d'accéder aux deux
derniers opérandes, ce qui est typiquement LIFO.

]]> Listes, piles, files — Q15 : Distinction entre interface et implémentation « Pile » et « file » sont des interfaces abstraites.
Cela signifie que :

]]> C'est l'idée des types abstraits de données
(TAD) : on spécifie ce que la structure doit faire, pas comment. Une pile peut être implémentée
de plusieurs façons, l'utilisateur du TAD ne s'en
soucie pas.

]]> 1.0 0.0 0 true true abc Elles sont écrites en assembleur

]]> Erreur : aucun rapport avec le langage.

]]> Elles sont obsolètes

]]> Erreur : elles sont au contraire fondamentales et
omniprésentes.

]]> Elles définissent le comportement, pas la structure

]]> Bonne réponse : on peut implémenter une pile avec
une liste Python, une liste chaînée, un tableau,
etc. Tant que les opérations respectent LIFO,
c'est une pile. Cette abstraction est essentielle
en programmation modulaire.

]]> Elles ne peuvent pas du tout être implémentées en Python

]]> Erreur : Python permet bien sûr d'implémenter ces
structures.

]]> Listes, piles, files — Q16 : Pile vide Que faut-il faire avant de tenter un pop() sur une
pile ?

]]> Bonne pratique : dans une classe Pile, proposer une méthode est_vide que l'utilisateur appelle avant de dépiler, ou vérifier la condition au début de depiler avec un assert explicite.

]]> 1.0 0.0 0 true true abc Multiplier la taille par deux

]]> Erreur : aucun rapport. Aucune opération de
redimensionnement n'est nécessaire avant un pop.

]]> Recalculer la longueur

]]> Erreur : pas de calcul à faire avant un pop.

]]> Vérifier qu'elle n'est pas vide

]]> Bonne réponse : un pop sur pile vide provoque
en général une erreur (IndexError en Python). Il
faut toujours vérifier d'abord, ou capturer
l'exception.

]]> Toujours appeler peek() d'abord

]]> Erreur : peek() consulte mais ne protège pas
d'un pop sur une pile vide.

]]> Listes, piles, files — Q17 : Liste chaînée vs tableau Quel est l'avantage principal d'une liste chaînée
sur un tableau dynamique ?

]]> Compromis classique : tableau pour l'accès indexé
rapide ; liste chaînée pour les insertions/suppressions
fréquentes en début ou milieu (avec un pointeur sur
l'emplacement).

]]> 1.0 0.0 0 true true abc L'accès indexé est plus rapide

]]> Erreur : c'est l'inverse. Le tableau a un accès
O(1), la liste chaînée O(n).

]]> Elle utilise moins de mémoire

]]> Erreur : c'est l'inverse, en général. Une liste
chaînée stocke un pointeur supplémentaire par
élément, ce qui consomme plus de mémoire.

]]> Insertion en tête en temps constant

]]> Bonne réponse : c'est l'avantage clé. Avec un
tableau, insérer en tête demande de décaler tous
les éléments. Avec une liste chaînée, on
modifie juste un pointeur.

]]> Elle est intrinsèquement toujours triée

]]> Erreur : aucun tri automatique.

]]> Listes, piles, files — Q18 : Implémentation orientée objet d'une pile En Python, dans une classe Pile minimale, quelles
méthodes définit-on typiquement ?

]]> L'utilisateur ne manipule que les méthodes de la pile, jamais la liste qui la stocke : c'est ce qui distingue une pile, accessible par son seul sommet, d'un tableau libre.

]]> 1.0 0.0 0 true true abc empiler, depiler, est_vide

]]> Bonne réponse : ces trois méthodes forment le cœur de l'interface d'une pile. On y ajoute souvent sommet(), qui consulte sans dépiler, ou taille().

]]> lire(i), ecrire(i, x), taille

]]> Erreur : lire ou écrire à un indice
quelconque, ce serait un tableau, pas une
pile, qui n'est accessible que par son
sommet.

]]> add, remove, find, sort

]]> Erreur : ces méthodes ne correspondent pas à
l'API d'une pile. Une pile n'offre pas de find
ou sort.

]]> Une seule méthode do(action, x)

]]> Erreur : trop minimaliste. Une pile expose
plusieurs opérations distinctes, chacune avec sa
propre méthode.

]]> Listes, piles, files — Q19 : Détection de parenthèses déséquilibrées L'expression (()) est-elle bien parenthésée ? Et
(() ?

]]> Règle algorithmique : une expression est bien
parenthésée si et seulement si la pile est vide à la
fin, ET qu'aucune fermante n'apparaît sur une pile
vide pendant le parcours.

]]> 1.0 0.0 0 true true abc (()) et (() sont toutes deux mal parenthésées

]]> Erreur : (()) est parfaitement équilibrée :
deux parenthèses ouvrantes, deux fermantes, dans
le bon ordre.

]]> La parité du nombre de caractères suffit à juger

]]> Erreur : ()( est de longueur paire mais
déséquilibré. La parité ne suffit pas.

]]> (()) et (() sont toutes deux bien parenthésées

]]> Erreur : (() ne ferme pas la première
parenthèse. Donc déséquilibrée.

]]> (()) est correcte, (() ne l'est pas

]]> Bonne réponse : avec une pile, on empile chaque
(, on dépile à chaque ). Pour (()), la pile
est vide à la fin. Pour ((), la pile contient
encore la première parenthèse, qui n'est jamais
fermée : l'expression est déséquilibrée.

]]> Listes, piles, files — Q20 : Analyse d'un code de pile Que renvoie le code Python suivant ?

`python
pile = []
for x in [1, 2, 3, 4]:
pile.append(x)
print(pile.pop())
`

]]> Comportement standard LIFO : dernier entré, premier
sorti. Si on continuait à pop() plusieurs fois, on
obtiendrait 4, 3, 2, 1 dans l'ordre.

]]> 1.0 0.0 0 true true abc 4

]]> Bonne réponse : on a empilé 1, 2, 3, 4. Le
sommet est 4. pop() retire et renvoie 4.

]]> 0

]]> Erreur : aucun rapport avec 0.

]]> 1

]]> Erreur : c'est l'élément de bas de pile (le
premier empilé). Mais pop() retire le sommet
(le dernier empilé).

]]> La liste entière [1, 2, 3]

]]> Erreur : pop() ne retourne qu'un seul élément.

]]> Listes, piles, files — Q21 : Pourquoi pas list.pop(0) pour une file Pourquoi list.pop(0) est-il inefficace pour
implémenter une file en Python ?

]]> C'est un piège classique en Python. Pour une file efficace, on peut par exemple utiliser deux piles, l'une pour enfiler et l'autre pour défiler, ou une liste accompagnée d'un indice qui repère la tête de la file.

]]> 1.0 0.0 0 true true abc Parce que ça lève toujours une erreur

]]> Erreur : pop(0) fonctionne sur une liste non
vide. Le problème est la performance, pas la
correction.

]]> Parce que pop ne peut pas prendre d'argument

]]> Erreur : pop(i) accepte un argument optionnel.

]]> Parce que les listes Python ne sont pas mutables

]]> Erreur : les listes sont mutables.

]]> Il faut décaler tous les éléments, en O(n)

]]> Bonne réponse : les éléments d'une liste Python sont rangés les uns à la suite des autres en mémoire. Retirer le premier élément force à décaler tous les autres d'une case.

]]> Listes, piles, files — Q23 : Récursivité et pile Toute fonction récursive peut être convertie en une
version itérative utilisant explicitement :

]]> Cette technique de dérécursivation est utile
quand la profondeur de récursion dépasse la limite
Python (souvent 1000). On remplace les appels par
des push/pop sur une pile explicite, et on contrôle
ainsi la mémoire utilisée.

]]> 1.0 0.0 0 true true abc Une file

]]> Erreur : la récursivité a une nature LIFO (l'appel
le plus profond est traité en premier). C'est
donc une pile.

]]> Une pile (la pile d'appels)

]]> Bonne réponse : c'est précisément ce que fait le
processeur en interne. En remplaçant les appels
récursifs par des opérations sur une pile
explicite, on transforme une fonction récursive
en boucle. Cela peut éviter les dépassements de
pile.

]]> Un dictionnaire

]]> Erreur : un dictionnaire ne préserve pas l'ordre
d'appels. La structure adaptée est une pile.

]]> Un arbre binaire de recherche

]]> Erreur : un arbre est une donnée, pas un
mécanisme d'exécution.

]]> Listes, piles, files — Q24 : Chercher par clé ou par valeur dans un dictionnaire Le dictionnaire annuaire associe à chaque nom un numéro de téléphone : par exemple, annuaire["Léa"] vaut "0601020304". Il contient 100000 entrées. On effectue deux recherches :

- (A) trouver le numéro de Léa ;
- (B) trouver le nom de la personne dont le numéro est "0601020304".

Que peut-on dire de leur coût ?

]]> Chercher par clé dans un dictionnaire prend un temps constant en moyenne ; chercher une valeur dans une liste, ou parmi les valeurs d'un dictionnaire, demande un parcours de coût linéaire. Pour retrouver rapidement un nom à partir d'un numéro, il faudrait un second dictionnaire dont les numéros sont les clés.

]]> 1.0 0.0 0 true true abc (B) est quasi immédiate, (A) demande de parcourir les entrées

]]> Erreur : tu inverses les rôles des clés et des valeurs. Ici, les noms sont les clés, ce sont eux qui donnent un accès direct ; les numéros sont les valeurs.

]]> Les deux demandent de parcourir les entrées, comme dans une liste

]]> Erreur : ce serait le cas si l'annuaire était une liste de couples. Dans un dictionnaire, l'accès par clé annuaire["Léa"] ne parcourt pas les entrées et prend un temps constant en moyenne.

]]> (A) est quasi immédiate, (B) demande de parcourir les entrées

]]> Bonne réponse : l'accès annuaire["Léa"] prend un temps constant en moyenne, quelle que soit la taille du dictionnaire. Retrouver un nom à partir d'un numéro oblige au contraire à examiner les couples un par un, comme dans une liste.

]]> Les deux sont quasi immédiates, car un dictionnaire est indexé

]]> Erreur : seul l'accès par clé est rapide. Rien ne permet d'aller directement à la valeur "0601020304" : il faut parcourir les entrées jusqu'à la trouver.

]]> Listes, piles, files — Q25 : Choisir la bonne structure On souhaite gérer l'historique des actions d'un éditeur
de texte, avec une fonction « annuler » (Ctrl+Z). Quelle
structure est la plus adaptée ?

]]> Petit défi : implémenter Ctrl+Z et Ctrl+Y. Astuce
classique : deux piles. Quand on annule, on dépile de
la pile « historique » et on empile dans la pile
« refait ». Quand on refait, c'est l'inverse.

]]> 1.0 0.0 0 true true abc Une file

]]> Erreur : la file annulerait la première action,
pas la dernière. Or « annuler » concerne la plus
récente.

]]> Une liste triée

]]> Erreur : pas de tri à faire ; l'ordre est déjà
donné par l'arrivée.

]]> Une pile

]]> Bonne réponse : à chaque action, on l'empile.
Ctrl+Z dépile et annule la dernière. C'est le cas
d'usage typique des piles. Pour le « refaire »
(Ctrl+Y), on utilise une deuxième pile.

]]> Un dictionnaire

]]> Erreur : pas de notion temporelle adaptée.

]]> Listes, piles, files — Q26 : Maillon d'une liste chaînée On souhaite implémenter une liste simplement chaînée
en Python. Quelle classe représente un maillon
correctement ?

]]> Pour parcourir la liste chaînée, on commence par la
tête et on suit les pointeurs suivant jusqu'à
atteindre None. La classe Maillon est l'élément
atomique ; la classe ListeChainee (ou directement
une variable « tête ») gère la collection.

]]> 1.0 0.0 0 true true abc `python
class Maillon:
def __init__(self, valeur, precedent, suivant):
self.valeur = valeur
self.precedent = precedent
self.suivant = suivant
`

]]> Erreur : on a ici un maillon doublement chaîné (avec un pointeur vers le précédent et
un vers le suivant). C'est utile pour certaines
structures, mais la question portait sur une
liste simplement chaînée.

]]> `python
class Maillon:
def __init__(self, valeur, suivant=None):
self.valeur = valeur
self.suivant = suivant
`

]]> Bonne réponse : un maillon contient sa propre
valeur et une référence vers le maillon suivant
(ou None si c'est le dernier). C'est la
définition canonique. La construction d'une
liste chaînée se fait ensuite en chaînant
plusieurs maillons via leur attribut suivant.

]]> `python
def maillon(valeur):
return [valeur]
`

]]> Erreur : on retourne ici une liste Python avec
un seul élément, ce qui n'est pas un maillon.
Pour chaîner plusieurs valeurs, il faudrait
imbriquer des listes, ce qui est lourd et peu
clair par rapport à une vraie classe.

]]> `python
class Maillon:
def __init__(self, valeur):
self.valeur = valeur
`

]]> Erreur : il manque l'attribut suivant. Sans
lui, le maillon ne peut pas pointer vers le
suivant et la « chaîne » est cassée. Ce serait
juste un conteneur de valeur, pas un maillon.

]]> Listes, piles, files — Q27 : Parcours en profondeur avec pile explicite Pour effectuer un parcours en profondeur d'un arbre
ou d'un graphe sans utiliser la récursivité, quel
algorithme et quelle structure utilise-t-on ?

]]> Mémoire récurrente :
- Pile + parcours = parcours en profondeur.
- File + parcours = parcours en largeur.
Cette dualité s'observe sur les arbres comme sur
les graphes, et illustre la puissance des
structures linéaires LIFO/FIFO en algorithmique.

]]> 1.0 0.0 0 true true abc On trie d'abord les sommets puis on les parcourt
dans l'ordre

]]> Erreur : on parle ici d'un parcours qui
respecte la structure du graphe ou de l'arbre,
pas d'un parcours par valeur croissante. Trier
n'a pas de sens dans ce contexte.

]]> On utilise une file : on enfile le sommet
de départ et on défile à chaque étape

]]> Erreur : avec une file (FIFO), on obtient un
parcours en largeur, pas en profondeur.
Le parcours en profondeur explore d'abord
les descendants avant les frères, ce qui est
un comportement LIFO.

]]> On utilise un dictionnaire pour stocker les
sommets visités

]]> Réponse partielle : un dictionnaire (ou un
ensemble) sert effectivement à mémoriser les
sommets déjà visités, mais ce n'est pas la
structure qui dirige le parcours. C'est la
pile (ou la file) qui décide de l'ordre de
visite.

]]> Une pile : dépiler un sommet, le marquer, empiler ses voisins

]]> Bonne réponse : la pile explicite simule
exactement ce que ferait la récursion via la
pile d'appels du langage. C'est un cas concret
de dérécursivation. Avantage : on contrôle la
mémoire et on évite les RecursionError sur
les graphes profonds.

]]> Listes, piles, files — Q28 : Annuler et refaire avec deux piles On veut implémenter une fonctionnalité « annuler »
(Ctrl+Z) et « refaire » (Ctrl+Y) dans un éditeur.
Quelle structure utiliser ?

]]> Variante avancée : pour gérer un historique
arborescent (où chaque action peut produire une
branche), il faut utiliser un arbre, pas
seulement deux piles. C'est le modèle utilisé par
certains éditeurs avancés (vim, Emacs en mode
undo-tree).

]]> 1.0 0.0 0 true true abc Deux piles, une « historique » et une « refaire »

]]> Bonne réponse : c'est le schéma standard des
éditeurs de texte. Les deux piles évoluent
symétriquement, sauf au moment d'une nouvelle
action, qui rend impossible de « refaire » les
actions annulées précédemment (c'est le
comportement attendu : on ne peut pas refaire
ce qui n'existe plus dans la branche
d'historique courante).

]]> Un dictionnaire indexé par l'instant de l'action

]]> Solution surdimensionnée : un dictionnaire
permet d'aller à n'importe quel instant, ce
qui n'est pas demandé pour Ctrl+Z/Ctrl+Y. Les
deux opérations agissent toujours sur la
dernière action ou la dernière action
annulée, ce qui correspond à des piles.

]]> Une seule pile suffit

]]> Erreur : avec une seule pile, on peut annuler
mais on perd définitivement les actions
annulées. Pour pouvoir les refaire, il
faut les conserver quelque part : c'est le
rôle de la deuxième pile.

]]> Une file pour l'historique, une pile pour le refaire

]]> Erreur : une file annulerait l'action la plus
ancienne (FIFO), alors qu'on veut annuler la
plus récente (LIFO). Il faut donc une pile
pour l'historique, pas une file.

]]> Listes, piles, files — Q29 : Deux implémentations d'une même file Deux programmeurs implémentent une file : l'un avec
une liste Python, l'autre avec deux piles. Qu'ont en
commun leurs deux versions ?

]]> L'interface d'une structure est la liste de ses
opérations et de ce qu'elles garantissent ;
l'implémentation est la façon de les programmer.
Plusieurs implémentations peuvent respecter la même
interface, avec des coûts différents.

]]> 1.0 0.0 0 true true abc Rien du tout : une file construite avec deux piles n'est pas une vraie file, seule la liste en est une

]]> Si elle rend les éléments dans l'ordre d'arrivée,
c'est une file, quelle que soit sa construction.

]]> Le même coût pour chaque opération, puisque les deux versions produisent exactement le même résultat

]]> Le coût dépend de l'implémentation : pop(0) sur
une liste décale tous les éléments, les deux
piles l'évitent.

]]> Le même code, à quelques noms de variables et de fonctions près, puisque le résultat est le même

]]> Les codes diffèrent entièrement ; seul le
comportement observable est identique.

]]> La même interface (enfiler, defiler, est_vide) et le même ordre premier entré, premier sorti

]]> Un programme qui utilise la file ne voit aucune
différence entre les deux.

]]> Listes, piles, files — Q30 : Remplacer l'implémentation sans toucher au programme Un programme de gestion d'impressions utilise une
file uniquement par enfiler, defiler et
est_vide. On remplace l'implémentation de la file
par une version plus rapide qui offre les mêmes
opérations. Que faut-il modifier dans le programme ?

]]> Le programme ne connaît la file que par ses trois
opérations. Tant que la nouvelle implémentation les
fournit avec le même comportement, aucun appel ne
change. C'est la distinction entre interface et
implémentation.

]]> 1.0 0.0 0 true true abc Tous les appels à defiler, car la nouvelle version rend les éléments dans l'autre sens

]]> Une file reste une file : defiler rend toujours
le plus ancien élément, sinon l'interface ne
serait pas respectée.

]]> Le programme entier, une structure de données ne se remplaçant pas en cours de projet

]]> Séparer interface et implémentation sert
précisément à rendre ce remplacement indolore.

]]> Les noms des opérations, qui dépendent de l'implémentation choisie

]]> Les noms font partie de l'interface, justement
conservée.

]]> Rien : il n'utilise que l'interface, qui n'a pas changé

]]> C'est tout l'intérêt de programmer contre une
interface : l'implémentation peut changer
librement.

]]> Listes, piles, files — Q31 : Deux codes, une même file ? Deux implémentations d'une file à partir d'une liste
Python f, initialement vide :

- version A : enfiler(x) fait f.append(x) et
defiler() renvoie f.pop(0) ;
- version B : enfiler(x) fait f.insert(0, x) et
defiler() renvoie f.pop().

On enfile 1, 2 puis 3, et on défile trois
fois. Laquelle se comporte comme une file ?

]]> Les deux versions respectent le comportement premier
entré, premier sorti : elles implémentent la même
interface. Elles diffèrent par le coût : chacune
contient une opération qui décale tous les éléments
(pop(0) dans A, insert(0, x) dans B).

]]> 1.0 0.0 0 true true abc Seule la version A, la version B rendant 3, 2, 1

]]> Dans B, après trois enfilements la liste vaut
[3, 2, 1] et pop() retire 1, le plus
ancien.

]]> Les deux : chacune rend 1, puis 2, puis 3

]]> A range à droite et retire à gauche ; B range à
gauche et retire à droite. Dans les deux cas, le
plus ancien sort en premier.

]]> Aucune des deux, une file ne pouvant pas se construire avec une seule liste

]]> Une liste suffit ; les deux versions respectent
l'interface, avec des coûts différents.

]]> Seule la version B, la version A rendant 3, 2, 1

]]> Dans A, la liste vaut [1, 2, 3] et pop(0)
retire 1 : l'ordre d'arrivée est respecté.

]]> Listes, piles, files — Q32 : Une pile qui empile en tête ``python
class Pile:
def __init__(self):
self.elements = []

def empiler(self, x):
self.elements.insert(0, x)

def depiler(self):
return self.elements.pop(0)

def est_vide(self):
return len(self.elements) == 0
``

Cette classe est-elle une implémentation correcte
d'une pile ?

]]> La classe respecte l'interface d'une pile : dernier
entré, premier sorti. Elle est simplement moins
efficace que la version qui empile en fin de liste,
car insert(0, x) et pop(0) décalent tous les
éléments à chaque opération.

]]> 1.0 0.0 0 true true abc Oui : le dernier empilé est le premier dépilé ; seul le coût diffère de la version append et pop()

]]> Après empiler(1), empiler(2), empiler(3), la
liste vaut [3, 2, 1] et depiler() renvoie
3.

]]> Non : depiler renvoie le premier élément empilé, ce qui en fait une file et non une pile

]]> pop(0) retire l'élément en tête, et c'est le
dernier empilé qui s'y trouve.

]]> Oui, mais seulement pour des entiers, la méthode insert refusant les autres types de valeurs

]]> insert accepte n'importe quel objet ; le type
des éléments n'a aucune importance.

]]> Non : une pile doit obligatoirement s'écrire avec append pour empiler et pop() pour dépiler

]]> L'interface impose un comportement, pas des
méthodes de liste précises.

]]> Listes, piles, files — Q33 : Trace d'une suite d'opérations sur une file Sur une file vide, on enfile 3, on enfile 7, on défile, on
enfile 2, on défile, puis on enfile 9. Que contient la
file, de la tête vers la queue ?

]]> Dans une file, défiler retire toujours l'élément le plus ancien ;
suivre une trace, c'est tenir la liste des arrivées non encore
servies.

]]> 1.0 0.0 0 true true abc 2 puis 9

]]> Bonne réponse : le premier défilement retire 3, le second
retire 7 ; restent 2 puis 9, dans l'ordre d'arrivée.

]]> 3 puis 9, comme dans une pile

]]> Erreur : ce serait le contenu d'une pile, où l'on retire le
dernier arrivé.

]]> 7 puis 2

]]> Erreur : 7 a été retiré par le second défilement.

]]> 9 puis 2

]]> Erreur : 2 est arrivé avant 9, il est donc en tête.

]]> Listes, piles, files — Q34 : Une file construite avec deux piles Une file est réalisée avec deux piles, entree et sortie :
enfiler empile sur entree. Pour défiler, que faire quand
sortie est vide ?

]]> Deux inversions successives rétablissent l'ordre d'arrivée : c'est
ce qui permet de faire une file avec deux piles.

]]> 1.0 0.0 0 true true abc Échanger les noms des deux piles sans déplacer aucun élément

]]> Erreur : échanger ne renverse pas l'ordre, le sommet resterait
le dernier arrivé.

]]> Renvoyer une erreur, la file étant forcément vide elle aussi

]]> Erreur : la file peut contenir des éléments encore dans
entree.

]]> Vider entree dans sortie un par un, puis dépiler sortie

]]> Bonne réponse : en passant d'une pile à l'autre, l'ordre
s'inverse, le plus ancien se retrouve au sommet de sortie.
Chaque élément n'est déplacé qu'une fois, le coût moyen reste
constant.

]]> Dépiler directement entree, qui contient tous les éléments

]]> Erreur : le sommet de entree est le dernier arrivé, on
obtiendrait une pile.

]]> Listes, piles, files — Q35 : Le premier élément servi Une file contient, de la tête vers la queue, 4, 8 et
1. On enfile 6 puis on défile. Quelle valeur est
retirée ?

]]> Premier arrivé, premier servi : enfiler et défiler agissent aux
deux extrémités opposées.

]]> 1.0 0.0 0 true true abc 6, le dernier enfilé

]]> Erreur : retirer le dernier arrivé serait le comportement d'une
pile.

]]> 1, le dernier avant l'ajout

]]> Erreur : 1 est en queue, loin de la tête.

]]> 8, l'élément du milieu

]]> Erreur : 8 ne sort qu'après 4.

]]> 4, la tête de la file

]]> Bonne réponse : enfiler ajoute en queue et ne change pas la
tête ; défiler retire la tête, 4.

]]> Listes, piles, files — Q36 : Une file dans un tableau de taille fixe Une file est rangée dans un tableau de taille fixe avec deux
indices, tete et queue, qui avancent à chaque défilement et à
chaque enfilement. Que faire quand queue atteint la fin du
tableau alors que des cases du début ont été libérées ?

]]> Le tableau circulaire donne des enfilements et défilements en temps
constant avec une mémoire fixe.

]]> 1.0 0.0 0 true true abc Refuser l'enfilement, la file devant être considérée comme pleine

]]> Erreur : des cases sont libres, la file n'est pas pleine.

]]> Reprendre à l'indice 0, le tableau étant parcouru en cercle

]]> Bonne réponse : les indices avancent modulo la taille du
tableau. Les cases libérées en tête sont réutilisées, sans
jamais décaler les éléments.

]]> Décaler tous les éléments vers le début du tableau à chaque fois

]]> Erreur : décaler coûte un temps proportionnel au nombre
d'éléments, ce que l'on cherche à éviter.

]]> Remettre tete à 0 sans toucher à queue, qui reste en place

]]> Erreur : tete désigne le plus ancien élément, le déplacer
perdrait des valeurs.

]]> Listes, piles, files — Q37 : Transvaser une liste par une pile Que contient sortie à la fin ?
`python
pile = []
for x in [1, 2, 3]:
pile.append(x)
sortie = []
while pile:
sortie.append(pile.pop())
`

]]> Empiler puis dépiler tout renverse une séquence : c'est le
comportement dernier entré, premier sorti.

]]> 1.0 0.0 0 true true abc [1, 2, 3]

]]> Erreur : passer par une pile inverse l'ordre.

]]> [3, 2, 1]

]]> Bonne réponse : les éléments sortent de la pile dans l'ordre
inverse de leur entrée ; sortie est la liste renversée.

]]> Une erreur, pop sur une pile vide

]]> Erreur : la boucle while pile s'arrête dès que la pile est
vide, avant tout pop fautif.

]]> []

]]> Erreur : sortie reçoit chaque élément dépilé.

]]> Listes, piles, files — Q38 : La hauteur maximale d'une pile de parenthèses On lit ((())()) caractère par caractère, en empilant chaque
parenthèse ouvrante et en dépilant à chaque fermante. Quelle
hauteur maximale la pile atteint-elle ?

]]> La hauteur de la pile mesure l'imbrication courante ; son maximum
est la profondeur de l'expression.

]]> 1.0 0.0 0 true true abc 8, la longueur de la chaîne

]]> Erreur : seules les ouvrantes sont empilées, et pas toutes en
même temps.

]]> 0, la pile finissant vide

]]> Erreur : la pile finit vide, mais elle a été remplie entre
temps.

]]> 3, au plus profond de l'imbrication

]]> Bonne réponse : la hauteur de la pile est le nombre de
parenthèses ouvertes non encore fermées ; son maximum est la
profondeur d'imbrication, 3 ici.

]]> 4, le nombre de parenthèses ouvrantes

]]> Erreur : les fermantes dépilent en cours de route, la pile ne
contient jamais toutes les ouvrantes à la fois.

]]> Listes, piles, files — Q39 : Une file pour visiter niveau par niveau Pour visiter un arbre ou un graphe niveau par niveau, on range les
sommets découverts dans une file. Pourquoi une file et non une
pile ?

]]> File ou pile, le même algorithme de parcours change d'ordre de
visite : largeur avec une file, profondeur avec une pile.

]]> 1.0 0.0 0 true true abc Une file est plus rapide qu'une pile pour ajouter des sommets

]]> Erreur : les deux structures ont des opérations en temps
constant.

]]> Une pile ne peut pas contenir des sommets, seulement des nombres

]]> Erreur : une pile le peut, mais elle rendrait les derniers
découverts en premier, ce qui donne le parcours en profondeur.

]]> Les sommets sont traités dans l'ordre de leur découverte

]]> Bonne réponse : la file rend les sommets dans l'ordre où ils y
sont entrés ; un niveau entier est traité avant le suivant.

]]> Une file évite de visiter deux fois le même sommet

]]> Erreur : c'est le marquage des sommets visités qui l'évite,
avec l'une ou l'autre structure.

]]> Listes, piles, files — Q40 : Une file en liste chaînée à coût constant Comment réaliser une file avec une liste chaînée pour que
enfiler et défiler soient tous deux en temps constant ?

]]> Les deux extrémités d'une liste chaînée doivent être accessibles
directement pour obtenir une file en temps constant.

]]> 1.0 0.0 0 true true abc Ajouter en tête et retirer en tête, sans lien vers la fin

]]> Erreur : ce serait une pile, le dernier arrivé sortant le
premier.

]]> Ajouter en queue et retirer en queue, avec un lien vers la fin

]]> Erreur : ajouter et retirer du même côté donne une pile.

]]> Ajouter en tête et retirer en queue, en parcourant la liste

]]> Erreur : atteindre le dernier maillon demande de parcourir
toute la liste, le défilement coûte alors un temps linéaire.

]]> Garder un lien vers la fin, ajouter en queue, retirer en tête

]]> Bonne réponse : garder un lien vers la tête et un vers le
dernier maillon permet d'ajouter à la fin et de retirer au
début sans parcourir la liste.

]]>