$course$/QCM de NSI/Première/Recherche linéaire Recherche séquentielle d'un élément dans une liste,
parcours élément par élément, cas favorables et
défavorables, complexité, comparaison avec la recherche
dichotomique, variantes (indice, booléen, toutes les
occurrences).

]]> Recherche linéaire — Q01 : Recherche linéaire ou séquentielle En quoi consiste la recherche linéaire (ou séquentielle) ?

]]> La recherche linéaire est universelle : elle
fonctionne sur tout itérable (liste, chaîne,
tuple) sans hypothèse sur l'ordre des éléments.
Sa simplicité a un prix : elle peut nécessiter
jusqu'à n comparaisons.

]]> 1.0 0.0 0 true true abc Sauter directement à la position centrale puis comparer

]]> Erreur : c'est l'idée de la recherche
dichotomique, qui n'est applicable qu'à
une liste triée.

]]> Parcourir la liste élément par élément et comparer chaque valeur à celle recherchée

]]> Bonne réponse : c'est l'algorithme le plus
simple. Il fonctionne sur n'importe quelle
liste (triée ou non).

]]> Utiliser un dictionnaire pour aller directement à la valeur

]]> Erreur : c'est une autre stratégie (table de
hachage), différente de la recherche
linéaire.

]]> Trier la liste puis chercher le premier élément

]]> Erreur : la recherche linéaire ne nécessite
pas de tri préalable.

]]> Recherche linéaire — Q02 : Liste triée ou non ? La recherche linéaire suppose-t-elle que la liste
soit triée ?

]]> Quand la liste est triée, on peut faire mieux
avec la dichotomique (O(log n)). Mais la linéaire
reste un choix correct, simple et universel.

]]> 1.0 0.0 0 true true abc Uniquement si la liste contient des nombres

]]> Erreur : la recherche linéaire fonctionne
quel que soit le type des éléments
(nombres, chaînes, objets...).

]]> Non, elle fonctionne sur n'importe quelle liste

]]> Bonne réponse : c'est précisément l'avantage
de la recherche linéaire. On peut l'appliquer
à des données non triées (par exemple, une
liste de noms saisis dans l'ordre d'arrivée).

]]> Uniquement si la liste contient au moins 10 éléments

]]> Erreur : la recherche linéaire fonctionne
aussi sur des listes courtes ou vides.

]]> Oui, sinon elle ne fonctionne pas

]]> Erreur : c'est la dichotomique qui exige
une liste triée. La linéaire fonctionne sans
condition.

]]> Recherche linéaire — Q03 : Pire cas Quel est le nombre maximal de comparaisons dans
une recherche linéaire dans une liste de longueur n ?

]]> Pire cas : l'élément n'est pas présent. On a fait
n comparaisons négatives. Meilleur cas : l'élément
est en première position, une seule comparaison.

]]> 1.0 0.0 0 true true abc n²

]]> Erreur : on parcourt la liste une seule
fois, sans imbrication de boucle.

]]> log(n)

]]> Erreur : c'est la complexité de la recherche
dichotomique, applicable seulement aux listes
triées.

]]> n

]]> Bonne réponse : dans le pire cas (élément
absent ou en dernière position), il faut
comparer chacun des n éléments. La complexité
est en O(n).

]]> n / 2

]]> Erreur : n / 2 est le nombre moyen de
comparaisons (en supposant l'élément présent
en position aléatoire), pas le maximum.

]]> Recherche linéaire — Q04 : Quand arrête-t-on la boucle ? Dans une recherche linéaire bien programmée, quand
arrête-t-on de parcourir la liste ?

]]> Schéma Python typique :
for i, x in enumerate(liste):
if x == cible: return i
return -1.

]]> 1.0 0.0 0 true true abc Au bout de log(n) comparaisons

]]> Erreur : c'est la dichotomique. Sans
hypothèse de tri, on ne peut pas s'arrêter
avant.

]]> Dès que l'élément n'est pas trouvé

]]> Erreur : si le premier élément n'est pas le
bon, l'élément peut quand même être plus loin.

]]> Toujours après avoir parcouru toute la liste

]]> Pas optimal : si on a déjà trouvé l'élément,
inutile de continuer. Mais cela donne malgré
tout un résultat correct (juste plus lent).

]]> Dès que l'élément cherché est trouvé, ou en arrivant à la fin de la liste

]]> Bonne réponse : on s'arrête au plus tôt avec
un break ou un return. Cela améliore le
temps moyen mais ne change pas le pire cas
(élément absent, parcours complet).

]]> Recherche linéaire — Q05 : Que renvoyer si absent ? Si l'élément cherché n'est pas dans la liste,
que peut-on raisonnablement renvoyer ?

]]> Lever une exception (ValueError, comme
list.index) est aussi une option. La méthode
Python str.find renvoie -1, mais str.index
lève une exception : il existe les deux.

]]> 1.0 0.0 0 true true abc La dernière position de la liste (n - 1)

]]> Erreur : on confondrait avec « élément en
dernière position ».

]]> La position 0 (par défaut)

]]> Erreur : on confondrait avec « élément en
première position ».

]]> La longueur de la liste

]]> Erreur : valeur arbitraire, pas une
convention reconnue.

]]> None ou -1, pour signaler l'absence

]]> Bonne réponse : ce sont les deux conventions
courantes. str.find renvoie -1,
dict.get renvoie None. À la maison de
choisir, mais il faut être cohérent dans
tout le code.

]]> Recherche linéaire — Q06 : Code Python typique Quel code implémente correctement la recherche
linéaire et renvoie l'indice de la cible (ou
-1 si absente) ?

]]> Vérifier deux choses dans toute fonction de
recherche : le type de retour (indice,
booléen, ou objet), et le comportement en
cas d'absence.

]]> 1.0 0.0 0 true true abc `python
def chercher(liste, cible):
for i in range(len(liste)):
if liste[i] == cible:
return i
return -1
`

]]> Erreur d'indentation : return -1 est
dans la boucle, ce qui termine après la
première comparaison. La fonction renverrait
toujours 0 ou -1 selon le premier élément.

]]> `python
def chercher(liste, cible):
for x in liste:
if x == cible:
return x
return -1
`

]]> Erreur : on renvoie x (la valeur), pas
son indice. La spécification demandait
l'indice.

]]> `python
def chercher(liste, cible):
for i in range(len(liste)):
if liste[i] == cible:
return i
return -1
`

]]> Bonne réponse : parcours par indice, retour
précoce dès la cible trouvée, -1 si la
boucle se termine sans trouver.

]]> `python
def chercher(liste, cible):
while True:
if liste[0] == cible:
return 0
`

]]> Erreur : boucle infinie si l'élément n'est
pas en première position.

]]> Recherche linéaire — Q07 : Opérateur `in` L'expression Python 42 in liste réalise
implicitement quelle opération ?

]]> L'opérateur in cache la complexité. Sur des
gros volumes, préférer set (O(1)) à list
(O(n)) pour les tests d'appartenance répétés.

]]> 1.0 0.0 0 true true abc Un tri

]]> Erreur : in ne modifie pas la liste.

]]> Une recherche dichotomique (rapide)

]]> Erreur : Python ne suppose pas que la liste
est triée. Il fait du linéaire.

]]> Une recherche linéaire de gauche à droite, qui s'arrête dès qu'une correspondance est trouvée

]]> Bonne réponse : sur une list, in est en
O(n). Sur un set ou dict, il est en O(1)
(table de hachage).

]]> Une vérification de type

]]> Erreur : in teste l'appartenance, pas le
type.

]]> Recherche linéaire — Q08 : Liste vide Que doit renvoyer une recherche linéaire (qui
renvoie l'indice ou -1) sur une liste vide ?

]]> Cas limite à toujours tester. Bonne pratique :
écrire un test unitaire assert chercher([], x) == -1.

]]> 1.0 0.0 0 true true abc Une exception

]]> Pas nécessairement. Avec le schéma
standard, la boucle ne s'exécute pas et la
fonction renvoie -1 proprement.

]]> None

]]> Possible (autre convention), mais selon
notre énoncé, la fonction renvoie -1.

]]> -1 (élément absent)

]]> Bonne réponse : aucune valeur n'est dans la
liste vide, donc tout élément y est absent.
La boucle ne s'exécute pas, on tombe
directement sur return -1.

]]> 0

]]> Erreur : 0 signifierait « trouvé en première
position » alors qu'il n'y a aucune position.

]]> Recherche linéaire — Q09 : Recherche de minimum Trouver le minimum d'une liste est aussi un
cas de recherche linéaire. Quelle est sa
complexité ?

]]> Note importante : ici on ne peut pas s'arrêter
tôt car on ne sait pas si un élément plus
petit existe plus loin. C'est différent de la
recherche d'une valeur précise.

]]> 1.0 0.0 0 true true abc O(n²) : double boucle nécessaire

]]> Erreur : un seul parcours suffit (en gardant
le minimum courant dans une variable).

]]> O(1) : on prend juste le premier élément

]]> Erreur : le premier élément n'est pas
forcément le minimum (sauf liste triée).

]]> O(log n) : recherche dichotomique

]]> Erreur : ne fonctionne pas, même sur liste
triée la dichotomique cherche une cible
précise, pas un extremum.

]]> O(n) : on doit comparer tous les éléments

]]> Bonne réponse : pour garantir le minimum, il
faut examiner chaque élément. On ne peut
pas s'arrêter avant la fin (contrairement à
la recherche d'une cible précise).

]]> Recherche linéaire — Q10 : Trace simple On cherche cible = 7 dans liste = [3, 5, 7, 2, 7].
Combien de comparaisons effectue une recherche
linéaire avec arrêt précoce ?

]]> Sans arrêt précoce, on aurait fait 5
comparaisons et compté 2 occurrences. Avec
arrêt précoce, 3 comparaisons et indice retourné
directement (= 2).

]]> 1.0 0.0 0 true true abc 5

]]> Erreur : on ne parcourt pas toute la liste si
on s'arrête au premier 7 rencontré.

]]> 1

]]> Erreur : il faut comparer 3, puis 5 avant
d'arriver à 7.

]]> 2

]]> Erreur : il faut bien tester liste[2] (et
la trouver égale à 7) pour conclure.

]]> 3

]]> Bonne réponse : liste[0]=3 (≠), liste[1]=5
(≠), liste[2]=7 (=) → on s'arrête. Trois
comparaisons.

]]> Recherche linéaire — Q11 : Meilleur cas Quelle est la complexité dans le meilleur cas
de la recherche linéaire ?

]]> Pour une recherche d'un élément aléatoirement
placé dans la liste, la complexité moyenne
est O(n / 2), souvent simplifiée en O(n) car les
constantes sont ignorées dans la notation O.

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

]]> Bonne réponse : si l'élément cherché est en
première position, on s'arrête après une
seule comparaison.

]]> O(n²)

]]> Erreur : pas de double boucle.

]]> O(log n)

]]> Erreur : aucun mécanisme dichotomique ici.

]]> O(n)

]]> Erreur : O(n) est le pire cas.

]]> Recherche linéaire — Q12 : Variante booléenne On veut juste savoir si l'élément est présent ou
non (sans avoir besoin de l'indice). Quelle
version est la plus pythonique ?

]]> Maxime : « N'écris pas en Python ce que Python
sait déjà faire. » L'opérateur in est conçu
pour exactement ce cas.

]]> 1.0 0.0 0 true true abc `python
def present(liste, cible):
return liste.index(cible)
`

]]> Erreur : index lève ValueError si
l'élément est absent (pas un booléen).

]]> `python
def present(liste, cible):
return cible in liste
`

]]> Bonne réponse : Python a une syntaxe native
pour cela. Sous le capot, c'est exactement
la même boucle linéaire, mais le code est
plus lisible.

]]> `python
def present(liste, cible):
for x in liste:
if x == cible:
return True
return False
`

]]> Code correct, mais plus long que nécessaire.
Python offre une syntaxe plus directe.

]]> `python
def present(liste, cible):
return cible == liste
`

]]> Erreur : on compare l'élément à la liste
entière, ce qui renvoie toujours False
(sauf cas dégénéré).

]]> Recherche linéaire — Q13 : Toutes les occurrences Pour trouver toutes les positions où la cible
apparaît dans la liste, quelle adaptation de la
recherche linéaire utilise-t-on ?

]]> Code typique :
[i for i, x in enumerate(liste) if x == cible].
Élégant, en une ligne, en O(n).

]]> 1.0 0.0 0 true true abc On trie la liste avant de chercher

]]> Erreur : trier modifie l'ordre et fait perdre
les positions originales.

]]> On parcourt toute la liste et on enregistre tous les indices où l'élément correspond

]]> Bonne réponse : pas d'arrêt précoce ici, on
accumule dans une liste de résultats.
Complexité : O(n) (parcours unique).

]]> On utilise une recherche dichotomique

]]> Erreur : la dichotomique trouve une
occurrence dans une liste triée, mais ne
liste pas toutes les occurrences naturellement.

]]> On s'arrête à la première occurrence et on l'enregistre

]]> Erreur : on raterait les suivantes.

]]> Recherche linéaire — Q14 : Linéaire vs dichotomique Pour rechercher un élément dans une liste triée
de 1 000 000 d'éléments, combien de comparaisons
au pire avec chacune des deux méthodes ?

]]> log₂(2¹⁰) = 10, log₂(2²⁰) = 20. Doubler la
taille de la liste ajoute juste une
comparaison à la dichotomique, mais double les
comparaisons de la linéaire.

]]> 1.0 0.0 0 true true abc Linéaire : 1 000 000 ; dichotomique : ~ 20

]]> Bonne réponse : log₂(10⁶) ≈ 20. La
dichotomique est ~ 50 000 fois plus rapide
dans ce cas. C'est l'intérêt majeur du tri.

]]> Linéaire : 1 000 000 ; dichotomique : 1 000

]]> Erreur : la dichotomique est en O(log n),
beaucoup plus efficace.

]]> Linéaire : 1 000 ; dichotomique : 1 000 000

]]> Erreur : valeurs inversées.

]]> Les deux sont identiques

]]> Erreur : la dichotomique est exponentiellement
plus rapide sur les grandes tailles.

]]> Recherche linéaire — Q15 : Bug d'initialisation Un élève écrit
`python
def chercher(liste, cible):
for i in range(len(liste)):
if liste[i] == cible:
trouve = True
else:
trouve = False
return trouve
`
Quel est le bug ?

]]> Schéma correct : initialiser un drapeau
avant la boucle, ne le mettre à True
qu'en cas de succès. Mieux : utiliser
return True direct et return False après la
boucle.

]]> 1.0 0.0 0 true true abc return doit être à l'intérieur de la boucle

]]> Erreur : ce serait un autre code, mais ce
n'est pas la cause du bug actuel.

]]> À chaque itération, trouve est réinitialisé. Seul le résultat de la dernière comparaison est renvoyé.

]]> Bonne réponse : si la cible est trouvée puis
que la dernière itération échoue, trouve
finit à False. Solution : initialiser
trouve = False avant la boucle, et ne
faire que trouve = True à l'intérieur
(sans else).

]]> La fonction est trop lente

]]> Erreur : la performance n'est pas le
problème principal.

]]> La variable trouve n'est pas définie hors de la boucle

]]> Erreur : Python autorise (à risque) la sortie
d'une variable de boucle, tant que la
boucle s'exécute au moins une fois.

]]> Recherche linéaire — Q16 : While ou for ? Quelle est la différence pratique entre une
recherche linéaire écrite avec for et avec
while ?

]]> Bonne pratique : for pour parcourir une
structure connue ; while quand on ne sait pas
à l'avance combien d'itérations seront
nécessaires (lecture utilisateur, condition
complexe).

]]> 1.0 0.0 0 true true abc while ne fonctionne pas sur les listes

]]> Erreur : while fonctionne avec n'importe
quelle condition booléenne.

]]> for est plus lisible quand on parcourt tous les indices ; while est plus naturel pour combiner deux conditions d'arrêt (par exemple i < n and not trouve)

]]> Bonne réponse : while permet une condition
composée. for est plus concis quand on
itère simplement sur la longueur.

]]> for est plus rapide

]]> Performance équivalente. La différence est
stylistique.

]]> Les deux sont strictement équivalents en Python

]]> Sur le plan du résultat oui, sur le plan de
la lisibilité non.

]]> Recherche linéaire — Q17 : Recherche dans un dictionnaire Pourquoi la recherche d'une clé dans un
dictionnaire Python est-elle en O(1) (alors que
in liste est en O(n)) ?

]]> À retenir : liste → in en O(n) ; set ou
dict → in en O(1) en moyenne. Pour des tests
d'appartenance répétés, transformer une liste en
set est souvent payant.

]]> 1.0 0.0 0 true true abc Parce que les dictionnaires utilisent une table de hachage : la position d'une clé est calculée directement par une fonction de hachage

]]> Bonne réponse : pas besoin de parcourir, on
calcule directement l'emplacement à partir
de la clé. C'est l'avantage majeur de cette
structure.

]]> Parce que les dictionnaires sont triés

]]> Erreur : depuis Python 3.7, l'ordre
d'insertion est conservé, mais cela n'a rien
à voir avec la complexité de recherche.

]]> Parce qu'ils contiennent moins de données

]]> Erreur : un dict peut être gigantesque, sa
recherche reste en O(1).

]]> Parce que Python est un langage rapide

]]> Réponse vague et incorrecte : la rapidité
vient de la structure de données, pas
du langage.

]]> Recherche linéaire — Q18 : Optimisation par fréquence Si l'on sait qu'un élément est plus souvent
cherché que les autres, comment optimiser une
série de recherches linéaires successives ?

]]> Cette idée (« self-organizing list ») est
utilisée en pratique dans certains caches.
C'est un bon exemple où l'ordre des données
influence la performance.

]]> 1.0 0.0 0 true true abc Trier la liste par ordre croissant

]]> Le tri n'aide pas la linéaire (et coûte O(n
log n)). De plus, les éléments fréquents ne
sont pas forcément les plus petits.

]]> Doubler la taille de la liste

]]> Erreur : cela aggrave le problème.

]]> Placer les éléments les plus fréquents au début de la liste

]]> Bonne réponse : la recherche linéaire avec
arrêt précoce trouvera ces éléments plus
vite. Heuristique « move-to-front » :
déplacer chaque élément trouvé en tête.

]]> Convertir la liste en chaîne

]]> Erreur : aucun gain, et in sur une chaîne
recherche les sous-chaînes, pas les
éléments.

]]> Recherche linéaire — Q19 : Recherche dans liste de tuples Soit
eleves = [("Alice", 17), ("Bob", 16), ("Eve", 18)].
Comment trouver l'âge d'Alice ?

]]> Si l'on fait souvent ce genre de recherche,
mieux vaut convertir en dict :
{nom: age for nom, age in eleves} puis
eleves["Alice"] en O(1).

]]> 1.0 0.0 0 true true abc `python
eleves["Alice"]
`

]]> Erreur : eleves est une liste, pas un
dictionnaire. On ne peut pas l'indexer par
chaîne.

]]> `python
for nom, age in eleves:
if nom == "Alice":
return age
`

]]> Bonne réponse : on déballe chaque tuple en
deux variables, on teste le nom, on renvoie
l'âge. Recherche linéaire classique.

]]> `python
eleves.index(("Alice"))
`

]]> Erreur : ("Alice") est une chaîne (pas un
tuple ; il manque la virgule). Et même
("Alice",) ne correspond pas car le tuple
est ("Alice", 17).

]]> `python
eleves.find("Alice")
`

]]> Erreur : la méthode .find n'existe pas sur
les listes.

]]> Recherche linéaire — Q20 : Sur une chaîne L'expression "a" in "abracadabra" :

]]> Subtilité : sur une chaîne, "abc" in "ababcabc"
renvoie aussi True (sous-chaîne, pas
caractère). Sur une liste, "abc" in liste
teste l'égalité avec chaque élément.

]]> 1.0 0.0 0 true true abc Lève une exception

]]> Erreur : la syntaxe est valide.

]]> Renvoie False

]]> Erreur : "a" apparaît bien dans
"abracadabra".

]]> Renvoie le nombre d'occurrences

]]> Erreur : in renvoie un booléen, pas un
entier. Pour le comptage, utiliser .count().

]]> Renvoie True

]]> Bonne réponse : in sur une chaîne fait une
recherche de sous-chaîne (pas de
caractère unique seulement). "a" est
présent comme sous-chaîne.

]]> Recherche linéaire — Q21 : Bug : oubli du `break` `python
def trouver(liste, cible):
indice = -1
for i in range(len(liste)):
if liste[i] == cible:
indice = i
return indice
`
Quel est le comportement de cette fonction si la
cible apparaît plusieurs fois ?

]]> Cas piège mais utile : ce code peut être correct
si l'on cherche la dernière occurrence. La
version classique « première occurrence »
requiert un return i ou un break après
l'affectation.

]]> 1.0 0.0 0 true true abc Elle renvoie -1

]]> Erreur : -1 est l'initialisation, mais elle
est écrasée si une correspondance existe.

]]> Elle renvoie l'indice de la dernière occurrence

]]> Bonne réponse : la boucle continue jusqu'au
bout, et indice = i écrase la valeur à
chaque correspondance. À la fin, c'est la
dernière occurrence qui reste.

]]> Elle entre dans une boucle infinie

]]> Erreur : for sur range est borné.

]]> Elle renvoie l'indice de la première occurrence

]]> Erreur : il manque un break ou un return
pour s'arrêter à la première occurrence.

]]> Recherche linéaire — Q22 : Choisir le bon algorithme Pour rechercher un élément dans une liste de
100 éléments, non triée, qu'on ne consultera
qu'une seule fois, quelle stratégie est la plus
efficace globalement ?

]]> Règle générale : prétraiter (trier, indexer)
n'est rentable qu'au-delà d'un certain nombre
de recherches. Pour une recherche unique, la
linéaire est imbattable en simplicité.

]]> 1.0 0.0 0 true true abc Recherche linéaire directement

]]> Bonne réponse : pour une seule
recherche, la linéaire (au plus 100
comparaisons) est plus rapide que tri +
dichotomie. L'investissement du tri n'est
rentable que pour de multiples
recherches.

]]> Convertir en dictionnaire

]]> Possible mais O(n) pour construire le dict.
Pour une seule recherche, gain nul.

]]> Faire la recherche en parallèle sur 4 cœurs

]]> Sur 100 éléments, le coût de
parallélisation dépasse largement le coût
de la recherche.

]]> Trier puis dichotomie

]]> Erreur : trier coûte O(n log n) ≈ 700
opérations, plus 7 pour la dichotomie. Soit
~ 707 opérations contre 100 max pour la
linéaire. Pas rentable pour une seule
recherche.

]]> Recherche linéaire — Q23 : Boucle while à bug `python
def chercher(liste, cible):
i = 0
while liste[i] != cible:
i += 1
return i
`
Quel problème pose ce code ?

]]> Bug très classique. Pour les boucles while,
toujours vérifier deux choses : la condition
d'arrêt et l'évolution de la variable de
boucle (pour éviter une boucle infinie ou un
dépassement).

]]> 1.0 0.0 0 true true abc Aucun, le code est correct

]]> Erreur : il y a un bug majeur lié au cas
d'absence.

]]> La fonction ne renvoie jamais rien

]]> Erreur : elle renvoie i quand elle trouve
la cible.

]]> Si l'élément est absent, la boucle dépasse la fin de la liste et lève IndexError

]]> Bonne réponse : il manque la condition
i < len(liste) dans le while. Sans cela,
on accède à liste[len(liste)] qui n'existe
pas. Solution :
while i < len(liste) and liste[i] != cible:.

]]> Le code modifie la liste

]]> Erreur : aucune modification de la liste.

]]> Recherche linéaire — Q24 : Comparer en pratique Sur ma machine, une recherche linéaire dans une
liste de 1 million d'éléments prend ~ 30 ms. Que
prendra une recherche dans une liste de 1
milliard d'éléments (si la mémoire le permet) ?

]]> Compétence essentielle : savoir extrapoler le
temps d'exécution selon la complexité. La
recherche linéaire devient gênante au-delà de
quelques millions d'éléments si elle est
répétée.

]]> 1.0 0.0 0 true true abc Environ 60 ms (juste deux fois plus)

]]> Erreur : 1 milliard, c'est mille fois plus
que 1 million, pas deux fois.

]]> Environ 30 secondes (1000 fois plus, car n est multiplié par 1000)

]]> Bonne réponse : O(n) → temps proportionnel.
1 milliard / 1 million = 1000, donc 30 ms ×
1000 = 30 s. Cette estimation est précieuse
pour anticiper les performances.

]]> Environ 30 secondes au carré

]]> Erreur : ce serait O(n²), pas O(n).

]]> Toujours environ 30 ms (constante)

]]> Erreur : O(n) signifie que le temps croît
proportionnellement à n.

]]> Recherche linéaire — Q25 : Synthèse Parmi les affirmations suivantes sur la recherche
linéaire, laquelle est fausse ?

]]> Maxime : « Pas d'algorithme universellement
meilleur. » Le choix dépend des hypothèses
(liste triée ?), du nombre de recherches, et
de la taille des données.

]]> 1.0 0.0 0 true true abc En Python, l'opérateur in sur une liste fait une recherche linéaire

]]> Vrai : in sur une list est en O(n) ; il
faudrait un set ou dict pour avoir O(1).

]]> Elle fonctionne sur des listes triées comme non triées

]]> Vrai : c'est l'avantage majeur sur la
dichotomique.

]]> Sa complexité au pire est O(n)

]]> Vrai : parcours complet de la liste.

]]> Elle est toujours plus rapide que la dichotomique

]]> Faux (donc bonne réponse) : sur une liste
triée et de grande taille, la dichotomique
(O(log n)) est exponentiellement plus
rapide. La linéaire reste compétitive sur
des petites listes ou pour une recherche
unique.

]]> Recherche linéaire — Q26 : Compter les occurrences On veut compter combien de fois la cible
apparaît dans la liste (et non simplement la
trouver). Quelle adaptation de la recherche
linéaire faut-il faire ?

]]> Différence essentielle avec la recherche d'une
occurrence : on ne peut pas s'arrêter au premier
succès, donc le pire cas et le meilleur cas sont
identiques en O(n). En Python, la méthode
liste.count(cible) fait exactement cela.

]]> 1.0 0.0 0 true true abc `python
def compter(liste, cible):
for x in liste:
if x == cible:
return 1
return 0
`

]]> Erreur classique : on s'arrête à la première
occurrence et on renvoie toujours 0 ou 1, ce
qui revient à un test d'appartenance, pas à
un comptage.

]]> `python
def compter(liste, cible):
return len(liste) if cible in liste else 0
`

]]> Erreur grossière : si la cible apparaît au
moins une fois, on renvoie la longueur
totale de la liste (donc tous les éléments
sont comptés, même ceux qui ne sont pas la
cible).

]]> `python
def compter(liste, cible):
n = 0
for x in liste:
if x == cible:
n += 1
return n
`

]]> Bonne réponse : on parcourt toute la
liste sans arrêt précoce, on incrémente un
compteur à chaque correspondance. Complexité
O(n). Équivalent à liste.count(cible).

]]> `python
def compter(liste, cible):
return liste.index(cible)
`

]]> Erreur : index renvoie la position de la
première occurrence (et lève une exception
si elle est absente), pas le nombre total.

]]> Recherche linéaire — Q27 : Recherche par condition On cherche le premier élément d'une liste de
nombres qui soit strictement supérieur à
100 (et son indice). Quel code applique
correctement la recherche linéaire à ce cas ?

]]> Schéma général de la recherche linéaire par
prédicat. On peut le rendre plus pythonique
avec next : next((x for x in liste if x > 100), None).

]]> 1.0 0.0 0 true true abc `python
def premier_grand(liste):
liste.sort()
return liste[-1]
`

]]> Erreur double : on trie (ce qui modifie la
liste et coûte O(n log n)), puis on renvoie
le maximum, qui n'est pas forcément le
premier élément supérieur à 100 dans
l'ordre original.

]]> `python
def premier_grand(liste):
return max(liste) > 100
`

]]> Erreur de spécification : on demande le
premier élément supérieur à 100, pas un
booléen indiquant s'il en existe un. Et
cette version coûte O(n) sans donner
l'information utile.

]]> `python
def premier_grand(liste):
for x in liste:
if x > 100:
return x
return None
`

]]> Erreur d'indentation : return None est
dans la boucle, donc la fonction sort dès le
premier élément (qui est rarement supérieur
à 100). De plus, on ne renvoie pas l'indice.

]]> `python
def premier_grand(liste):
for i, x in enumerate(liste):
if x > 100:
return (i, x)
return None
`

]]> Bonne réponse : la recherche linéaire se
généralise à n'importe quelle condition
(prédicat). On parcourt la liste, on teste
la condition, on renvoie dès le premier
succès. Si aucun élément ne satisfait la
condition, on renvoie None.

]]> Recherche linéaire — Q28 : Recherche dans un tableau à deux dimensions On dispose d'une matrice carrée représentée par
une liste de listes (par exemple
m = [[3, 7, 1], [8, 2, 5], [4, 9, 6]]). On
cherche le couple (ligne, colonne) de la
première occurrence de la valeur 5. Quel code
est correct ?

]]> Pour une matrice non carrée, on remplace
len(m[i]) par la longueur de la ligne
courante. Avec enumerate, le code devient
plus lisible :
for i, ligne in enumerate(m): for j, x in enumerate(ligne): ....

]]> 1.0 0.0 0 true true abc `python
def chercher(m, cible):
if cible in m:
return m.index(cible)
return None
`

]]> Erreur : in m teste si la cible est l'une
des lignes de la matrice, pas l'un de
ses éléments. Ce code ne trouvera donc rien
(sauf si la cible est elle-même une liste
identique à une ligne).

]]> `python
def chercher(m, cible):
for ligne in m:
for x in ligne:
if x == cible:
return x
return None
`

]]> Erreur : on renvoie la valeur trouvée
(ce qui est trivial puisqu'on connaît
déjà la cible), pas le couple de
coordonnées demandé. Il faut utiliser
enumerate pour récupérer les indices.

]]> `python
def chercher(m, cible):
for i in range(len(m)):
if m[i] == cible:
return i
return None
`

]]> Erreur : on compare une ligne entière à
la cible (un nombre), ce qui sera toujours
faux. On confond élément de la matrice et
ligne.

]]> `python
def chercher(m, cible):
for i in range(len(m)):
for j in range(len(m[i])):
if m[i][j] == cible:
return (i, j)
return None
`

]]> Bonne réponse : double boucle imbriquée pour
parcourir lignes et colonnes, retour
précoce dès la cible trouvée. Pour la
matrice donnée, on renvoie (1, 2).
Complexité O(L × C) où L est le nombre de
lignes et C le nombre de colonnes.

]]>