tronc commun algo/algo approfondie
This commit is contained in:
gwen
parent
898dc77569
commit
a0040a3b00
@ -1,291 +1 @@
|
||||
Algorithmique
|
||||
=============
|
||||
|
||||
Al-Kharezmi, auteur du traité "Kitab al jabr w'al-muqabala", est l'inventeur
|
||||
des manipulations algébriques (algèbre = **al jabr**).
|
||||
C'est Léonard de Pise, dit Fibonacci, qui emprunta le nom du célèbre
|
||||
mathématicien arabe du 9ème siècle, mais l'algèbre existe
|
||||
depuis bien plus longtemps (Depuis Babylone, puis ensuite l'Egypte ancienne).
|
||||
|
||||
.. glossary::
|
||||
|
||||
|
||||
algorithme
|
||||
|
||||
terme désignant une suite d'opérations constituant un schéma de calcul
|
||||
ou de résolution d'un problème. C'est un processus systématique de
|
||||
résolution d'un problème permettant de décrire précisément des étapes.
|
||||
C'est une suite finie d'instructions permettant de donner la réponse à un
|
||||
problème.
|
||||
|
||||
L'algorithmique est l'étude et la production de règles et de techniques
|
||||
qui sont impliquées dans la définition d'algorithmes.
|
||||
|
||||
Implémentation d'un algorithme
|
||||
------------------------------
|
||||
|
||||
.. glossary::
|
||||
|
||||
implémentation
|
||||
|
||||
Adaptation de la méthodologie de calculabilité au calcul effectif
|
||||
sur une machine abstraite ou via un langage formel.
|
||||
|
||||
Il n’y a pas de parcours à sens unique de l’algorithme vers l’implantation.
|
||||
La quête d’une implantation efficace nous amène souvent à effectuer
|
||||
un retour vers les algorithmes eux-mêmes, et à en modifier des points
|
||||
essentiels. L’aspect théorique de réflexion sur les algorithmes,
|
||||
et l’aspect pratique de l'implémentation sont donc en symbiose.
|
||||
|
||||
Un existant émerge de la décomposition structurale d'un
|
||||
domaine de base. Le fait essentiel, c'est la genèse des genres de l'existant les
|
||||
uns à partir des autres.
|
||||
|
||||
L'essence d'une forme (un algorithme) se réalise au sein d'une matière qu'elle créée
|
||||
(un langage). L'origine d'une matière fait naître les formes (concepts)
|
||||
que sa structure dessine.
|
||||
|
||||
- Notion structurale de non-contradiction
|
||||
- Notion extensive de "réalisation dans un champ donné"
|
||||
|
||||
Deux aspects réciproques : l'essence d'une forme se réalise au sein d'une
|
||||
matière qu'elle crée, l'essence d'une matière faisant naître les formes que sa
|
||||
structure dessine.
|
||||
|
||||
Abandonner l'idée trop simpliste de domaines concrets et d'opérations abstraites
|
||||
qui posséderaient en eux-mêmes comme une nature de matière et une nature de
|
||||
forme ; cette conception tendrait, en effet, à stabiliser les existants
|
||||
mathématiques dans certains rôles immuables et ignorerait le fait que les
|
||||
existants abstraits qui naissent de la structure d'un domaine plus concret
|
||||
peuvent à leur tour servir de domaine de base pour la genèse d'autres existants.
|
||||
|
||||
L'algorithme comme généralisation de la calculabilité
|
||||
------------------------------------------------------
|
||||
|
||||
L'importance croissante de l'informatique comme outil scientifique
|
||||
impose d'élaborer un nouveau mode de description des méthodes de calcul (appelées algorithmes)
|
||||
susceptible de satisfaire à la fois le critère de sécurité (maîtrise du résultat) et la possibilité
|
||||
d'implémenter les calculs sur un ordinateur.
|
||||
|
||||
Exemple d'algorithme
|
||||
---------------------
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{L'alorithme de Bellman-Kalaba}
|
||||
\begin{algorithmic}[1]
|
||||
\Procedure {BellmanKalaba}{$G$, $u$, $l$, $p$}
|
||||
\ForAll {$v \in V(G)$}
|
||||
\State $l(v) \leftarrow \infty$
|
||||
\EndFor
|
||||
\State $l(u) \leftarrow 0$
|
||||
\Repeat
|
||||
\For {$i \leftarrow 1, n$}
|
||||
\State $min \leftarrow l(v_i)$
|
||||
\For {$j \leftarrow 1, n$}
|
||||
\If {$min > e(v_i, v_j) + l(v_j)$}
|
||||
\State $min \leftarrow e(v_i, v_j) + l(v_j)$
|
||||
\State $p(i) \leftarrow v_j$
|
||||
\EndIf
|
||||
\EndFor
|
||||
\State $l(i) \leftarrow min$
|
||||
\EndFor
|
||||
\State $changed \leftarrow l \not= l’$
|
||||
\State $l \leftarrow l$
|
||||
\Until{$\neg changed$}
|
||||
\EndProcedure
|
||||
\Statex
|
||||
\Procedure {FindPathBK}{$v$, $u$, $p$}
|
||||
\If {$v = u$}
|
||||
\State \textbf{Write} $v$
|
||||
\Else
|
||||
\State $w \leftarrow v$
|
||||
\While {$w \not= u$}
|
||||
\State \textbf{Write} $w$
|
||||
\State $w \leftarrow p(w)$
|
||||
\EndWhile
|
||||
\EndIf
|
||||
\EndProcedure
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
Exemple d'algorithme avec son implémentation
|
||||
---------------------------------------------
|
||||
|
||||
Soit l'algorithme de factorielle suivant,
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Algorithme de la factorielle d'un nombre}\label{factorielle}
|
||||
\begin{algorithmic}[1]
|
||||
\Function{factorielle}{$n$}\Comment{La fonction récursive factorielle}
|
||||
\BState \emph{parametre} : $n$ entier
|
||||
\If{$n = 1$}
|
||||
\BState \emph{Sortie} : 1
|
||||
\Else
|
||||
\BState \emph{Sortie} : $n * \Call{factorielle}{n-1}$ \Comment{On appelle la fonction dans l'algorithme lui-même}
|
||||
\EndIf
|
||||
\EndFunction
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
et son implémentation en python :
|
||||
|
||||
.. literalinclude:: code/factorielle.py
|
||||
:language: python
|
||||
|
||||
En voici une autre implémentation (en OCaml) :
|
||||
|
||||
.. literalinclude:: code/factorielle.ml
|
||||
:language: ocaml
|
||||
|
||||
On remarque que le **pseudocode** est très proche de
|
||||
la syntaxe du python :
|
||||
|
||||
.. function:: factorielle(n:int)
|
||||
|
||||
::
|
||||
|
||||
if n=1
|
||||
return 1
|
||||
else
|
||||
return n * factorielle(n-1)
|
||||
end if
|
||||
|
||||
Qualité d'un algorithme
|
||||
-----------------------
|
||||
|
||||
- correction d'un algorithme
|
||||
- complétude d'un algorithme
|
||||
|
||||
Sémantique
|
||||
|
||||
Étude du sens, de la signification d'un langage
|
||||
Définir la sémantique d’un langage formel consiste à lui donner une
|
||||
signification mathématique.
|
||||
|
||||
Sémantique opérationnelle
|
||||
|
||||
on définit la sémantique par sa mise en œuvre sur
|
||||
une machine abstraite.
|
||||
|
||||
Sémantique dénotationnelle
|
||||
|
||||
on associe à chaque construction syntaxique un
|
||||
objet mathématique
|
||||
|
||||
Sémantique axiomatique
|
||||
|
||||
chaque construction est décrite par la manière dont
|
||||
elle transforme des propriétés ou des prédicats.
|
||||
|
||||
Proposition
|
||||
|
||||
une proposition est un énoncé qui est soit vrai, soit faux
|
||||
|
||||
**exemple** : ``2 + 3 = 5``. Proposition vraie.
|
||||
|
||||
Prédicats
|
||||
|
||||
Une proposition dont la valeur de vérité dépend de la valeur d’une ou plusieurs variables
|
||||
|
||||
**Exemple** : ``n est pair`` : vrai pour n = 4 mais faux pour n = 9
|
||||
|
||||
|
||||
Axiome
|
||||
|
||||
une proposition qui est supposée vraie
|
||||
|
||||
Un ensemble d’axiomes est consistant s’il n’existe pas de proposition
|
||||
dont on peut démontrer qu’elle est à la fois vraie et fausse.
|
||||
|
||||
Un ensemble d’axiomes est complet si, pour toute proposition, il est
|
||||
possible de démontrer qu’elle est vraie ou fausse.
|
||||
|
||||
Théorème d’incomplétude de Gödel (1931) : tout ensemble
|
||||
consistant d’axiomes pour l’arithmétique sur les entiers est
|
||||
nécessairement incomplet.
|
||||
|
||||
**Les concepts de base en algorithmique sont les axiomes**
|
||||
|
||||
inférence
|
||||
|
||||
règles d’inférence, règles permettant de combiner des axiomes et des
|
||||
propositions vraies pour établir de nouvelles propositions vraies.
|
||||
|
||||
Démonstration
|
||||
|
||||
vérification d’une proposition par une séquence de déductions logiques
|
||||
à partir d’un ensemble d’axiomes.
|
||||
|
||||
Lorsque le champ donné (le domaine) ne contient qu'un nombre fini d'individus,
|
||||
on peut définir un choix de valeur des variables permettant de vérifier la
|
||||
proposition obtenue par la *conjonction* de tous les axiomes du système proposé.
|
||||
On dit alors que ce choix *réalise* un système d'axiomes.
|
||||
|
||||
|
||||
Il ne s'agit plus de savoir si la définition entraîne l'existence, mais de
|
||||
chercher si la structure d'un système d'axiomes (*règles*) peut donner naissance
|
||||
à un champ d'individus qui soutiennent entre eux les relations définies pas les
|
||||
axiomes.
|
||||
|
||||
Concret et abstrait
|
||||
--------------------
|
||||
|
||||
Il est possible qu'un même genre d'existant joue dans un schéma de genèse le
|
||||
rôle d'abstrait par rapport à un concret de base, et soit au contraire dans une
|
||||
autre genèse le concret de base d'un nouvel abstrait.
|
||||
|
||||
Une pareille présentation des choses implique un tel renversement par rapport
|
||||
aux habitudes de pensée classiques, qu'il faut encore insister sur le sens
|
||||
nouveau que reçoivent ici les expressions de "concret" et "d'abstrait".
|
||||
|
||||
Les systèmes d'axiomes sont souvent conçus comme des structures purement
|
||||
formelles, abstraites. Ces structures sont si profondément engagées dans la
|
||||
genèse de leurs réalisations, qu'il valait mieux désigner par ces termes les
|
||||
structures de base.
|
||||
|
||||
Un système d'axiome *peut* devenir le concret de base.
|
||||
|
||||
Ceci permet d'exprimer non seulement l'engagement du concret dans la genèse de
|
||||
l'abstrait, mais encore les relations d'imitation qui peuvent exister entre la
|
||||
structure de cet abstrait et celle du concret de base.
|
||||
|
||||
Dans certains cas, la genèse de l'abstrait à partir d'un concret de base
|
||||
s'affirme jusqu'à réaliser une imitation de structure entre ces genres
|
||||
d'existants qui naissent l'un de l'autre.
|
||||
|
||||
**C'est pourquoi on représente souvent un algorithme en pseudo-code**,
|
||||
c'est-à-dire en fait dans le mode de représentation (issu du langage préféré de la
|
||||
personne qui l'exprime) dominant chez la personne qui exprime un algorithme.
|
||||
|
||||
Comment rendre un algorithme lisible
|
||||
------------------------------------
|
||||
|
||||
- Le bon algorithme utilise des identifiants explicites.
|
||||
- Le bon algorithme est structuré.
|
||||
- Le bon algorithme est indenté.
|
||||
|
||||
Complexité d'un algorithme
|
||||
--------------------------
|
||||
|
||||
On peut approximer la complexité des algorithmes.
|
||||
C'est utile pour pouvoir comparer des algorithmes.
|
||||
|
||||
complexité
|
||||
|
||||
estimer la complexité d'un algorithme, c'est estimer le nombre de calculs qu'il utilise.
|
||||
|
||||
Si f est la fonction caractérisant exactement le coût d’un algorithme et n
|
||||
la taille des données, on s’intéresse à la façon dont augment f(n) lorsque n augmente
|
||||
on va montrer que f(n) n'augmente pas plus vite qu’une autre fonction
|
||||
g(n). Du point de vue mathématique, on dit que la fonction f est dominée
|
||||
asymptotiquement par la fonction g ce qui se note f = O(g)
|
||||
|
||||
- Complexité temporelle : c’est le nombre d’op«erations effectuées par
|
||||
une machine qui exécute l’algorithme.
|
||||
|
||||
- Complexité spatiale : c’est le nombre de positions mémoire utilisées par
|
||||
une machine qui exécute l’algorithme.
|
||||
.. include:: ../../tronCommun/algo.txt
|
||||
|
||||
@ -1,198 +1 @@
|
||||
Présentation de l'art de programmer
|
||||
====================================
|
||||
|
||||
Qu'est-ce que la programmation ?
|
||||
--------------------------------
|
||||
|
||||
programmation
|
||||
|
||||
Description d’un calcul (traitement) dans
|
||||
un langage compréhensible par la machine
|
||||
(langage de programmation)
|
||||
|
||||
Le processus d'abstraction
|
||||
--------------------------
|
||||
|
||||
Débuter en programmation n'est pas une chose aisée. Aujourd'hui, la tendance est au
|
||||
"bas niveau". Souvent, on se jette dans le grand bain :
|
||||
|
||||
- soit en s'approchant au maximum de la machine (admin système et réseau, noyau
|
||||
linux, langage C)
|
||||
|
||||
- soit en faisant du dev web côté backend, ce qui ramène à une administration réseau
|
||||
de bas niveau (microservices, monde nodeJS/javascript, etc...)
|
||||
|
||||
Soit on suit un cursus scolaire traditionnel qui commence souvent par une
|
||||
explication du fonctionnement d'une machine abstraite de bas niveau, puis en
|
||||
allant de plus en plus haut, mais étant sous-entendu qu'il faut rester connecté au
|
||||
bas niveau (comprendre comment ça se passe derrière la scène).
|
||||
|
||||
Dans ces deux cas, il est sous-entendu qu'on apprend plus de choses et plus rapidement en mettant
|
||||
les mains dans le cambouis, ce qui est vrai bien sûr. Mais cela sous-entend qu'un développeur doit
|
||||
rester le nez dans le guidon. Qu'il doit être un expert de son domaine en accumulant des technologies
|
||||
sans aucun recul. Bien sûr il se doit d'être un expert du système dans lequel il évolue
|
||||
(connaissance du système d'exploitation, binding avec le C, du ramasse miette (garbage
|
||||
collector), interaction avec les différentes librairies, gestion et optimisation de la mémoire,
|
||||
architecture par microservices, threads...) mais il doit aussi être capable de prendre du recul.
|
||||
|
||||
L'approche algorithmique (algorithmique de pseudo code, algorithmique algébrique et modulaire)
|
||||
est un véritable moyen pour le programmeur de prendre du recul : elle commence par se placer du
|
||||
côté de l'esprit humain et de ses capacités de compréhension et d'abstraction, elle autorise une
|
||||
pensée rationnelle sur l'art de programmer et permet au programmeur d'effectuer les bons choix,
|
||||
en connaissance de sa discipline.
|
||||
|
||||
Le lien est fait ensuite avec le plus bas niveau grâce une implémentation effective
|
||||
des langages à partir des paradigmes de rationalisation de la penseée (modules,
|
||||
objects, généricité, polymorphisme paramétrique...) et d'un outil de communication
|
||||
avec la machine qu'on appelle compilateur (dont la description est en dehors de
|
||||
l'objectif de ce cours).
|
||||
|
||||
La tendance générale de l'évolution des langages est de se libérer de ces
|
||||
contraintes de bas niveau, un peu comme en sciences physiques où les lois physiques
|
||||
dépendent de l'échelle d'en dessous (du niveau microscopique/quantique) mais qu'à
|
||||
l'échelle du dessus, on n'a pas affaire à des effets de bas niveau (pas d'effets
|
||||
quantiques à un niveau macroscopique en général). Ce processus d'évolution est vrai
|
||||
aussi dans le monde de la technique informatique lui-même (modèle OSI, comment est
|
||||
construite une trame IP, indépendances de chaque couche (transport, payload) entre
|
||||
elles). Même la tendance système est à la virtualisation qui accentue encore la
|
||||
tendance à s'affranchir du bas niveau (le niveau système), le séparer nettement du
|
||||
haut niveau (le niveau applicatif).
|
||||
|
||||
Il apparaît régulièrement de nouveaux langages. Comment s'orienter ? Quel(s)
|
||||
langage(s) choisir pour un projet de développement ? Au delà de leurs disparités, la
|
||||
conception et la genèse de chacun d'eux procèdent d'une motivation partagée : la
|
||||
volonté d'abstraire.
|
||||
|
||||
- **s'abstraire de la machine** : un langage de programmation permet de
|
||||
négliger l'aspect *mécanique* de l'ordinateur. On oublie le modèle du
|
||||
microprocesseur, jusqu'au système d'exploitation sur lequel sera exécuté
|
||||
le programme.
|
||||
|
||||
- **abstraire les erreurs** : Il s'agit ici de garantir la sûreté d'exécution; un
|
||||
programme ne doit pas se terminer brutalement ou devenir incohérent en cas d'erreur.
|
||||
Un des moyens pour y parvenir est le typage des programmes et la mise
|
||||
en oeuvre d'un mécanisme d'exceptions.
|
||||
|
||||
- **abstraire le mode opératoire** : Il s'agit de choisir une représentation, un
|
||||
paradigme d'implémentation qui est indépendant du domaine considéré (paradigme
|
||||
objet, modulaire, générique, composants...)
|
||||
|
||||
- **abstraire les composants** : Les langages de programmation donnent la
|
||||
possibilité de découper une application en différents composants logiciels, plus ou
|
||||
moins indépendants et autonomes. La modularité permet une structuration de plus haut
|
||||
niveau de l'ensemble d'une application complexe. Les langages à objets constituent
|
||||
une autre approche de la réutilisabilité permettant la réalisation très rapide de
|
||||
prototypes.
|
||||
|
||||
Description des niveaux d'abstraction par rapport à la machine
|
||||
---------------------------------------------------------------
|
||||
|
||||
Les langages de haut niveau simplifient le travail du
|
||||
programmeur là où les langages de bas niveau permettent de produire un code
|
||||
plus efficace.
|
||||
|
||||
- **niveau 0** : le langage machine. Illisible, c'est une suite d'optcode.
|
||||
impossible de coder dans ce langage.
|
||||
|
||||
- **niveau 1** : langage d'assemblage. Il reste très dépendant de la machine
|
||||
et aujourd'hui il est rare d'en faire, sauf si on code un bootloader par exemple,
|
||||
la gestion de l'accès à la mémoire est en réel (le mode protégé n'apparaît que après).
|
||||
Il faut gérer les ressources,le langage est très optimisé mais presque impossible
|
||||
à maintenir et rendre générique. Aujourd'hui plus personne ne code en assembleur.
|
||||
|
||||
- **niveau 2** : langages dits de **bas niveau** : (exemple : le C, le C++)
|
||||
indépendance par rapport à la machine, grande structuration mais très verbeux
|
||||
|
||||
- **niveau 3** : langages dits de **haut niveau** : le raisonnement dans ces
|
||||
langages ne dépent plus de la machine, et ils implémentent des paradigmes de
|
||||
programmation indépendant de l'état de la mémoire de l'ordinateur,
|
||||
ils sont indépendant même du système d'exploitation.
|
||||
|
||||
Qu'est-ce qu'une machine ?
|
||||
---------------------------
|
||||
|
||||
Une machine, ce truc apparemment si complexe, est en fait
|
||||
un assemblage de bric et de brac.
|
||||
|
||||
L'assemblage des connecteurs permet de simuler un additionneur,
|
||||
en prenant en compte les propriétés de **reste euclidien**
|
||||
de l'addition.
|
||||
|
||||
La structure électronique est composée de :
|
||||
|
||||
- un ordonnanceur.
|
||||
- le stockage d'un **état**.
|
||||
- une pile d'instruction
|
||||
|
||||
.. glossary::
|
||||
|
||||
adressage
|
||||
|
||||
Dès lors qu'on dispose de ces bases électronique au dessus du processeur,
|
||||
un langage d'assemblage est possible, c'est le langage de calcul sur les registres.
|
||||
|
||||
registre
|
||||
|
||||
machines ont un espace mémoire et un espace de calcul (registres)
|
||||
|
||||
Un ordinateur, c'est très très stupide, mais ça permet de disposer de :
|
||||
|
||||
- une mémoire très grande et ordonnée,
|
||||
- une capacité à effectuer inlassablement des tâches répétitives
|
||||
- une grande rapidité de calcul
|
||||
|
||||
Apprendre à programmer, c'est-à-dire être capable de
|
||||
contrôler la machine.
|
||||
|
||||
.. important:: Apprendre à programmer, c'est-à-dire apprendre à penser de manière structurée,
|
||||
pour pouvoir accessoirement ensuite communiquer avec une machine.
|
||||
|
||||
Compilateur
|
||||
-----------
|
||||
|
||||
Schématiquement, un compilateur est un programme qui traduit un
|
||||
programme d’un langage source vers un langage cible, en signalant
|
||||
d’éventuelles erreurs.
|
||||
|
||||
Quand on parle de compilation, on pense typiquement à la traduction d’un
|
||||
langage de haut niveau (C, Java, Caml, ...) vers le langage machine d’un
|
||||
processeur (Intel Pentium, PowerPC, ...)
|
||||
|
||||
- xml (libre office, word) -> postscript (imprimante)
|
||||
- postcript -> image
|
||||
- syntaxe wiki -> html (Wikipédia...)
|
||||
|
||||
compilation graphique
|
||||
|
||||
passer une description, ça donne un dessin genre ocaml Quilt < mon_dessin.txt
|
||||
passer par une api qui permet de causer avec une interface
|
||||
|
||||
**transpiler** : transformation d'un langage de haut niveau vers un autre
|
||||
langage de haut niveau.
|
||||
|
||||
- cofee script, typescript -> javascript
|
||||
- (babel) javascript -> javascript ES 6
|
||||
- python -> javascript
|
||||
|
||||
Un compilateur traduit un programme P en un programme Q tel que
|
||||
pour toute entrée x , la sortie de `Q(x)` soit la même que celle de `P(x)`
|
||||
|
||||
Un interprète est un programme qui, étant donné un programme `P` et une
|
||||
entrée x , calcule la sortie s de `P(x)`
|
||||
|
||||
Le compilateur fait un travail complexe une seule fois, pour produire un
|
||||
code fonctionnant pour n’importe quelle entrée
|
||||
L’interprète effectue un travail plus simple, mais le refait sur chaque entrée
|
||||
Autre différence : le code compilé est généralement bien plus efficace que
|
||||
le code interprété
|
||||
|
||||
Typiquement, le travail d’un compilateur se compose d’une phase d’analyse
|
||||
|
||||
- reconnaît le programme à traduire et sa signification
|
||||
- signale les erreurs et peut donc échouer (erreurs de syntaxe, de portée, de typage, etc.)
|
||||
|
||||
Puis d’une phase de synthèse
|
||||
|
||||
- production du langage cible
|
||||
- utilise de nombreux langages intermédiaires
|
||||
- n’échoue pas
|
||||
.. include:: ../../tronCommun/fondement.txt
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Introduction à l'algorithmique
|
||||
================================
|
||||
Algorithmique Approfondie
|
||||
=========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
1
algo/AlgoApprofondie/cours/langage.txt
Normal file
1
algo/AlgoApprofondie/cours/langage.txt
Normal file
@ -0,0 +1 @@
|
||||
.. include:: ../../tronCommun/langage.txt
|
||||
@ -1,291 +0,0 @@
|
||||
Algorithmique
|
||||
=============
|
||||
|
||||
Al-Kharezmi, auteur du traité "Kitab al jabr w'al-muqabala", est l'inventeur
|
||||
des manipulations algébriques (algèbre = **al jabr**).
|
||||
C'est Léonard de Pise, dit Fibonacci, qui emprunta le nom du célèbre
|
||||
mathématicien arabe du 9ème siècle, mais l'algèbre existe
|
||||
depuis bien plus longtemps (Depuis Babylone, puis ensuite l'Egypte ancienne).
|
||||
|
||||
.. glossary::
|
||||
|
||||
|
||||
algorithme
|
||||
|
||||
terme désignant une suite d'opérations constituant un schéma de calcul
|
||||
ou de résolution d'un problème. C'est un processus systématique de
|
||||
résolution d'un problème permettant de décrire précisément des étapes.
|
||||
C'est une suite finie d'instructions permettant de donner la réponse à un
|
||||
problème.
|
||||
|
||||
L'algorithmique est l'étude et la production de règles et de techniques
|
||||
qui sont impliquées dans la définition d'algorithmes.
|
||||
|
||||
Implémentation d'un algorithme
|
||||
------------------------------
|
||||
|
||||
.. glossary::
|
||||
|
||||
implémentation
|
||||
|
||||
Adaptation de la méthodologie de calculabilité au calcul effectif
|
||||
sur une machine abstraite ou via un langage formel.
|
||||
|
||||
Il n’y a pas de parcours à sens unique de l’algorithme vers l’implantation.
|
||||
La quête d’une implantation efficace nous amène souvent à effectuer
|
||||
un retour vers les algorithmes eux-mêmes, et à en modifier des points
|
||||
essentiels. L’aspect théorique de réflexion sur les algorithmes,
|
||||
et l’aspect pratique de l'implémentation sont donc en symbiose.
|
||||
|
||||
Un existant émerge de la décomposition structurale d'un
|
||||
domaine de base. Le fait essentiel, c'est la genèse des genres de l'existant les
|
||||
uns à partir des autres.
|
||||
|
||||
L'essence d'une forme (un algorithme) se réalise au sein d'une matière qu'elle créée
|
||||
(un langage). L'origine d'une matière fait naître les formes (concepts)
|
||||
que sa structure dessine.
|
||||
|
||||
- Notion structurale de non-contradiction
|
||||
- Notion extensive de "réalisation dans un champ donné"
|
||||
|
||||
Deux aspects réciproques : l'essence d'une forme se réalise au sein d'une
|
||||
matière qu'elle crée, l'essence d'une matière faisant naître les formes que sa
|
||||
structure dessine.
|
||||
|
||||
Abandonner l'idée trop simpliste de domaines concrets et d'opérations abstraites
|
||||
qui posséderaient en eux-mêmes comme une nature de matière et une nature de
|
||||
forme ; cette conception tendrait, en effet, à stabiliser les existants
|
||||
mathématiques dans certains rôles immuables et ignorerait le fait que les
|
||||
existants abstraits qui naissent de la structure d'un domaine plus concret
|
||||
peuvent à leur tour servir de domaine de base pour la genèse d'autres existants.
|
||||
|
||||
L'algorithme comme généralisation de la calculabilité
|
||||
------------------------------------------------------
|
||||
|
||||
L'importance croissante de l'informatique comme outil scientifique
|
||||
impose d'élaborer un nouveau mode de description des méthodes de calcul (appelées algorithmes)
|
||||
susceptible de satisfaire à la fois le critère de sécurité (maîtrise du résultat) et la possibilité
|
||||
d'implémenter les calculs sur un ordinateur.
|
||||
|
||||
Exemple d'algorithme
|
||||
---------------------
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{L'alorithme de Bellman-Kalaba}
|
||||
\begin{algorithmic}[1]
|
||||
\Procedure {BellmanKalaba}{$G$, $u$, $l$, $p$}
|
||||
\ForAll {$v \in V(G)$}
|
||||
\State $l(v) \leftarrow \infty$
|
||||
\EndFor
|
||||
\State $l(u) \leftarrow 0$
|
||||
\Repeat
|
||||
\For {$i \leftarrow 1, n$}
|
||||
\State $min \leftarrow l(v_i)$
|
||||
\For {$j \leftarrow 1, n$}
|
||||
\If {$min > e(v_i, v_j) + l(v_j)$}
|
||||
\State $min \leftarrow e(v_i, v_j) + l(v_j)$
|
||||
\State $p(i) \leftarrow v_j$
|
||||
\EndIf
|
||||
\EndFor
|
||||
\State $l(i) \leftarrow min$
|
||||
\EndFor
|
||||
\State $changed \leftarrow l \not= l’$
|
||||
\State $l \leftarrow l$
|
||||
\Until{$\neg changed$}
|
||||
\EndProcedure
|
||||
\Statex
|
||||
\Procedure {FindPathBK}{$v$, $u$, $p$}
|
||||
\If {$v = u$}
|
||||
\State \textbf{Write} $v$
|
||||
\Else
|
||||
\State $w \leftarrow v$
|
||||
\While {$w \not= u$}
|
||||
\State \textbf{Write} $w$
|
||||
\State $w \leftarrow p(w)$
|
||||
\EndWhile
|
||||
\EndIf
|
||||
\EndProcedure
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
Exemple d'algorithme avec son implémentation
|
||||
---------------------------------------------
|
||||
|
||||
Soit l'algorithme de factorielle suivant,
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Algorithme de la factorielle d'un nombre}\label{factorielle}
|
||||
\begin{algorithmic}[1]
|
||||
\Function{factorielle}{$n$}\Comment{La fonction récursive factorielle}
|
||||
\BState \emph{parametre} : $n$ entier
|
||||
\If{$n = 1$}
|
||||
\BState \emph{Sortie} : 1
|
||||
\Else
|
||||
\BState \emph{Sortie} : $n * \Call{factorielle}{n-1}$ \Comment{On appelle la fonction dans l'algorithme lui-même}
|
||||
\EndIf
|
||||
\EndFunction
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
et son implémentation en python :
|
||||
|
||||
.. literalinclude:: code/factorielle.py
|
||||
:language: python
|
||||
|
||||
En voici une autre implémentation (en OCaml) :
|
||||
|
||||
.. literalinclude:: code/factorielle.ml
|
||||
:language: ocaml
|
||||
|
||||
On remarque que le **pseudocode** est très proche de
|
||||
la syntaxe du python :
|
||||
|
||||
.. function:: factorielle(n:int)
|
||||
|
||||
::
|
||||
|
||||
if n=1
|
||||
return 1
|
||||
else
|
||||
return n * factorielle(n-1)
|
||||
end if
|
||||
|
||||
Qualité d'un algorithme
|
||||
-----------------------
|
||||
|
||||
- correction d'un algorithme
|
||||
- complétude d'un algorithme
|
||||
|
||||
Sémantique
|
||||
|
||||
Étude du sens, de la signification d'un langage
|
||||
Définir la sémantique d’un langage formel consiste à lui donner une
|
||||
signification mathématique.
|
||||
|
||||
Sémantique opérationnelle
|
||||
|
||||
on définit la sémantique par sa mise en œuvre sur
|
||||
une machine abstraite.
|
||||
|
||||
Sémantique dénotationnelle
|
||||
|
||||
on associe à chaque construction syntaxique un
|
||||
objet mathématique
|
||||
|
||||
Sémantique axiomatique
|
||||
|
||||
chaque construction est décrite par la manière dont
|
||||
elle transforme des propriétés ou des prédicats.
|
||||
|
||||
Proposition
|
||||
|
||||
une proposition est un énoncé qui est soit vrai, soit faux
|
||||
|
||||
**exemple** : ``2 + 3 = 5``. Proposition vraie.
|
||||
|
||||
Prédicats
|
||||
|
||||
Une proposition dont la valeur de vérité dépend de la valeur d’une ou plusieurs variables
|
||||
|
||||
**Exemple** : ``n est pair`` : vrai pour n = 4 mais faux pour n = 9
|
||||
|
||||
|
||||
Axiome
|
||||
|
||||
une proposition qui est supposée vraie
|
||||
|
||||
Un ensemble d’axiomes est consistant s’il n’existe pas de proposition
|
||||
dont on peut démontrer qu’elle est à la fois vraie et fausse.
|
||||
|
||||
Un ensemble d’axiomes est complet si, pour toute proposition, il est
|
||||
possible de démontrer qu’elle est vraie ou fausse.
|
||||
|
||||
Théorème d’incomplétude de Gödel (1931) : tout ensemble
|
||||
consistant d’axiomes pour l’arithmétique sur les entiers est
|
||||
nécessairement incomplet.
|
||||
|
||||
**Les concepts de base en algorithmique sont les axiomes**
|
||||
|
||||
inférence
|
||||
|
||||
règles d’inférence, règles permettant de combiner des axiomes et des
|
||||
propositions vraies pour établir de nouvelles propositions vraies.
|
||||
|
||||
Démonstration
|
||||
|
||||
vérification d’une proposition par une séquence de déductions logiques
|
||||
à partir d’un ensemble d’axiomes.
|
||||
|
||||
Lorsque le champ donné (le domaine) ne contient qu'un nombre fini d'individus,
|
||||
on peut définir un choix de valeur des variables permettant de vérifier la
|
||||
proposition obtenue par la *conjonction* de tous les axiomes du système proposé.
|
||||
On dit alors que ce choix *réalise* un système d'axiomes.
|
||||
|
||||
|
||||
Il ne s'agit plus de savoir si la définition entraîne l'existence, mais de
|
||||
chercher si la structure d'un système d'axiomes (*règles*) peut donner naissance
|
||||
à un champ d'individus qui soutiennent entre eux les relations définies pas les
|
||||
axiomes.
|
||||
|
||||
Concret et abstrait
|
||||
--------------------
|
||||
|
||||
Il est possible qu'un même genre d'existant joue dans un schéma de genèse le
|
||||
rôle d'abstrait par rapport à un concret de base, et soit au contraire dans une
|
||||
autre genèse le concret de base d'un nouvel abstrait.
|
||||
|
||||
Une pareille présentation des choses implique un tel renversement par rapport
|
||||
aux habitudes de pensée classiques, qu'il faut encore insister sur le sens
|
||||
nouveau que reçoivent ici les expressions de "concret" et "d'abstrait".
|
||||
|
||||
Les systèmes d'axiomes sont souvent conçus comme des structures purement
|
||||
formelles, abstraites. Ces structures sont si profondément engagées dans la
|
||||
genèse de leurs réalisations, qu'il valait mieux désigner par ces termes les
|
||||
structures de base.
|
||||
|
||||
Un système d'axiome *peut* devenir le concret de base.
|
||||
|
||||
Ceci permet d'exprimer non seulement l'engagement du concret dans la genèse de
|
||||
l'abstrait, mais encore les relations d'imitation qui peuvent exister entre la
|
||||
structure de cet abstrait et celle du concret de base.
|
||||
|
||||
Dans certains cas, la genèse de l'abstrait à partir d'un concret de base
|
||||
s'affirme jusqu'à réaliser une imitation de structure entre ces genres
|
||||
d'existants qui naissent l'un de l'autre.
|
||||
|
||||
**C'est pourquoi on représente souvent un algorithme en pseudo-code**,
|
||||
c'est-à-dire en fait dans le mode de représentation (issu du langage préféré de la
|
||||
personne qui l'exprime) dominant chez la personne qui exprime un algorithme.
|
||||
|
||||
Comment rendre un algorithme lisible
|
||||
------------------------------------
|
||||
|
||||
- Le bon algorithme utilise des identifiants explicites.
|
||||
- Le bon algorithme est structuré.
|
||||
- Le bon algorithme est indenté.
|
||||
|
||||
Complexité d'un algorithme
|
||||
--------------------------
|
||||
|
||||
On peut approximer la complexité des algorithmes.
|
||||
C'est utile pour pouvoir comparer des algorithmes.
|
||||
|
||||
complexité
|
||||
|
||||
estimer la complexité d'un algorithme, c'est estimer le nombre de calculs qu'il utilise.
|
||||
|
||||
Si f est la fonction caractérisant exactement le coût d’un algorithme et n
|
||||
la taille des données, on s’intéresse à la façon dont augment f(n) lorsque n augmente
|
||||
on va montrer que f(n) n'augmente pas plus vite qu’une autre fonction
|
||||
g(n). Du point de vue mathématique, on dit que la fonction f est dominée
|
||||
asymptotiquement par la fonction g ce qui se note f = O(g)
|
||||
|
||||
- Complexité temporelle : c’est le nombre d’op«erations effectuées par
|
||||
une machine qui exécute l’algorithme.
|
||||
|
||||
- Complexité spatiale : c’est le nombre de positions mémoire utilisées par
|
||||
une machine qui exécute l’algorithme.
|
||||
@ -1,294 +0,0 @@
|
||||
Les structures de contrôle
|
||||
==========================
|
||||
|
||||
L'instruction de saut
|
||||
----------------------
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Exemple de saut conditionnel}\label{saut}
|
||||
\begin{algorithmic}[1]
|
||||
\Procedure{Euclide}{} \Comment{c'est l'algorithme d'Euclide}
|
||||
\State $\textit{stringlen} \gets \text{length of }\textit{string}$
|
||||
\State $i \gets \textit{patlen}$
|
||||
\BState \emph{top}:
|
||||
\If {$i > \textit{stringlen}$} \Return false
|
||||
\EndIf
|
||||
\State $j \gets \textit{patlen}$
|
||||
\BState \emph{loop}: \Comment{C'est le label (l'étiquette)} \label{etiquette}
|
||||
\If {$\textit{string}(i) = \textit{path}(j)$}
|
||||
\State $j \gets j-1$.
|
||||
\State $i \gets i-1$.
|
||||
\State \textbf{goto} \emph{loop}. \label{goto}
|
||||
\State \textbf{close};
|
||||
\EndIf
|
||||
\State $i \gets
|
||||
i+\max(\textit{delta}_1(\textit{string}(i)),\textit{delta}_2(j))$.
|
||||
\State \textbf{goto} \emph{top}. \Comment{C'est l'instruction de saut}
|
||||
\EndProcedure
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
Ligne \ref{etiquette}, le bloc `loop` est aussi un label (une étiquette),
|
||||
c'est-à-dire une marque posée qu'il est possible de retrouver dans le programme. \\
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
Ligne \ref{goto}, l'instruction \texttt{goto} (aller à ) est le saut vers le label. \\
|
||||
|
||||
Description générique d'une instruction de saut::
|
||||
|
||||
Instruction 1
|
||||
Saut Label1
|
||||
Instruction 2
|
||||
...
|
||||
Label1:
|
||||
Instruction n
|
||||
|
||||
.. important:: les sauts conditionnels sont à éviter, même s'ils sont implémentés
|
||||
dans le langage cible, car c'est le meilleur moyen d'aboutir à
|
||||
du **code spaghetti**.
|
||||
|
||||
L'instruction de branchement conditionnel
|
||||
------------------------------------------
|
||||
|
||||
On appelle structure conditionnelle les instructions qui permettent de tester si une condition est vraie ou non.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Exemple d'instruction de test}
|
||||
\begin{algorithmic}[1]
|
||||
\BState \emph{entrée}: $quality\gets 0$ \Comment{C'est cette valeur qui sera testée}
|
||||
\BState \emph{locale}: $a\gets ""$
|
||||
\BState \emph{sortie}: $a$ \Comment{La sortie est la valeur de $a$}
|
||||
\BState \emph{corps}:
|
||||
\If{$quality\ge 9$}
|
||||
\State $a\gets perfect$
|
||||
\ElsIf{$quality\ge 7$}
|
||||
\State $a\gets good$
|
||||
\ElsIf{$quality\ge 5$}
|
||||
\State $a\gets medium$
|
||||
\ElsIf{$quality\ge 3$}
|
||||
\State $a\gets bad$
|
||||
\Else
|
||||
\State $a\gets unusable$
|
||||
\EndIf
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
|
||||
|
||||
.. ifconfig:: exercice
|
||||
|
||||
**Exercice** : Compacter l'algorithme suivant en une seule condition de test::
|
||||
|
||||
Si il fait trop chaud Alors
|
||||
Si il ne pleut pas Alors
|
||||
Ouvrir la fenêtre
|
||||
Sinon
|
||||
Fermer la fenêtre
|
||||
Finsi
|
||||
Sinon
|
||||
Fermer la fenêtre
|
||||
Finsi
|
||||
|
||||
.. ifconfig:: correction
|
||||
|
||||
**Correction** :
|
||||
|
||||
::
|
||||
|
||||
Si il fait trop chaud ET il ne pleut pas Alors
|
||||
Ouvrir la fenêtre
|
||||
Sinon
|
||||
Fermer la fenêtre
|
||||
Finsi
|
||||
|
||||
|
||||
L'instruction switch
|
||||
--------------------
|
||||
|
||||
L'instruction switch permet de faire plusieurs tests de valeurs sur le contenu d'une même variable.
|
||||
Ce branchement conditionnel simplifie beaucoup le test de plusieurs valeurs d'une variable.
|
||||
|
||||
Les instructions d'itérations (boucles)
|
||||
---------------------------------------
|
||||
|
||||
.. important:: Toutes les boucles concernent le paradigme de programmation impératif
|
||||
et ne sont pas valides dans le paradigme de programmation fonctionnel
|
||||
(puisque l'ordre d'évaluation importe)
|
||||
|
||||
- arrêt conditionnel (break)
|
||||
- passage d'un pas (continue)
|
||||
|
||||
Répéter ... jusqu'à
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Exemple de répéter ... jusqu'à}
|
||||
\begin{algorithmic}[1]
|
||||
\BState \emph{locales}: $i \gets 1$ \Comment{déclaration et initialisation de i}
|
||||
\Repeat \Comment{c'est le label de début du répéter}
|
||||
\State $i \gets \textit{i+1}$
|
||||
\Until{i == 100} \Comment{condition de fin de la boucle}
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
La boucle **pour** (for)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Exemple de boucle for}
|
||||
\begin{algorithmic}[1]
|
||||
\BState \emph{locales}: $sum\gets 0$
|
||||
\For{$i\gets 1, n$}
|
||||
\State $sum\gets sum+i$
|
||||
\EndFor
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
.. ifconfig:: exercice
|
||||
|
||||
**Exercice** : Ecrire un algorithme qui demande successivement 20 nombres à l’utilisateur,
|
||||
et qui lui dise ensuite quel était le plus grand parmi ces 20 nombres
|
||||
|
||||
.. ifconfig:: correction
|
||||
|
||||
**Correction** :
|
||||
::
|
||||
|
||||
Variables N, i, PG en Entier
|
||||
Debut
|
||||
PG <- 0
|
||||
Pour i <- 1 à 20
|
||||
Ecrire "Entrez un nombre : "
|
||||
Lire N
|
||||
Si i = 1 ou N > PG Alors
|
||||
PG <- N
|
||||
FinSi
|
||||
Ecrire "Le nombre le plus grand était : ", PG
|
||||
Fin
|
||||
|
||||
|
||||
.. attention:: ne jamais manipuler le compteur dans une boucle
|
||||
|
||||
::
|
||||
|
||||
Variable Truc en Entier
|
||||
Début
|
||||
Pour Truc <- 1 à 15
|
||||
Truc <- Truc * 2
|
||||
Ecrire "Passage numéro : ", Truc
|
||||
Truc Suivant
|
||||
Fin
|
||||
|
||||
La boucle tant que (while)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Exemple de boucle while}
|
||||
\begin{algorithmic}[1]
|
||||
\BState \emph{locales}: $sum\gets 0$
|
||||
\State $i\gets 1$
|
||||
\While{$i\le n$}
|
||||
\State $sum\gets sum+i$
|
||||
\State $i\gets i+1$
|
||||
\EndWhile
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
.. ifconfig:: exercice
|
||||
|
||||
**Exercice** : Ecrire un algorithme de validation d'une entrée utilisateur
|
||||
|
||||
::
|
||||
|
||||
"Voulez vous un café ? (O/N)"
|
||||
|
||||
.. ifconfig:: correction
|
||||
|
||||
**Correction** : deux solutions possibles, une
|
||||
|
||||
::
|
||||
|
||||
Variable Rep en Caractère
|
||||
Début
|
||||
Rep <- ""
|
||||
Ecrire "Voulez vous un café ? (O/N)"
|
||||
TantQue Rep <> "O" et Rep <> "N"
|
||||
Lire Rep
|
||||
Si Rep <> "O" et Rep <> "N" Alors
|
||||
Ecrire "Saisie Erronée, Recommencez"
|
||||
FinSi
|
||||
FinTantQue
|
||||
Fin
|
||||
|
||||
::
|
||||
|
||||
Variable Rep en Caractère
|
||||
Début
|
||||
Ecrire "Voulez vous un café ? (O/N)"
|
||||
Lire Rep
|
||||
TantQue Rep <> "O" et Rep <> "N"
|
||||
Ecrire "Vous devez répondre par O ou N. Recommencez"
|
||||
Lire Rep
|
||||
FinTantQue
|
||||
Ecrire "Saisie acceptée"
|
||||
Fin
|
||||
|
||||
.. ifconfig:: exercice
|
||||
|
||||
**Exercice** : "C'est plus, C'est moins", c'est-à-dire Ecrire un algorithme qui demande à l’utilisateur
|
||||
un nombre compris entre a et b jusqu’à ce que la réponse convienne.
|
||||
|
||||
.. ifconfig:: correction
|
||||
|
||||
**Correction** :
|
||||
|
||||
::
|
||||
|
||||
Variable N en Entier
|
||||
Debut
|
||||
N <- 0
|
||||
Ecrire "Entrez un nombre entre 10 et 20"
|
||||
TantQue N < 10 ou N > 20
|
||||
Lire N
|
||||
Si N < 10 Alors
|
||||
Ecrire "Plus grand !"
|
||||
SinonSi N > 20 Alors
|
||||
Ecrire "Plus petit !"
|
||||
FinSi
|
||||
FinTantQue
|
||||
Fin
|
||||
|
||||
Et les autres boucles : répéter... jusqu'à, etc...
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Exemple de boucle répéter}
|
||||
|
||||
\begin{algorithmic}[1]
|
||||
\State $sum\gets 0$
|
||||
\State $i\gets 1$
|
||||
\Repeat
|
||||
\State $sum\gets sum+i$
|
||||
\State $i\gets i+1$
|
||||
\Until{$i>n$}
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
@ -7,10 +7,8 @@ Introduction à l'algorithmique
|
||||
presentation
|
||||
fondement
|
||||
langage
|
||||
algo
|
||||
programme
|
||||
fonctions
|
||||
control
|
||||
donnees
|
||||
apercu
|
||||
modularite
|
||||
|
||||
Loading…
Reference in New Issue
Block a user