$course$/QCM de NSI/Terminale/Programmation dynamique Sous-problèmes recouvrants, sous-structure optimale,
mémoïsation descendante, tabulation ascendante,
exemples classiques (suite de Fibonacci, plus longue
sous-séquence commune, sac à dos, distance d'édition,
rendu de monnaie).

]]> Programmation dynamique — Q01 : Idée centrale de la programmation dynamique Quel est le principe fondamental de la
programmation dynamique ?

]]> Le terme « programmation » dans « programmation
dynamique » vient de l'optimisation linéaire
(Bellman, années $1950$), et non de la
programmation informatique. Il signifie « plan,
tableau », ce qui justifie la notion de
tabulation.

]]> 1.0 0.0 0 true true abc Diviser le problème en deux moitiés et résoudre chacune indépendamment

]]> Cette description correspond au paradigme
« diviser pour régner ». La différence
essentielle est que les sous-problèmes y sont
disjoints, alors qu'en programmation
dynamique ils se recouvrent.

]]> Faire à chaque étape le choix qui semble localement le meilleur

]]> Cette description correspond au principe des
algorithmes gloutons. La programmation
dynamique, au contraire, explore toutes les
possibilités de manière organisée, en
mémorisant les solutions des sous-problèmes.

]]> Modifier le programme à mesure qu'il s'exécute

]]> Cette description évoque l'auto-modification
de code, qui n'a aucun rapport avec la
programmation dynamique. Le mot
« dynamique » désigne ici le caractère
temporel de la décision, pas une
modification du programme.

]]> Mémoriser les solutions des sous-problèmes pour ne pas avoir à les recalculer

]]> La programmation dynamique exploite la
présence de sous-problèmes qui se répètent
dans la décomposition récursive. En les
mémorisant, on évite la croissance
exponentielle du nombre de recalculs.

]]> Programmation dynamique — Q02 : Mémoïsation Qu'est-ce que la mémoïsation ?

]]> Le mot « mémoïsation » associe les idées de
mémoire et de récursivité. C'est l'approche
« descendante » de la programmation dynamique :
on part du problème complet, on descend dans les
sous-problèmes en mémorisant les résultats au
passage.

]]> 1.0 0.0 0 true true abc La comparaison de deux algorithmes pour choisir le plus rapide

]]> Cette opération relève de la mesure de
performance, et n'a aucun rapport avec la
mémoïsation.

]]> La conversion automatique d'une fonction récursive en boucle itérative

]]> Cette transformation s'appelle la
dérécursivation, et c'est une technique
différente. La mémoïsation conserve la
structure récursive de la fonction, en y
ajoutant simplement un cache.

]]> La compression d'un programme en mémoire pour gagner de la place

]]> La mémoïsation n'a aucun rapport avec la
taille du programme. Elle concerne le
temps de calcul, en évitant de
recalculer plusieurs fois la même valeur.

]]> Le stockage des résultats déjà calculés dans un cache pour les réutiliser

]]> À chaque appel récursif, l'algorithme
vérifie si le résultat est déjà connu
(typiquement dans un dictionnaire ou un
tableau) avant de le calculer. Si la valeur
est déjà disponible, elle est renvoyée
directement.

]]> Programmation dynamique — Q03 : Tabulation Qu'appelle-t-on tabulation en programmation
dynamique ?

]]> La mémoïsation et la tabulation sont les deux
faces de la programmation dynamique : la
mémoïsation est descendante (récursive, avec un
cache) ; la tabulation est ascendante
(itérative, avec un tableau). En pratique, la
tabulation est souvent plus rapide, car elle
évite le surcoût des appels récursifs.

]]> 1.0 0.0 0 true true abc Le découpage d'un problème en sous-problèmes égaux

]]> Cette description correspond au paradigme
« diviser pour régner ». La tabulation
consiste à remplir un tableau ; elle ne
découpe pas le problème.

]]> La création d'une table HTML pour afficher les résultats

]]> La « tabulation » dans ce contexte
algorithmique n'a aucun rapport avec une
mise en forme HTML. Il s'agit du
remplissage progressif d'un tableau de
valeurs.

]]> Une optimisation des comparaisons utilisée dans un algorithme de tri

]]> La tabulation est spécifique à la
programmation dynamique. Elle n'a pas de
rôle particulier dans les algorithmes de
tri.

]]> La construction d'un tableau de résultats, en partant des plus petits sous-problèmes pour aller vers les plus grands

]]> C'est l'approche dite « ascendante » : on
part des cas de base et on remplit
progressivement un tableau, sans aucune
récursion.

]]> Programmation dynamique — Q04 : Suite de Fibonacci en programmation dynamique Quelle est la complexité de la suite de Fibonacci
calculée avec mémoïsation ?

]]> Le passage de $O(2^n)$ à $O(n)$ pour la suite
de Fibonacci est l'exemple canonique de la
puissance de la programmation dynamique. Pour
$n = 50$, on passe ainsi de plus d'un million
d'appels à seulement $51$.

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

]]> La programmation dynamique appliquée à
Fibonacci ne nécessite qu'un parcours
linéaire des valeurs, et non une double
itération qui justifierait une complexité
quadratique.

]]> $O(\log n)$

]]> Avec la récurrence $f(n) = f(n-1) + f(n-2)$,
on ne peut pas descendre en dessous de la
complexité linéaire avec une mémoïsation
standard. Une complexité logarithmique
existe, mais elle requiert des techniques
plus avancées (comme l'exponentiation
matricielle).

]]> $O(2^n)$

]]> Cette complexité correspond à la version
récursive naïve, sans mémoïsation. Le
recours à un cache réduit drastiquement ce
coût.

]]> $O(n)$

]]> Avec mémoïsation, chaque valeur
$\text{fib}(k)$ pour $k$ allant de $0$ à
$n$ n'est calculée qu'une seule fois, ce
qui donne $n$ calculs au total.

]]> Programmation dynamique — Q05 : Sous-problèmes recouvrants Que signifie « le problème a des sous-problèmes
recouvrants » ?

]]> Cette propriété est essentielle pour que la
programmation dynamique soit utile. Si les
sous-problèmes sont uniques, la mémoïsation
n'apporte rien et on retombe sur le paradigme
« diviser pour régner » classique.

]]> 1.0 0.0 0 true true abc Les sous-problèmes ont tous la même solution

]]> Les sous-problèmes peuvent avoir des
solutions très différentes, ce qui est
d'ailleurs le cas le plus courant. Le
caractère recouvrant signifie qu'ils
apparaissent plusieurs fois dans
l'arbre des appels récursifs, et non qu'ils
partagent leur solution.

]]> Les sous-problèmes sont triés par taille décroissante

]]> L'ordre dans lequel on considère les
sous-problèmes n'a rien à voir avec leur
caractère recouvrant. Le mot « recouvrant »
renvoie à la notion de doublon, pas
d'ordre.

]]> Les sous-problèmes sont indépendants les uns des autres

]]> Si les sous-problèmes étaient indépendants,
on appliquerait plutôt le paradigme
« diviser pour régner ». La programmation
dynamique exploite précisément le contraire.

]]> Plusieurs sous-problèmes peuvent apparaître plus d'une fois dans la décomposition récursive

]]> C'est le cas typique de la suite de
Fibonacci, où la valeur $\text{fib}(k)$ est
calculée plusieurs fois dans la version
naïve. La programmation dynamique évite
précisément ces recalculs.

]]> Programmation dynamique — Q06 : Sous-structure optimale Que signifie « le problème possède une
sous-structure optimale » ?

]]> La sous-structure optimale et le caractère
recouvrant des sous-problèmes sont les deux
ingrédients qui rendent un problème adapté à la
programmation dynamique. Sans la première, on
ne peut pas combiner les solutions ; sans la
seconde, la mémoïsation ne sert à rien.

]]> 1.0 0.0 0 true true abc La taille des sous-problèmes diminue de manière logarithmique

]]> Cette description évoque la diminution
logarithmique du paradigme « diviser pour
régner » équilibré, mais elle ne correspond
pas à la définition de la sous-structure
optimale.

]]> La solution optimale du problème global est constituée des solutions optimales aux sous-problèmes

]]> Cette propriété permet de construire la
solution optimale en combinant les solutions
optimales des sous-problèmes. C'est elle qui
rend la programmation dynamique applicable.

]]> Le problème peut être résolu en parallèle sur plusieurs processeurs

]]> La sous-structure optimale est une propriété
mathématique du problème, et non une
caractéristique algorithmique. Le
parallélisme relève de l'implémentation.

]]> Les sous-problèmes ont tous la même taille

]]> Cette uniformité de taille n'est pas
requise. La sous-structure optimale parle de
la composition des solutions, pas des
tailles des sous-problèmes.

]]> Programmation dynamique — Q07 : Programmation dynamique et algorithme glouton Quelle est la différence principale entre un
algorithme glouton et un algorithme de
programmation dynamique ?

]]> Quand un problème possède la propriété de
choix glouton (un choix local mène à
l'optimum global), un algorithme glouton suffit
et reste plus efficace. Sinon, la programmation
dynamique est souvent nécessaire pour
atteindre l'optimum.

]]> 1.0 0.0 0 true true abc L'algorithme glouton fait un choix local optimal sans revenir en arrière, tandis que la programmation dynamique explore toutes les possibilités via les sous-problèmes

]]> L'algorithme glouton est plus rapide mais
peut manquer l'optimum global. La
programmation dynamique est plus coûteuse,
mais elle garantit l'optimum global lorsque
le problème possède la sous-structure
optimale.

]]> L'algorithme glouton est récursif, alors que la programmation dynamique est itérative

]]> Les deux approches peuvent être implémentées
aussi bien récursivement qu'itérativement.
C'est le principe qui les distingue, et
non leur forme syntaxique.

]]> La programmation dynamique est utilisée uniquement pour les jeux vidéo

]]> La programmation dynamique a un champ
d'application très large : alignement de
séquences, optimisation économique,
traitement automatique du langage, et bien
d'autres domaines.

]]> L'algorithme glouton ne fonctionne que sur les graphes

]]> Les algorithmes gloutons s'appliquent à de
très nombreux types de problèmes : rendu de
monnaie, planification d'activités, sac à
dos fractionnaire, et bien d'autres.

]]> Programmation dynamique — Q08 : Structure de mémoïsation Quelle structure Python convient le mieux pour
mémoïser une fonction prenant un seul paramètre
entier positif ?

]]> Pour des paramètres entiers, la liste est
idéale. Pour des paramètres plus complexes
(chaînes, $p$-uplets, objets), le dictionnaire
devient nécessaire. Python propose aussi le
décorateur @functools.lru_cache, qui
automatise tout cela.

]]> 1.0 0.0 0 true true abc Une liste indexée par la valeur du paramètre

]]> Pour des paramètres entiers positifs dans
une plage connue, une liste donne un accès
en $O(1)$ très efficace. C'est la structure
la plus rapide.

]]> Un fichier sur le disque

]]> Le disque est beaucoup trop lent pour de la
mémoïsation en mémoire. Il s'utiliserait
plutôt pour persister un cache entre deux
exécutions du programme.

]]> Un dictionnaire avec les paramètres comme clés

]]> Un dictionnaire fonctionne, mais avec un
surcoût lié au calcul des empreintes. Pour
des indices entiers, la liste reste plus
rapide.

]]> Une variable globale unique

]]> Une seule variable ne peut stocker qu'une
seule valeur, alors que la mémoïsation
demande d'en mémoriser plusieurs.

]]> Programmation dynamique — Q09 : Origine du terme Le terme « programmation dynamique » a été
introduit en $1953$ par :

]]> Bellman a expliqué qu'il avait choisi le terme
« dynamique » pour évoquer le caractère
temporel de la décision, et « programmation »
au sens de planification. L'équation de Bellman
reste aujourd'hui un outil central en
optimisation et en apprentissage par
renforcement.

]]> 1.0 0.0 0 true true abc Tim Berners-Lee

]]> Tim Berners-Lee est l'inventeur du World
Wide Web. Son travail n'a aucun rapport
avec la programmation dynamique.

]]> Alan Turing

]]> Alan Turing est principalement connu pour
la machine de Turing et le décryptage
d'Enigma, mais pas pour la programmation
dynamique.

]]> Donald Knuth

]]> Donald Knuth est connu pour son traité
monumental « The Art of Computer
Programming », mais ce n'est pas lui qui
est à l'origine de la programmation
dynamique.

]]> Richard Bellman

]]> Richard Bellman a inventé la programmation
dynamique pour traiter des problèmes
d'optimisation séquentielle. Le mot
« programmation » vient du jargon militaire
de l'époque, dans le sens de
« planification ».

]]> Programmation dynamique — Q10 : Exemple classique de programmation dynamique Lequel des problèmes suivants se résout
typiquement par programmation dynamique ?

]]> Autres exemples typiques : sac à dos, plus
longue sous-séquence commune, distance
d'édition, plus longue sous-suite croissante,
rendu de monnaie. Tous ont en commun la
sous-structure optimale et les sous-problèmes
recouvrants.

]]> 1.0 0.0 0 true true abc Tester si un nombre est premier

]]> Les tests de primalité ne se prêtent pas à
la programmation dynamique, car ils ne font
pas apparaître naturellement de
sous-problèmes recouvrants.

]]> Inverser une chaîne de caractères

]]> C'est une opération en $O(n)$ qui ne
requiert aucune mémoïsation. Aucune
décomposition en sous-problèmes ne
s'impose.

]]> Trier un tableau

]]> Les algorithmes de tri usuels (tri par
insertion, par sélection, par fusion) ne
relèvent pas de la programmation
dynamique.

]]> Calculer le plus court chemin dans un graphe pondéré

]]> L'algorithme de Bellman-Ford repose sur la
programmation dynamique. Il exploite la
sous-structure optimale : le plus court
chemin de A à C contient un plus court
chemin de A à B, pour tout sommet B
intermédiaire.

]]> Programmation dynamique — Q11 : Mémoïsation manuelle de Fibonacci On écrit la fonction suivante :

memo = {}
def fib(n):
    if n in memo:
        return memo[n]
    if n <= 1:
        return n
    memo[n] = fib(n - 1) + fib(n - 2)
    return memo[n]

Combien d'appels effectifs (qui calculent
réellement, sans utiliser le cache) sont
effectués pour fib(10) ?

]]> La mémoïsation transforme la complexité
$O(2^n)$ en $O(n)$ : c'est un gain
algorithmique considérable. Le code reste
pourtant très proche de la version récursive
naïve.

]]> 1.0 0.0 0 true true abc Exactement un

]]> Il faut bien calculer chaque valeur
intermédiaire au moins une fois. La
mémoïsation évite les recalculs, pas les
calculs initiaux.

]]> Environ onze

]]> Chaque valeur fib(0), fib(1), ...,
fib(10) est calculée une seule fois grâce
au cache. Les appels suivants sur une
valeur déjà calculée sont satisfaits
immédiatement par memo.

]]> Plus de mille

]]> Cet ordre de grandeur correspond à la
version sans mémoïsation. Avec un cache,
le nombre de calculs est bien plus
modeste.

]]> Environ cent

]]> C'est trop. Le nombre de valeurs distinctes
à calculer est seulement $n + 1$, soit
$11$, et non $n^2$.

]]> Programmation dynamique — Q12 : Tabulation pour Fibonacci Quelle est la version tabulée (itérative) de
la suite de Fibonacci ?

]]> L'approche tabulée évite la récursion et le
cache. Pour Fibonacci, on peut même optimiser
l'espace en ne gardant que les deux dernières
valeurs : a, b = b, a + b.

]]> 1.0 0.0 0 true true abc

def fib(n):
    return round((1.618 ** n) / 2.236)

]]> Cette formule est celle de Binet, qui
utilise le nombre d'or. Elle ne relève pas
de la programmation dynamique et devient
imprécise pour de grandes valeurs de $n$ à
cause des arrondis sur les flottants.

]]>

def fib(n):
    t = [0, 1]
    for i in range(2, n + 1):
        t.append(t[i-1] + t[i-2])
    return t[n]

]]> On remplit un tableau t de taille $n + 1$
en partant des cas de base ($t[0] = 0$ et
$t[1] = 1$), puis on construit les valeurs
suivantes par récurrence. La complexité
est $O(n)$ en temps comme en espace.

]]>

def fib(n):
    if n <= 1: return n
    return fib(n-1) + fib(n-2)

]]> Il s'agit de la version récursive naïve,
sans mémoïsation ni tabulation. Sa
complexité est $O(2^n)$.

]]>

def fib(n):
    return n * (n - 1) / 2

]]> Cette formule donne la somme des entiers
de $0$ à $n - 1$, et non la suite de
Fibonacci.

]]> Programmation dynamique — Q13 : Problème du sac à dos Le problème du sac à dos $0/1$ consiste à
choisir un sous-ensemble d'objets à mettre dans
un sac de capacité fixée pour maximiser leur
valeur totale. Quelle est sa complexité en
programmation dynamique avec un sac de
capacité $W$ et $n$ objets ?

]]> La complexité $O(nW)$ est dite
pseudo-polynomiale : elle est polynomiale
en la valeur de $W$, mais exponentielle en
sa taille en bits. Le sac à dos reste donc
un problème difficile en taille d'entrée
stricte.

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

]]> Aucune raison particulière n'amène à une
complexité factorielle pour ce problème.

]]> $O(n)$

]]> Il faut considérer chaque objet pour chaque
capacité possible du sac. La complexité
dépend nécessairement des deux paramètres.

]]> $O(2^n)$

]]> Cette complexité correspond à l'approche
par recherche exhaustive (essayer tous les
sous-ensembles d'objets). La programmation
dynamique est bien plus rapide.

]]> $O(n \cdot W)$

]]> On remplit un tableau à deux dimensions de
taille $n \times W$. Pour chaque case, le
calcul est en $O(1)$. La complexité totale
est donc $O(nW)$.

]]> Programmation dynamique — Q14 : Sac à dos : comparer les deux approches Pour le problème du sac à dos $0/1$,
l'algorithme glouton qui prend les objets par
ordre décroissant du ratio « valeur / poids »
donne-t-il toujours la solution optimale ?

]]> Le sac à dos $0/1$ ne possède pas la
propriété de choix glouton. Il faut donc
explorer plusieurs possibilités, ce que fait la
programmation dynamique en $O(nW)$, à comparer
aux $O(2^n)$ de la recherche exhaustive.

]]> 1.0 0.0 0 true true abc L'algorithme glouton est plus rapide mais moins précis

]]> Il s'agit ici d'optimum exact, pas
d'approximation. Soit l'algorithme garantit
l'optimum, soit il ne le garantit pas. Il
n'y a pas de notion de précision
intermédiaire.

]]> Non, l'algorithme glouton peut manquer l'optimum dans le cas $0/1$

]]> Pour le sac à dos $0/1$, l'algorithme
glouton peut être trompé. Avec un sac de
capacité $50$ et les objets
$\{(60, 10), (100, 20), (120, 30)\}$
(valeur, poids), l'algorithme glouton prend
$(120, 30)$ en premier, alors que la
combinaison optimale est
$(60, 10) + (100, 20)$, pour une valeur
totale supérieure.

]]> Oui, c'est l'algorithme correct pour ce problème

]]> Cette approche gloutonne est optimale pour
le sac à dos fractionnaire (où l'on
peut couper un objet), mais pas pour la
version $0/1$, où chaque objet est pris
entièrement ou pas du tout.

]]> Cela dépend du langage de programmation utilisé

]]> La propriété est purement mathématique. Elle
ne dépend pas du langage choisi pour
l'implémentation.

]]> Programmation dynamique — Q15 : Approche descendante et approche ascendante Quelle est la différence entre l'approche
descendante et l'approche ascendante en
programmation dynamique ?

]]> L'approche descendante (mémoïsation) est plus
naturelle quand la définition du problème est
récursive. L'approche ascendante (tabulation)
est en général plus économe en mémoire et plus
rapide en pratique. Le choix dépend du
contexte.

]]> 1.0 0.0 0 true true abc L'approche descendante est récursive avec mémoïsation, l'approche ascendante est itérative avec tabulation

]]> L'approche descendante part du problème
global et descend dans les sous-problèmes,
en utilisant un cache. L'approche
ascendante part des cas de base et
construit progressivement la table des
résultats jusqu'au problème global.

]]> L'approche descendante concerne les graphes, l'approche ascendante concerne les listes

]]> Les deux approches s'appliquent à toutes
les structures de données. La distinction
n'a rien à voir avec le type des éléments
manipulés.

]]> L'approche descendante est toujours plus rapide

]]> En pratique, l'approche ascendante est
souvent plus rapide, car elle évite le
surcoût des appels récursifs. La complexité
asymptotique est cependant la même dans les
deux cas.

]]> Aucune, ces termes sont synonymes

]]> Ce sont deux approches distinctes, même si
elles permettent toutes deux de résoudre
les mêmes problèmes.

]]> Programmation dynamique — Q16 : Le décorateur `lru_cache` en Python En Python, quel décorateur de la bibliothèque
functools automatise la mémoïsation d'une
fonction ?

]]> Le sigle LRU signifie « Least Recently
Used », soit « le moins récemment utilisé ».
Le cache stocke un nombre limité de résultats
($128$ par défaut, ou un nombre illimité avec
maxsize=None) et expulse les moins
récemment consultés.

]]> 1.0 0.0 0 true true abc @dynamic

]]> Ce décorateur n'existe pas dans la
bibliothèque standard de Python.

]]> @cache_me

]]> Ce nom de décorateur n'existe pas en
Python. Le décorateur attendu se trouve
dans le module functools.

]]> @lru_cache

]]> Le décorateur
@functools.lru_cache(maxsize=None) ajoute
automatiquement un cache à n'importe
quelle fonction. C'est très pratique pour
des fonctions récursives, sans avoir à
coder soi-même la mémoïsation.

]]> @memoize

]]> Le décorateur @memoize n'est pas dans la
bibliothèque standard. Certaines
bibliothèques tierces le proposent, mais le
standard Python est lru_cache.

]]> Programmation dynamique — Q17 : Rendu de monnaie en programmation dynamique Pour le rendu de monnaie avec un système de
pièces arbitraire, la programmation dynamique
calcule, en $O(n \cdot s)$ (où $s$ est la somme
à rendre et $n$ le nombre de pièces) :

]]> Le rendu de monnaie est l'exemple emblématique
d'un problème où l'algorithme glouton échoue
sur certains systèmes monétaires (par exemple
$\{1, 3, 4\}$), alors que la programmation
dynamique garantit l'optimum.

]]> 1.0 0.0 0 true true abc La somme totale rendue

]]> La somme à rendre est donnée en entrée du
problème, elle n'est pas calculée par
l'algorithme.

]]> Le nombre minimal de pièces nécessaires pour atteindre la somme

]]> Pour chaque sous-somme $k \in [0, s]$,
l'algorithme calcule le nombre minimal de
pièces nécessaires. La récurrence utilisée
est
$\text{ND}(k) = 1 + \min_{p}\, \text{ND}(k - p)$,
où $p$ parcourt les pièces disponibles.

]]> La pièce la plus grande utilisée

]]> Cette description correspond plutôt à
l'approche gloutonne, qui choisit toujours
la plus grande pièce disponible.

]]> Une séquence ordonnée de pièces

]]> La programmation dynamique calcule un
nombre minimal, et non une séquence
ordonnée. La séquence des pièces
effectivement utilisées peut être
reconstruite ensuite, par un parcours à
rebours du tableau.

]]> Programmation dynamique — Q18 : Programmation dynamique et diviser pour régner En quoi la programmation dynamique se
distingue-t-elle du paradigme « diviser pour
régner » classique ?

]]> Pour identifier si un problème relève de la
programmation dynamique, on peut tracer
l'arbre des appels récursifs et chercher les
nœuds dupliqués. S'il y en a beaucoup, la
programmation dynamique est probablement le
bon outil.

]]> 1.0 0.0 0 true true abc Le paradigme « diviser pour régner » utilise toujours la récursivité, contrairement à la programmation dynamique

]]> Les deux paradigmes peuvent utiliser la
récursivité. La programmation dynamique
peut aussi être itérative (par tabulation),
mais ce n'est pas la différence
essentielle.

]]> La programmation dynamique ne s'applique qu'aux problèmes portant sur des entiers

]]> La programmation dynamique s'applique à
tout problème possédant les deux propriétés
requises (sous-structure optimale et
sous-problèmes recouvrants), quel que soit
le type des données manipulées.

]]> La programmation dynamique est plus simple à coder

]]> C'est subjectif et souvent l'inverse. Les
algorithmes de type « diviser pour régner »
sont en général plus simples à concevoir.

]]> En programmation dynamique, les sous-problèmes se recouvrent ; en « diviser pour régner », ils sont disjoints

]]> C'est la distinction fondamentale. Sans
recouvrement, la mémoïsation n'apporte
rien. Avec recouvrement, elle apporte des
gains majeurs.

]]> Programmation dynamique — Q19 : Compromis mémoire et temps La programmation dynamique illustre un
compromis classique en algorithmique. Lequel ?

]]> Pour la suite de Fibonacci, la version naïve a
une complexité en $O(2^n)$ en temps avec
$O(n)$ d'espace de pile. La version mémoïsée
passe à $O(n)$ en temps avec $O(n)$ de mémoire :
on a légèrement augmenté l'espace, mais on a
divisé le temps par un facteur exponentiel.

]]> 1.0 0.0 0 true true abc Moins de mémoire consommée et moins de temps de calcul

]]> Il n'y a pas de gain gratuit. Ne stocker
aucune valeur intermédiaire reviendrait au
cas naïf récursif, qui est précisément
beaucoup plus lent.

]]> Plus de mémoire consommée, en échange de beaucoup moins de temps de calcul

]]> On stocke les solutions intermédiaires
(mémoire en plus) pour ne plus avoir à les
recalculer (temps en moins). C'est un
compromis central en algorithmique.

]]> Aucun changement par rapport à l'algorithme naïf

]]> La programmation dynamique apporte un gain
majeur sur de nombreux problèmes (suite de
Fibonacci, sac à dos, plus longue
sous-séquence commune, etc.).

]]> Plus de temps de calcul mais moins de mémoire consommée

]]> C'est exactement l'inverse. La
programmation dynamique consomme plus de
mémoire, mais elle accélère
considérablement le calcul.

]]> Programmation dynamique — Q20 : Lecture d'une programmation dynamique ascendante Que calcule la fonction Python suivante ?

def f(n):
    T = [0] * (n + 1)
    T[0] = 1
    for i in range(1, n + 1):
        T[i] = T[i-1] * i
    return T[n]

]]> Cet exemple illustre une programmation
dynamique ascendante très simple : on
remplit un tableau en partant du cas de base.
C'est l'archétype de la tabulation pour une
récurrence simple.

]]> 1.0 0.0 0 true true abc La factorielle $n!$

]]> On a $T[i] = T[i-1] \cdot i = i!$, en
partant de $T[0] = 1 = 0!$. La fonction
renvoie donc bien $n!$, par construction
ascendante.

]]> La $n$-ième valeur de la suite de Fibonacci

]]> La suite de Fibonacci utiliserait
l'instruction T[i] = T[i-1] + T[i-2],
fondée sur une addition de deux termes
précédents, et non sur la multiplication
par $i$.

]]> $2^n$

]]> Pour obtenir $2^n$, il faudrait écrire
T[i] = T[i-1] 2 plutôt que
T[i-1] i.

]]> La somme $1 + 2 + \cdots + n$

]]> Une somme s'obtiendrait par addition. Or
la fonction effectue une multiplication
(T[i-1] * i), qui correspond à un
produit cumulé.

]]> Programmation dynamique — Q21 : Plus longue sous-séquence commune Pour calculer la plus longue sous-séquence
commune à deux chaînes de longueurs $m$ et $n$,
la programmation dynamique a une complexité
de :

]]> Cet algorithme est utilisé en bio-informatique
(alignement de séquences ADN), dans le
versionnage de fichiers (commande diff), en
reconnaissance vocale, et dans bien d'autres
domaines. La complexité quadratique reste
raisonnable même pour des chaînes de plusieurs
milliers de caractères.

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

]]> On construit un tableau à deux dimensions
de taille $m \times n$. Pour chaque case,
le calcul est en $O(1)$. La complexité
totale est donc $O(mn)$.

]]> $O(m^2 + n^2)$

]]> La complexité de ce problème est
multiplicative dans les deux longueurs, et
non additive sur leurs carrés.

]]> $O(m + n)$

]]> Cette complexité linéaire correspondrait à
un simple parcours conjoint des deux
chaînes. Or il faut explorer les
combinaisons possibles, ce qui demande un
coût supérieur.

]]> $O(2^{m+n})$

]]> Cette complexité exponentielle correspond
à l'approche par recherche exhaustive
(essayer toutes les sous-séquences). La
programmation dynamique réduit ce coût à
un produit polynomial.

]]> Programmation dynamique — Q22 : Piège du paramètre par défaut mutable Dans une mémoïsation manuelle, on écrit :

def f(n, memo={}):
    if n in memo: return memo[n]
    if n <= 1: return n
    memo[n] = f(n-1, memo) + f(n-2, memo)
    return memo[n]

Quel problème pose le memo={} placé en
paramètre par défaut ?

]]> La bonne pratique consiste à utiliser
memo=None puis, à l'intérieur de la
fonction, if memo is None: memo = {}. On peut
aussi recourir à @functools.lru_cache, qui
gère ces subtilités automatiquement.

]]> 1.0 0.0 0 true true abc Il est partagé entre tous les appels successifs de la fonction, conservant les valeurs entre exécutions différentes

]]> Python évalue les valeurs par défaut
une seule fois, à la définition de la
fonction. Le dictionnaire memo est donc
partagé. Cela peut être souhaité (cache
global) ou provoquer des bugs subtils si
l'on attendait un cache neuf à chaque
appel.

]]> Il rend la fonction trop lente, car le dictionnaire est recréé à chaque appel

]]> C'est l'inverse. Le dictionnaire par
défaut est créé une seule fois (à la
définition de la fonction), ce qui est
précisément le piège.

]]> Il ralentit globalement Python

]]> Aucun ralentissement global. Le seul
problème est le partage non intentionnel
du cache entre les appels.

]]> Il provoque une erreur de récursion

]]> Aucune erreur de récursion n'est causée par
un paramètre mutable par défaut. Le piège
est sémantique, et ne se manifeste pas par
une erreur d'exécution.

]]> Programmation dynamique — Q23 : Reconstruire la solution En programmation dynamique, on calcule souvent
une valeur optimale (par exemple le coût
minimal). Comment retrouve-t-on la solution
effective, c'est-à-dire la séquence de
décisions qui mène à cet optimum ?

]]> Cette technique de reconstruction à rebours
est universelle en programmation dynamique :
après avoir rempli la table, on retrace les
choix faits à chaque étape pour reconstruire
la solution complète.

]]> 1.0 0.0 0 true true abc On ne peut pas, la programmation dynamique ne donne que la valeur optimale

]]> La solution effective peut tout à fait
être reconstruite : c'est ce qui rend la
programmation dynamique utile dans les
applications réelles.

]]> On lance plusieurs programmations dynamiques avec différents paramètres pour identifier les choix

]]> Cette approche serait inefficace. Une seule
exécution suffit, à condition de bien lire
la table à rebours.

]]> On la reconstruit en parcourant la table à rebours, à partir de la valeur finale

]]> On remonte dans la table en suivant les
choix qui ont mené à chaque valeur
optimale. Cela permet de retrouver la
séquence de décisions sans alourdir le
calcul lui-même.

]]> On stocke aussi la solution dans la table

]]> C'est possible mais coûteux en mémoire, et
souvent inutile : la solution se
reconstruit toujours en $O(n)$ après le
calcul, par un parcours à rebours.

]]> Programmation dynamique — Q24 : Optimisation de l'espace Pour calculer la suite de Fibonacci en $O(n)$
en temps avec une mémoire réduite, on peut
écrire :

a, b = 0, 1
for _ in range(n):
    a, b = b, a + b

Quelle est la complexité en mémoire de
cette version ?

]]> Cette optimisation est très courante. Pour de
nombreuses récurrences (suite de Fibonacci,
sac à dos selon une dimension, etc.), on peut
éviter de stocker toute la table en ne
conservant que les valeurs strictement
nécessaires.

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

]]> On ne stocke que deux variables, a et
b, durant tout le calcul. Aucun tableau
de taille $n$ n'est utilisé.

]]> $O(n^2)$

]]> Aucune raison n'amène à une mémoire
quadratique pour ce calcul.

]]> $O(1)$

]]> Seules deux variables suffisent. C'est
l'optimisation classique : quand la
récurrence ne dépend que des $k$ valeurs
précédentes (ici $k = 2$), on peut réduire
l'espace à $O(k)$, soit une mémoire
constante.

]]> $O(\log n)$

]]> Aucune structure logarithmique n'est
utilisée ici, simplement deux variables.

]]> Programmation dynamique — Q25 : Reconnaître un problème de programmation dynamique Pour qu'un problème se résolve efficacement par
programmation dynamique, il doit posséder :

]]> Ces deux propriétés sont l'identité de la
programmation dynamique. Sans la sous-structure
optimale, il est impossible de combiner les
solutions. Sans le recouvrement des
sous-problèmes, la mémoïsation est inutile, et
l'on retombe sur le paradigme « diviser pour
régner » classique.

]]> 1.0 0.0 0 true true abc Une décomposition logarithmique du problème

]]> Cette caractéristique correspond plutôt au
paradigme « diviser pour régner »
classique. Ce n'est pas un prérequis de la
programmation dynamique.

]]> Un seul cas de base et une seule récurrence

]]> Le nombre de cas de base ou de récurrences
n'est pas un critère. Ce sont les
propriétés structurelles du problème qui
comptent.

]]> Une fonction objectif uniquement minimale

]]> La programmation dynamique s'applique aussi
à des problèmes de maximisation (sac à dos,
plus longue sous-séquence) ou de comptage
(nombre de chemins).

]]> La sous-structure optimale et des sous-problèmes recouvrants

]]> Ces deux propriétés sont nécessaires. La
sous-structure optimale permet de combiner
les solutions, et les sous-problèmes
recouvrants rendent la mémoïsation utile.

]]> Programmation dynamique — Q26 : Chemins dans une grille On veut compter le nombre de chemins
monotones (n'allant qu'à droite ou en bas)
d'un coin d'une grille rectangulaire de $m$
lignes et $n$ colonnes au coin opposé. Quelle
est la récurrence appropriée et la complexité
par programmation dynamique ?

]]> Ce problème est l'un des plus simples
illustrant la programmation dynamique sur une
table à deux dimensions. La même technique
s'étend aux variantes (cases bloquées,
sommes minimales, etc.).

]]> 1.0 0.0 0 true true abc $C(i, j) = C(i-1, j) + C(i, j-1)$ avec
$C(0, j) = C(i, 0) = 1$, complexité
$O(m \cdot n)$

]]> Bonne réponse : pour atteindre la case
$(i, j)$, on vient soit du dessus
$(i-1, j)$ soit de la gauche $(i, j-1)$.
Les cas de base sont les bords, où il
n'existe qu'un seul chemin (descente ou
déplacement à droite uniquement). On
remplit un tableau à deux dimensions de
taille $m \times n$, chaque case en
$O(1)$, donc complexité totale
$O(m \cdot n)$.

]]> $C(i, j) = C(i-1, j-1) + 1$, complexité
$O(m \cdot n)$

]]> Erreur : la récurrence proposée ne
correspond pas au problème. On ne peut se
déplacer qu'à droite ou vers le bas,
pas en diagonale. La récurrence correcte
additionne les chemins venant de la case
du dessus et de la case de gauche.

]]> $C(i, j) = C(i-1, j) \cdot C(i, j-1)$,
complexité $O(m + n)$

]]> Erreur : pour compter le nombre de
chemins, on additionne les
possibilités, on ne les multiplie pas. La
complexité est aussi sous-estimée :
remplir un tableau à deux dimensions
coûte $O(m \cdot n)$, pas $O(m + n)$.

]]> $C(i, j) = i + j$, calcul direct en
$O(1)$

]]> Erreur : le nombre de chemins n'est pas la
somme des coordonnées mais bien le
coefficient binomial $\binom{i+j}{i}$. Une
formule fermée existe, mais elle se
calcule en $O(\min(i, j))$ multiplications,
pas en temps constant.

]]> Programmation dynamique — Q27 : Distance d'édition La distance d'édition (ou distance de
Levenshtein) entre deux chaînes mesure le
nombre minimal d'opérations
(insertion, suppression, substitution) pour
transformer l'une en l'autre. Quel est le
schéma de programmation dynamique pour la
calculer ?

]]> La distance d'édition est l'algorithme central
de la commande diff, des correcteurs
orthographiques, et de la bio-informatique
(alignement de séquences). C'est un exemple
type de programmation dynamique sur une
table à deux dimensions.

]]> 1.0 0.0 0 true true abc $D(i, j) = \max(i, j)$, calcul en $O(1)$

]]> Erreur grossière : ce serait dire que la
distance d'édition est toujours la
longueur de la chaîne la plus longue. Or
deux chaînes identiques ont une distance
de zéro, et la formule donnée n'en tient
pas compte.

]]> $D(i, j) = D(i-1, j-1)$ si les deux
derniers caractères sont égaux ; sinon,
$D(i, j) = 1 + \min(D(i-1, j),
D(i, j-1), D(i-1, j-1))$. Complexité
$O(m \cdot n)$

]]> Bonne réponse : trois opérations possibles
se traduisent par trois récurrences
(suppression, insertion, substitution),
plus le cas où les caractères coïncident.
Cas de base : $D(0, j) = j$ et
$D(i, 0) = i$. La complexité est
quadratique, ce qui reste praticable pour
des chaînes de quelques milliers de
caractères.

]]> On compare uniquement les premiers
caractères des deux chaînes. Complexité
$O(1)$

]]> Erreur : la distance d'édition prend en
compte toutes les positions, pas
seulement la première. Une approche
$O(1)$ ne donnerait évidemment pas le
résultat correct.

]]> $D(i, j) = D(i-1, j-1) + 1$ dans tous les
cas. Complexité $O(\min(m, n))$

]]> Erreur : cette récurrence ne traite pas
séparément le cas où les caractères
coïncident (gratuit). Elle ignore aussi
les opérations d'insertion et de
suppression, qui modifient la longueur
des chaînes. Le résultat serait
systématiquement faux.

]]> Programmation dynamique — Q28 : Trace sur le rendu de monnaie Avec les pièces $\{1, 3, 4\}$ et la somme à
rendre $s = 6$, quel est le nombre minimal
de pièces calculé par programmation dynamique
(et l'écart avec la méthode gloutonne qui
prend toujours la plus grosse pièce
possible) ?

]]> Cet exemple est emblématique : il prouve
qu'avec un système monétaire arbitraire,
l'algorithme glouton n'est plus optimal. Avec
les systèmes monétaires usuels (euros,
dollars), l'algorithme glouton fonctionne
grâce à des propriétés structurelles
particulières des dénominations choisies.

]]> 1.0 0.0 0 true true abc La programmation dynamique trouve $1$
pièce, l'algorithme glouton en trouve $2$

]]> Erreur : aucune pièce de valeur $6$
n'existe dans le système monétaire
$\{1, 3, 4\}$, donc une pièce ne peut pas
suffire. Le minimum atteignable est de
deux pièces (combinaison $3 + 3$).

]]> La programmation dynamique et l'algorithme
glouton trouvent tous deux $3$ pièces

]]> Erreur : si c'était le cas, la
programmation dynamique n'aurait aucun
intérêt sur ce problème. Refaire le
calcul : avec $3 + 3$, deux pièces
suffisent, ce que l'algorithme glouton
rate.

]]> Les deux échouent car aucune combinaison
ne donne $6$

]]> Erreur : la combinaison $3 + 3 = 6$ est
parfaitement valide. De même
$1 + 1 + 4 = 6$ ou $1 + 1 + 1 + 3 = 6$
fonctionnent. Le problème est résoluble.

]]> La programmation dynamique trouve $2$
pièces (la combinaison $3 + 3$), tandis
que l'algorithme glouton en utilise $3$
(la combinaison $4 + 1 + 1$)

]]> Bonne réponse : c'est l'exemple
pédagogique classique où la stratégie
gloutonne échoue à atteindre l'optimum.
Glouton : prendre $4$, reste $2$, prendre
$1$, prendre $1$, total $3$ pièces.
Programmation dynamique : explore toutes
les combinaisons et trouve $3 + 3 = 6$,
soit seulement $2$ pièces. Cas
paradigmatique de l'intérêt de la
programmation dynamique.

]]> Programmation dynamique — Q29 : Trace du sac à dos On dispose d'un sac de capacité $W = 5$ et de
trois objets : $O_1$ (poids $2$, valeur $3$),
$O_2$ (poids $3$, valeur $4$), $O_3$ (poids
$4$, valeur $5$). Quelle est la valeur
optimale obtenue par programmation
dynamique ?

]]> Construire le tableau $V$ à la main est un
excellent exercice. Il révèle que la
programmation dynamique « teste » toutes les
combinaisons utiles sans en énumérer
explicitement aucune. Pour reconstruire la
solution (les objets choisis), on remonte
dans le tableau à rebours en regardant
pour chaque case quelle décision a mené à
l'optimum.

]]> 1.0 0.0 0 true true abc $12$ (en prenant les trois objets)

]]> Erreur : prendre les trois objets pèse
$2 + 3 + 4 = 9 \mathrm{kg}$, bien
au-delà de la capacité du sac. C'est la
difficulté du sac à dos : on doit
renoncer à des objets précieux à cause
de la contrainte de poids.

]]> $7$ (en prenant $O_1$ et $O_2$, poids
total $5$, valeur totale $7$)

]]> Bonne réponse : on construit la table
$V[i][w]$ donnant la valeur optimale en
considérant les $i$ premiers objets pour
une capacité $w$. Quelques valeurs clés :
$V[2][5] = \max(V[1][5], V[1][2] + 4)$
$= \max(3, 3 + 4) = 7$. À l'arrivée
$V[3][5] = \max(V[2][5], V[2][1] + 5)$
$= \max(7, 0 + 5) = 7$. La solution
optimale prend $O_1$ ($2 \mathrm{kg}$,
$3$) et $O_2$ ($3 \mathrm{kg}$, $4$),
poids total $5$, valeur totale $7$.

]]> $5$ (en prenant uniquement $O_3$)

]]> Erreur : prendre seulement $O_3$ ne donne
que $5$ de valeur, alors que la
combinaison $O_1 + O_2$ donne $7$ pour
un poids identique au sac (capacité
atteinte exactement). Il vaut donc mieux
prendre les deux petits objets que le
gros.

]]> $9$ (en prenant $O_2$ et $O_3$)

]]> Erreur : la combinaison $O_2$ + $O_3$
pèse $3 + 4 = 7 \mathrm{kg}$, ce qui
dépasse la capacité $W = 5$ du sac.
Cette solution n'est donc pas réalisable.

]]> Programmation dynamique — Q30 : Code du sac à dos en programmation dynamique Quel code Python implémente correctement la
programmation dynamique ascendante (par
tabulation) pour le sac à dos $0/1$ avec $n$
objets de poids poids[i] et valeurs
valeurs[i] et un sac de capacité W ?

]]> Complexité : $O(n \cdot W)$ en temps et en
espace. Optimisation possible : ne conserver
que la ligne courante et la précédente,
ramenant l'espace à $O(W)$. Pour
reconstruire la solution effective, on
remonte le tableau de la case $V[n][W]$ vers
la case $V[0][0]$, en notant à chaque
étape si l'objet $i$ a été pris.

]]> 1.0 0.0 0 true true abc

def sac_a_dos(poids, valeurs, W):
    total = 0
    for i in range(len(poids)):
        total += valeurs[i]
    return total

]]> Erreur : ce code retourne la somme de
toutes les valeurs sans tenir compte
de la contrainte de poids. Il
renverrait par exemple $12$ pour le cas
de la question précédente, alors que
la vraie réponse est $7$.

]]>

def sac_a_dos(poids, valeurs, W):
    n = len(poids)
    V = [[0] * (W + 1) for _ in range(n + 1)]
    for i in range(1, n + 1):
        for w in range(W + 1):
            if poids[i-1] <= w:
                V[i][w] = max(V[i-1][w],
                              V[i-1][w-poids[i-1]] + valeurs[i-1])
            else:
                V[i][w] = V[i-1][w]
    return V[n][W]

]]> Bonne réponse : on construit un tableau à
deux dimensions de taille
$(n+1) \times (W+1)$. Pour chaque case
$(i, w)$ : si l'objet $i$ rentre dans le
sac (poids[i-1] <= w), on prend le
maximum entre « ne pas le prendre »
(V[i-1][w]) et « le prendre »
(V[i-1][w-poids[i-1]] + valeurs[i-1]) ;
sinon, on ne peut pas le prendre. Indices
$i-1$ car les listes Python commencent
à $0$.

]]>

def sac_a_dos(poids, valeurs, W):
    # Tri par ratio valeur/poids décroissant
    ordre = sorted(range(len(poids)),
                   key=lambda i: -valeurs[i]/poids[i])
    total = 0
    capa = W
    for i in ordre:
        if poids[i] <= capa:
            total += valeurs[i]
            capa -= poids[i]
    return total

]]> Erreur : c'est l'algorithme glouton par
ratio valeur/poids. Il est optimal pour
le sac à dos fractionnaire (où l'on
peut couper des objets), mais pas pour
la version $0/1$. Il peut renvoyer une
valeur sous-optimale, comme on l'a vu
dans la question précédente.

]]>

def sac_a_dos(poids, valeurs, W):
    return max(valeurs)

]]> Erreur : ce code renvoie la valeur de
l'objet le plus précieux, sans même
vérifier qu'il rentre dans le sac. Et
surtout, il ignore les combinaisons
d'objets, qui sont souvent meilleures.

]]> Programmation dynamique — Q31 : Mesurer le gain de la mémoïsation On compare le calcul de fibonacci(40) avec
la version récursive naïve et avec la
version mémoïsée. Quel est l'ordre de
grandeur du rapport entre les deux
complexités ?

]]> Cet exemple illustre la puissance de la
programmation dynamique. Bien sûr, pour
Fibonacci en pratique, on utilise plutôt la
version itérative à deux variables, qui a
la même complexité $O(n)$ mais avec une
consommation mémoire $O(1)$ au lieu de
$O(n)$.

]]> 1.0 0.0 0 true true abc Les deux versions ont la même complexité
asymptotique

]]> Erreur : la mémoïsation change
fondamentalement la complexité. La
version naïve calcule plusieurs fois
les mêmes valeurs (par exemple,
$\mathrm{fib}(35)$ est calculée
plusieurs millions de fois) ; la
mémoïsée ne calcule chaque valeur qu'une
seule fois.

]]> La version mémoïsée est environ deux fois
plus rapide

]]> Erreur : un facteur deux serait une
amélioration mineure. Or le passage de
$O(2^n)$ à $O(n)$ représente un gain
exponentiel, pas multiplicatif. Pour
$n = 40$, c'est un facteur de plus de
dix milliards.

]]> La version mémoïsée est plus lente à
cause du surcoût du cache

]]> Erreur : pour $n$ aussi petit que $20$,
le surcoût du cache est négligeable
devant le gain en évitant les calculs
redondants. Pour $n = 40$, le gain est
colossal.

]]> La version mémoïsée est environ
$10^{10}$ fois plus rapide

]]> Bonne réponse : version naïve en
$O(2^n)$, soit environ
$2^{40} \approx 10^{12}$ appels
récursifs. Version mémoïsée en $O(n)$,
soit environ $40$ appels effectifs. Le
rapport est donc d'environ
$10^{12} / 40 \approx 2{,}5 \cdot 10^{10}$.
En pratique, on passe de plusieurs
minutes à une fraction de milliseconde.

]]> Programmation dynamique — Q32 : Optimisation de l'espace pour le sac à dos Le sac à dos en programmation dynamique
utilise par défaut un tableau $V$ de taille
$(n+1) \times (W+1)$, soit un espace
$O(n \cdot W)$. Comment réduire cet
espace à $O(W)$ tout en gardant la même
complexité en temps ?

]]> Compromis : la réduction à $O(W)$ permet de
traiter des sacs à dos avec des capacités
$W$ très grandes (typiquement plusieurs
millions), au prix de la perte d'information
pour reconstruire la solution. Si on a
besoin des deux (faible mémoire et
reconstruction), des techniques plus
avancées existent, comme le « partage par le
milieu » qui combine deux passes sur des
moitiés du tableau.

]]> 1.0 0.0 0 true true abc On observe que pour calculer la ligne
$V[i]$, on n'a besoin que de la ligne
$V[i-1]$. On peut donc se contenter de
deux lignes (la précédente et la
courante), voire d'une seule en
parcourant les capacités de droite à
gauche

]]> Bonne réponse : c'est une optimisation
classique. La récurrence ne dépend que
de la ligne précédente, donc deux
tableaux de taille $W+1$ suffisent.
Mieux : avec un seul tableau parcouru à
rebours (

for w in range(W, poids[i]-1,

-1)

), on garantit qu'on utilise bien
l'ancienne valeur de $V[w-poids[i]]$
avant qu'elle ne soit écrasée par la
ligne en cours. Espace final : $O(W)$.

]]> On utilise un dictionnaire au lieu d'un
tableau

]]> Erreur : un dictionnaire peut éviter de
stocker des cases inutilisées (avec une
mémoïsation paresseuse), mais dans le
pire cas, on stocke toujours $O(n
\cdot W)$ entrées. Le gain n'est pas
systématique.

]]> On ne peut pas réduire l'espace en
dessous de $O(n \cdot W)$

]]> Erreur : la réduction à $O(W)$ est
possible et constitue une optimisation
standard. Elle est cependant payée par
la perte de la trace permettant de
reconstruire la solution effective :
si l'on n'a plus que la ligne courante,
on ne peut plus remonter dans le
tableau à rebours.

]]> On compresse les valeurs avec un
algorithme de compression

]]> Erreur : la compression peut réduire la
taille en mémoire d'un facteur constant,
mais ne change pas la complexité
asymptotique. L'optimisation correcte
est structurelle : ne stocker que ce
qui est utile pour le calcul courant.

]]>