rojets informatiques

Projet de programmation - OMI1C9 (ENSAE)

Les exercices présentent la logique de la programmation mais la pratique est la

seule véritable façon de progresser. La plupart des élèves qui n’avaient pas ou peu
programmé avec ce projet ont noté une réelle différence avant et après. Ci-dessous,
quelques phrases extraites de rapports d’étudiants et qui traduiront mieux que je
ne pourrais le faire les étapes par lesquelles on passe dans ce type d’aventure.

Extraits des projets informatiques de première année à l’ENSAE en 2015

Sujets proposés

Travail attendu

Que faut-il en attendre ?

Références

Ce que vous ne lisez jamais mais que j’observe chaque année

Erreurs de design fréquentes

Façons d’écrire du code lent

Oublis dans le rapport

Maladresses lors de la soutenance

Sujets proposés

Les sujets proposés abordent différents domaines connexes aux enseignements

proposés à l’ENSAE (finance, statistique, économie) et quelques jeux. Tous les
projets proposés sont des suggestions, les élèves sont libres d’élaborer un sujet
de leur choix ou de s’inspirer des énoncés ci-dessous à la condition de le faire
valider par un encadrant. Afin d’avoir un premier suivi productif, il est conseillé
de parcourir les références bibliographiques suggérées. C’est souvent l’occasion de
découvrir un sujet que vous ne verrez pas ou peu à l’ENSAE. Par genre :

Algorithmes de trading
Data en folie
Algorithmes génétiques, Fourmis
Jeux de réflexion
Jeux de cartes
Jeux de réflexion qui se jouent seul
Jeux mathématiques
Machine Learning
Sécurité, Cryptographie
Automatisation, Objets connectés, Reconnaissance
Simulations économiques, sociales

Liste exhaustive :

ML algo : Apprentissage par renforcement

ML algo : Algorithme de Chow-Liu

ML algo : Reconnaissance des visages de ses amis

 ML algo : Deep et Extreme Machine Learning

ML algo : Alignement de mots dans l’optique de constuire un traducteur

automatique

ML algo : Fast k-NN (2016)

ML algo : Accélération de la descente de gradient dans le cadre d’une

optimisation convexe (2016)

ML algo : Ecrire une librairie pour représenter des modèles de machine learning
(2018)

Jeu 1 : 2048

Jeu 1 : Voronoï solo

Jeu 1 : Puzzle GCHD (2016)

Jeu 1 : Tetris (2018)

ML : Inférer les trajectoirs de vélo vélib

ML : Nuages de mots, extraction de concepts

ML : Twitter

ML : Recherche de texte dans n’importe quelle base de données avec Whoosh

ML : Régression à base de plus proches voisins (2017)

ML : Construction d’un estimateur du caractère éthique d’un moteur de recherche

(2017)

ML : Détection de fumée dans les images (2017)

ML : Implémenter un SNN : Spiking Neural Network (2018)

ML : Implémenter un algorithme des plus proches voisins amélioré (2018)

Finance : Trend following

Finance : Optimisation de portefeuille

Finance : Pair trading

Finance : Machine learning et trading

Simulation : Simuler la ségégation sociale

Simulation : Simulation d’une foule en panique

Simulation : Simuler l’évolution d’un réseau social

Simulation : Pourquoi la ligne 13 est-elle surchargée ? (2016)

Objets connectés : Application smartphone

 Objets connectés : Domotique

Objets connectés : Expressions du visages en temps réel (2017)

Objets connectés : Reconnaissance de la parole en temps réel et BOT (2017)

Objets connectés : Mon Skype à moi (2019)

Algo génétique : Optimisation à partir d’algorithmes génétiques

Algo génétique : Problème du sac-à-dos et algorithmes génétiques

Algo génétique : Problème du voyageur de commerce et algorithme génétique

Algo génétique : Colonie de fourmis et plus court chemin

Algo génétique : Recherche de motifs

Jeu 2 : Awalé

Jeu 2 : Echec

Jeu 2 : Go

Jeu 2 : Gomoku

Jeu 2 : Othello

Jeu 2 : Pai Sho (2016)

Jeu 2 : Puissance 4

Jeu 2 : Pokémon (2016)

Jeu 2 : Tic Tac Toe 9x9 (2016)

Algo : Ondes Wifi

Algo : Pentomino

Algo : Recherche exacte d’un motif, d’une expression

Algo : Recherche approximative d’un motif, d’une expression

Algo : Problème du voyageur de commerce

Algo : Problème des tournées de véhicules

Algo : Construction d’une texture

Algo : Simulation d’une loi statistique avec un algorithme d’optimisation A*

Algo : Recalage d’un réseau

Algo : Structure de données adaptée à la recherche de palindromes

Algo : Implémentation d’une grammaire probabiliste pour traiter le langage

naturel
 Algo : Distance entre deux arbres : Robinson–Foulds (2016)

Algo : Résolution de systèmes d’inéquations (2016)

Algo : Elaboration d’un clavier (2017)

Algo : Impression 3D (2018)

Algo : Détection de période dans les séquences qui préservent l’ordre (2018)

Jeu hasard : Poker

Jeu hasard : Belotte

Travail attendu

Le projet dure quatre mois au second semestre (de février à mai). Il se conclut par
un programme et un rapport. Une soutenance suit mi-juin. Le rapport doit souligner
la contribution originale des élèves, illuster les résultats numériques obtenus et
la façon dont ils ont été obtenus. On suppose que le rapport s’adresse à un public
expert. La soutenance doit reprendre les points principaux, décrire brièvement la
façon dont le travail a été réparti au sein de l’équipe.

Chaque projet, quelque soit le sujet, devra comporter une composante numérique
(statistique, économique, financière, …), que ce soit une stratégie de trading,
l’optimisation d’une intelligence artificielle pour un jeu, une simulation
économique. Cet aspect devra ressortir lors de la rédaction du rapport final qui
devra exposer les résultats numériques obtenus et faire au moins une ou deux
allusions à la façon dont ces calculs ont été implémentés. Le rapport doit contenir
les éléments suivants :

instructions pour exécuter le programme

description d’un point de design de code

description d’un algorithme du programme et son coût

description d’une difficulté qui vous a fait perdre beaucoup de temps (hors
celles liées à votre apprentissage de la programmation)

description d’une contribution originale

description des résultats obtenus

prolongements et applications envisageables

Le code rendu doit contenir au moins un test unitaire. Voir 1A.soft Tests
unitaires, setup et ingéniérie logiciel (correction).

Ces remarques sont plus un guide qu’un plan précis. Je vous encourage à voir cet
extrait de film bien connu The Pirate code.

D’une manière générale, il faut penser un rapport comme un document qui se lie
consciencieusement une fois puis qui se relie plusieurs fois rapidement pour
retrouver ce qu’on cherche, cela veut dire des graphiques complets lisibles sans
trop de contexte, une conclusion explicite qui rappelle les résultats et le
contexte d’exploitation de ceux-ci.
Que faut-il en attendre ?
Vous serez plus autonome. Vous n’aurez plus l’assurance qu’une solution existe ni
même quelqu’un qui vous donnera la réponse tout de suite si vous ne trouvez pas.
Vous devrez parfois vous interroger sur les résultats numériques que vous avez
obtenus et qui sont si loin de votre intuition qu’ils cachent sans doute une erreur
d’implémentation. Vous devrez vous-même définir le problème et y répondre. Cela
veut dire parfois aussi faire un compromis entre ce que vous rêvez de faire et le
temps que vous avez pour le faire. Si vous travailler à deux, vous découvrirez
qu’il n’est pas toujours évident de se synchroniser. Heureusement, les outils ont
beaucoup progressé ces dix dernières années. Un projet informatique s’effectue le
plus souvent sur le long terme. Vous verrez que si on fait une pause de quelques
semaines dans un projet, on oublie beaucoup de petits détails qu’on redécouvre aux
détours d’une exception. Mais là encore, il existe des solutions. Le plus important
sans doute, programmer veut aussi dire être créatif. Pour finir, voici ce qu’en ont
retiré les élèves de première année en 2015 : Extraits des projets informatiques de
première année à l’ENSAE en 2015.
Références

Articles de blogs

Deux ou trois choses à vérifier avant de rendre un projet informatique

Récupérer des données financières

Travailler à plusieurs sur le même projet informatique

Quelques précisions sur les projets informatiques

Python extensions to do machine learning

Frameworks for games in Python

Ideas for making better conference talks & conferences (2016/06)

Resources

données

Source de données.

bibliographie

Barème indicatif des projets informatiques (année 2012-2013)

Barème indicatif des projets informatiques (année 2013-2014)

Ce que vous ne lisez jamais mais que j’observe chaque année

Erreurs de design fréquentes

Ce ne sont pas à proprement parler des erreurs car elles n’altèrent pas l’exécution
du programme. Toutefois elles le rendent plus difficile à lire et à corriger en cas
d’une vraie erreur. La plupart des développeurs les font lorsqu’ils apprennent à
programmer et ne les font plus par la suite.

Un seul gros fichier

Chaque année, je vois plusieurs projets informatiques implémenter en un seul gros

fichier. C’est sans doute dû au fait que, lorsqu’on travaille à deux ou trois, il
est plus facile de s’échanger un seul fichier que plusieurs. Je remarque d’ailleurs
que les « groupes » d’un élève font créent plus souvent plusieurs fichiers.
Lorsqu’on développe un jeu, il est préférable de séparer la partie affiche de la
partie intelligence artificielle, il est encore mieux de les mettre dans deux
fichiers séparés. La partie IA sera considéré comme un module et la partie
affichage comme le programme principal.

Pour éviter l’envoi continu de mail entre deux membres du même groupe, le meilleur
recours est l’emploi d’un logiciel de suivi de source. GitHub est une possibilité.
C’est celle que j’utilise pour développer ce cours : sdpython/ensae_teaching_cs.
Cela permet de suivre les modifications (un commit), ou de revenir en arrière.

Le copier/coller de plus de 10 lignes pour changer un caractère

Je schématise un peu. Concrètement, lorsqu’on programme un jeu à deux joueurs, on

fait des choses pour le premier joueur dans un bloc de code qu’on recopie pour
l’autre joueur avec quelques modifications subtiles

if joueur == 1 :
next_joueur = 2
proba_1[eta_succ[U-1]]=1
proba_2[eta_succ[U-1]]=0
proba_2[eta_succ[U-2]]=0
proba_1[sym(eta_succ[U-1])]=1
proba_2[sym(eta_succ[U-1])]=0
proba_2[sym(eta_succ[U-2])]=0
else :
next_joueur = 1
proba_2[eta_succ[U-1]]=1
proba_1[eta_succ[U-1]]=0
proba_1[eta_succ[U-2]]=0
proba_2[sym(eta_succ[U-1])]=1
proba_1[sym(eta_succ[U-1])]=0
proba_1[sym(eta_succ[U-2])]=0

Ceci est à éviter le plus possible. Cela allonge inutilement les programmes mais
surtout cela oblige développeur à répercuter une modification sur tous les blocs
recopiés. Et on se trompe souvent. Dans ce cas précis, il est facile d’écrire

if joueur == 1 :
pr1,pr2 = proba_1,proba_2
else :
pr1,pr2 = proba_2,proba_1

next_joueur = 3 - next_joueur
pr1[eta_succ[U-1]]=1
pr2[eta_succ[U-1]]=0
pr2[eta_succ[U-2]]=0
pr1[sym(eta_succ[U-1])]=1
pr2[sym(eta_succ[U-1])]=0
pr2[sym(eta_succ[U-2])]=0

Et si on est vraiment pointilleux

pr1,pr2 = proba_1,proba_2 if joueur == 1 else proba_2,proba_1

next_joueur = 3 - next_joueur
eu_1 = eta_succ[U-1]
seu_1 = sym(eta_succ[U-1])
pr1[eu_1]=1
pr2[eu_1]=0
pr2[eta_succ[U-2]]=0
pr1[seu_1]=1
pr2[seu_1]=0
pr2[sym(eta_succ[U-2])]=0

Les variables globales

Elles sont pratiques :

On y met les paramètres d’une simulation ou l’état d’un jeu de poker.

On n’a pas besoin de les transmettre comme paramètres à chaque fonction.

Ce choix simple peut devenir ennuyeux par la suite lorsqu’on souhaite faire tourner
plusieurs le même programme en changeant ces variables globales. Pour éviter cela,
le plus simple est de créer une classes qui les contient toutes et de passer une
instance de cette classe à chaque fonction qui en a besoin

class VariablesGlobales :
def __init__(self):
self.epsilon = 0.01
self.alpha = 0.5
self.iter = 1000
# ...

variable = VariablesGlobales ()

def fonction_qui_en_a_besoin( varglob) :

s = varglob.alpha
for i in range(0,varglob.iter):
# ...

Façons d’écrire du code lent

if if if if

if x == 1:
r = 0
if x == 2:
r = 1

Le second if porte sur une condition qui n’a aucune chance d’être vérifiée si la
première l’est. Il faut utiliser elif.

if x == 1:
r = 0
elif x == 2:
r = 1

sort à la place d’un top k

def deux_meilleures_options(l):
l.sort()
return l[0:2]

Trier toute une liste pour n’extraire que deux éléments est plus coûteux que
nécessaire même si c’est simple à coder.
def deux_meilleures_options(l):
ens = ((v, i) for i, v in enumerate(l))
return min(ens)[0], min(ens[1:])[0]

Appel de fonction inutile

def mean_vector(x):
return sum(x) / len(x)

if mean_vector(x)[0] < mean_vector(x)[1]:

# ...

Le test appelle deux fois la fonction mean_vector avec les mêmes paramètres. Le
résultat sera forcément identique.

def mean_vector(x):
return sum(x) / len(x)

v = mean_vector(x)
if v[0] < v[1]:
# ...

deepcopy inutile

def enumerate_transposition(li):
for i in range(1, len(li)):
cl = copy.deepcopy(li)
cl[0], cl[i] = li[i], li[0]
yield cl

Est-il vraiment nécessaire de faire une copie la liste ? Autant ne pas le faire et
l’indiquer dans la documentation.

def enumerate_transposition(li):
"""
the function does not return a copy,
do not modify the returned list
"""
for i in range(1, len(li)):
li[0], li[i] = li[i], li[0]
yield li
li[0], li[i] = li[i], li[0]

langue

Si vous hésitez entre l’anglais et le français, préférez l’anglais.

Oublis dans le rapport

Le code qu’on a jeté

Lorsqu’on fait un projet de la sorte, il arrive souvent qu’on jette du code qu’on a
écrit. On découvre parfois que le programme tel qu’il est conçu ne permet pas de
faire tel ou tel chose, il faut en réécrire une partie. On écrit parfois du code
jetable lorsqu’on a besoin d’un résultat numérique. Une fois celui-ci obtenu, on
l’intègre au programme et on jette le code qui a permis de l’obtenu.

C’est parfois utile dans votre rapport de décrire ces codes jetés. Dans le premier
cas, le code jeté sert de justification au nouveau. Dans le second cas, cela
rassure de voir que certains résultats ne sortent pas de nulle part.

Qu’avez-vous appris ?

Certaines conclusions mentionnent le fait qu’on apprend beaucoup à faire un projet

informatique, seul, sans aide extérieure. On apprend autant que durant des séances
de travaux pratiques. C’est un des objectifs de l’exercice : apprendre à maîtriser
cet outil qu’est la programmation. Mais il n’est pas utile de préciser cela dans le
rapport.

Mais ce projet demande aussi une part d’imagination, que ce soit pour concevoir une
fonction d’évaluation pour une intelligence artificielle, une simulation économique
réaliste, une stratégie financière… Tout au long de la mise en place de ses idées,
on s’aperçoit que les premiers jets sont parfois un peu naïf, que les premiers
résultats numériques ne sont pas aussi bons qu’escomptés. Il faut retravailler
l’idée initiale. Cette partie doit ressortir dans votre rapport et elle doit bien
ressortir.

Qu’est-ce que le lecteur va retenir ?

Expliquer les choses, les illustrer, choisir le bon graphique, le bon tableau, pour
défendre une idée n’est pas toujours simple. Il faut parfois imaginer qu’un rapport
sera lu deux fois, une fois en diagonale, une autre plus sérieusement.

Il faut se poser la question de savoir ce que vous voulez que le lecteur retienne.

Un programme informatique est d’autant plus difficile à cerner qu’il est long. Le
rapport est la version la plus accessible de votre travail. C’est le point de
départ. A partir de là, on navigue plus aisément dans votre programme.

La phrase suivante est librement inspirée d’un rapport à propos d’un jeu :

On choisit finalement la première intelligence artificielle mais en choisissant

cette fois-ci de bons paramètres.

De cette phrase, je comprends que certains paramètres ont été optimisés mais le
rapport ne revient jamais sur cet aspect. Donc :

Je dois deviner quelle partie du programme a servi à cela, si toutefois le

code est encore là. Je vois bien un fichier qui correspond mais il ne marche pas
(ou plus). Je ne suis pas sûr d’avoir envie de le débugger.

Je ne sais pas quels sont ces paramètres, je n’ai aucune idée des résultats
obtenus, ni même que la différence de niveau entre les bons paramètres et les
mauvais.

Je comprends qu’un travail d’optimisation a été effectué mais je n’ai

aucune idée de l’importance qu’il revêt. Si le rapport n’en fait pas mention, c’est
sans doute que cela n’est qu’une contribution minime.

Un exemple ou une copie d’écran

Les copies d’écran est indispensable pour une interface graphique ou un site web.
Le résultats de vos algorithmes doit être illustrés sur au moins un exemple qui
fonctionne et, si cela a du sens, un autre qui ne fonctionne pas.

Imprécision

Je paraphrase :
 On a comparé les deux intelligences artificielles en jouant contre elles, la
seconde est meilleure.

Et en chiffres ?
Maladresses lors de la soutenance

Court transparent, grand discours

Lorsqu’on a beaucoup de choses à dire, on prend le risque de noyer l’auditoire sans

pouvoir lui rappeler au cours de ce discours les idées importantes qu’il devrait
retenir. Un transparent part souvent d’une intention lorsqu’on crée la
présentation. Devant le public, on s’aperçoit que l’intention est plus complexe
qu’il n’y paraît. C’est à ce moment qu’il faut faire attention à ne pas noyer ceux
qui écoutent. Il ne faut pas hésiter alors à écrire au tableau les idées
importantes même si elles n’étaient pas écrites initialement sur la présentation.
Le pire est sans doute de rester plus de deux minutes sur le même transparent tout
en exposant des idées insufisamment préparées dont la perception est le plus
souvent confuse.

Suivre le plan du rapport

Il faut partir du principe que la soutenance s’adresse à un public non expert qui
n’a probablement pas lu votre rapport. Selon ce critère, suivre le même plan que le
rapport ne devrait sans doute pas poser de problème. Un bémol : en suivant le même
plan que le rapport, on a parfois tendance à reproduire le même discours sans
vraiment chercher à l’adapter à ce moyen d’expression.

Tout dire

La soutenance est courte et impose souvent de faire un tri sur tout ce que vous
voulez présenter. Le plus souvent, l’auditoire n’est pas un expert et quand bien
même il le serait, la plupart des présentations abordent des sujets complexes qu’il
est difficile d’appréhender en quelques minutes. Vous n’avez pas l’occasion de
démontrer la pertinence des résultats, il y a toujours une forme de confiance qui
s’établit entre celui qui expose et celui qui écoute. Car à la fin, pour les
derniers résultats, les plus intéressants, le public n’a pas d’autres choix que de
croire celui qui les énonce. Il est impossible de les vérifier sur le moment.

Comment installer cette relation de confiance ? Il n’y a pas de règles, juste

quelques directions comme montrer comment un algorithme se comporte sur un problème
simple, montrer comment l’algorithme s’est construit peu à peu en considérant
quelques exemples précis, insister sur le fait que vous avez contrôlé chaque étape
du développement et laisser l’auditoire supposer que vous avez appliqué la même
rigueur jusqu’à l’obtention des résultats finaux. Au cinéma, cette figure s’appelle
une ellipse (voir aussi L’ellipse - leçon (filmée) de cinéma).

Déduction rapide

Beaucoup de groupes tirent des conclusions de peu d’expérimentations : une

simulation n’est pas une preuve mathématique, et il faut répéter plusieurs fois la
même simulation pour une avoir une certitude statistique.

Dernière mise à jour : 2019-08-08.