[ALGO] Notation en algorithmique

Nous avons un soucis dans les notations concernant l'algorithmique.

Ce que je propose, c'est que l'on discute des notations que nous allons tous utiliser dans les FAQ, les articles et les sources.

Ce qu'il faut absolument, c'est uniformiser les structures de contrôles, les affectations, les tests, les appels de fonctions, les élements de tableaux, les utilisations des pointeurs, ...

Merci à tous

Pour la déclaration des fonctions, j'ai déjà vu en gros 2 manières :

Code:

---

1 2	fonction mafonction(element:Entier, truc:Reel):Entier

---

Ou :

Code:

---

1 2	fonction mafonction(Entier element, Reel truc) -> Entier

---

(ou des mélanges des deux).

Eventuellement, avec les fonctions ne renvoyant aucun paramètre (et donc avec effet de bord). Plutôt l'utilisation du terme "Procédure" que fonction.


Pour l'affectation :
Soit :
x <- 1
Soit
x:= 1 (utilisé dans plusieurs langage)
Peut être x=1, mais c'est moyen.


Pour la notation de pointeur, je ne sais pas si on utilise des réferences ou des pointeurs.



Il manque également la manière de noter les commentaires.

Citation:

---

Eventuellement, avec les fonctions ne renvoyant aucun paramètre (et donc avec effet de bord).

---

Je suis pas certain que les procédures soient toutes des procédures qui modifient leur paramètres. Sauf si tu considères les sorties comme un effet de bord, je ne suis pas d'accord.

Pour les fonctions je fais ainsi :

Code:

---

1 2	fonction NomDeLaFonction ( X : type ; Y : type ; ... ) renvoie type.

---

Pour les procédures :

Code:

---

1 2	procedure NomDeLaProcedure( X : mode type ; Y : mode type)

---

On est donc très proche de ce qui est fait en ADA.

Citation:

---

Pour l'affectation :
Soit :
x <- 1
Soit
x:= 1 (utilisé dans plusieurs langage)
Peut être x=1, mais c'est moyen.

---

Pour l'affectation surtout pas x=1. Comment fait tu la différence entre l'affectation et le test d'égalité (comme en C ?). C'est une mauvaise chose qui va entraîner des soucis.

Généralement je fais ceci :

Code:

---

X <- Valeur.

---

Citation:

---

Pour la notation de pointeur, je ne sais pas si on utilise des réferences ou des pointeurs.

---

Une référence n'a de sens que dans un langage. En algo, seul le pointeur compte.

A la fac, j'ai l'habitude de voir deux choses :

Code:

---

X.all.valeur

---

ou alors ceci :

Code:

---

X->valeur

---

La première est la notation ADA, la deuxième est la notation C. La première interdit l'utilisation de champs nommé all (mais est-ce un problème ?), elle est généralement plus lourde mais est à mon sens assez efficace dans le sens où on ne se trompe assez rarement.

La deuxième est plus courte ( C oblige ). Je ne sais pas laquelle est la meilleure.

Citation:

---

Il manque également la manière de noter les commentaires.

---

Pour les commentaires, j'aurai tendance à suivre les recommandations des créateurs de compilateurs : faire des commentaires à la C++ ou ADA. C'est à dire qui commence par un token et qui se termine avec la fin de ligne. Ca résoud quelques problèmes ou ambiguités.

L'intérêt d'une représentation informelle, c'est qu'elle est informelle. Si on veut une représentation fixée, autant utiliser un langage.

Ceci dit, j'écrivais pour commenter:

Citation:

---

Envoyé par PRomu@ld

A la fac, j'ai l'habitude de voir deux choses :

Code:

---

X.all.valeur

---

...la notation ADA

---

En Ada c'est X.valeur, le all est permit mais n'est obligatoire que quand on en fait pas référence à un champs (autrement dit, x.all c'est l'équivalent de *x en C, x.field l'équivalent de x->field).

Je suis tout à fait d'accord, il faut s'écrater des langages, c'est pourquoi j'ai crée ce topic.

Et toi, Jean Marc, quelles sont tes habitudes en matière de notation ?

Citation:

---

Envoyé par PRomu@ld

Et toi, Jean Marc, quelles sont tes habitudes en matière de notation?

---

Pas tellement d'habitudes. J'utilise quelque chose de proche du langage qui sera utilisé par après, souvent même le langage utilisé en utilisant des commentaires pour ce qui n'est pas permis dans le langage. Pour une présentation, je vais me permettre des choses comme indices, exposants, lettres grecques... un peu dans l'esprit des différents niveaux de représentation d'Algol.

Je me permet de taper l'incrust dans ce sujet, veuillez m'excuser si c'est déplacé... :oops:

Pedant mon court séjour à EPITA, il existait un interpréteur d'algo, PowerAlgoPlus, qui était très proche du langage naturel. Je pense que c'est pas mal, ça permet à tout un chacun d'adapter ensuite dans son langage de prédilection.

Je n'ai pas réussi à remettre la main dessus, peut-être qu'un ancien epiteen aurait encore ça, mais en gros ça donnait :

Citation:

---

i = 0
faire
i = i+1
tant que i < 20

---

j'avait beaucoup aimé à l'époque...

Citation:

---

Je me permet de taper l'incrust dans ce sujet, veuillez m'excuser si c'est déplacé...

---

Le sujet est ouvert à tous (et surtout au plus grand nombre), histoire de confronter les différentes habitudes et de façon à ce que l'on puisse obtenir une notation uniformisée la plus adaptée possible.

Code:

---

1 2 3 4

i = 0 faire i = i+1 tant que i < 20

---

Effectivement, c'est sympa.

Par contre, pour les structures de contrôle, j'ai tendance à les mettre en majuscule pour bien les démarquer et aussi utiliser une indentation. Ainsi, ton code donne chez moi :

Code:

---

1 2 3 4 5

i <- 0 FAIRE i <- i + 1 TANT QUE i < 20

---

Citation:

---

Envoyé par titoumimi

Pedant mon court séjour à EPITA, il existait un interpréteur d'algo, PowerAlgoPlus

---

S'il y a un interpréteur, c'est un langage. L'avantage de ne pas utiliser un langage formellement défini c'est de pouvoir être imprécis sur ce qui n'est pas significatif pour l'exposé en cours. Suivant ce qu'on veut faire, on utilise des choses différentes. Certains et non des moindres vont jusqu'à utiliser des langages machines...

Si on est en train de regarder les tris en place et l'occupation mémoire nécessaire, utiliser quelque chose de proche d'Haskell va poser des problèmes. Si on est en train d'exposer des algo sur des structures de données infinies, utiliser quelque chose de proche d'Haskell avec une évaluation paresseuse va au contraire aider à masquer toute une gestion qui n'a pas d'intérêt pour l'exposé. Si je fais des algo d'analyse numérique, utiliser quelque chose qui permet une notation infixe pour le calcul matriciel va être mieux.

D'autre part, si l'objectif est d'implémenter après, quelque chose de très proche du langage d'implémentation (ou même celui-ci avec des commentaires pour ce qui est informel) est mieux qu'une notation présentatant des similitudes syntaxiques mais des différences sémantiques.

Je ne crois pas à la solution universelle...

Citation:

---

Envoyé par Jean-Marc.Bourguet

S'il y a un interpréteur, c'est un langage.

---

En fait, c'était un interpréteur qui avait été construit en interne sur la base des cours d'algo qu'on avait.

Mais effectivement, ce n'était que de l'initiation à la logique algorithmique, je n'ai jamais eu de gros algo de la mort à réaliser avec, ce n'était peut-être pas adapté.

Citation:

---

e suis pas certain que les procédures soient toutes des procédures qui modifient leur paramètres.

---

Effectivement, une procédure n'est pas obligée de modifer ses paramètres, mais en général, cela n'a pas trop d'utilité.

Par exemple :

Code:

---

1 2 3

Procédure carre(Entier i) j <- i *i

---

Citation:

---

Une référence n'a de sens que dans un langage. En algo, seul le pointeur compte.

---

Personnellement, dans les cours d'algorithmique que j'ai eu et que j'ai vu, on a toujours parlé de reférence et non de pointeur.

Il y a également la question de la déclaration des variables.

Déclare-t-on les variables ou non ? Et si oui, avec quel syntaxe ? Pour garder de la cohérence, cela devrait se faire de la même manière que dans la déclaration des fonctions

Bonjour,

Après avoir lu vos posts précédents, je vois qu'on a tous eu plus ou moins les mêmes cours d'algo ;)

Alors, moi je vous propose (eh non, rien de neuf) :

Affectation :

Code:

---

x := 1

---

Pointeur :

Code:

---

x->valeur

---

Fonctions et procédures :

Code:

---

1 2	fonction mafonction(element:Entier, truc:Reel):Entier procedure mafonction(element:Entier, truc:Reel)

---

me semble plus lisible que l'autre solution (avec -> pour le type de retour).

Structures :

Code:

---

1 2 3 4 5

i:Entier i := 0 FAIRE i := i + 1 TANT QUE i < 20

---

en majuscules et indentées.

Citation:

---

Fonctions et procédures :
...

---

Il faudrait pouvoir identifier dans tes procédures comment sont passés les paramètres (in, out ou in out).

Citation:

---

Déclare-t-on les variables ou non ? Et si oui, avec quel syntaxe ?

---

Pour la déclaration, je pense à ça :

Citation:

---

nom : type

---

Bonjour,
Pour ma part, je dirais :

pour une fonction :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

fonction maFonction(element : Entier, truc : Reel) : Entier i <- 0 // affectation tant que i < 20 faire i <- i + 1 ftq // fin tant que retourne i finfonc lexique i : Entier, variable temporaire

---

Pour une procédure :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procédure échangerVariables(inout x : Entier, inout y : Entier) tmp <- x x <- y y <- tmp finproc lexique tmp : Entier, variable temporaire pour permettre l'échange x : Entier, premier paramètre qui sera remplacé par y y : Entier, second paramètre qui sera remplacé par x

---

Pour une classe (par exemple) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

classe Arbre /* Un attribut */ attribut : Entier /* Un nœud de l'arbre. Il est aussi un arbre. */ nœud : Arbre constructeur(toto : Entier) ... finconst finclasse

---

Les mots-clés étant soulignés. Indentations. Commentaires de type C, C++, Java, etc. On devrait permettre l'utilisation des accents (échangerVariables), ligatures (nœud) et autres symboles diacritiques (ç, etc.) ou lettres grecques.

Par exemple.

Bonjour,
Quant à moi, je privilégie un pseudo-langage proche du C, que je trouve presque plus lisible...

Les affectations:

Code:

---

1 2	type variable =x

---

Les fonctions:

Code:

---

1 2	fonction(type paramètre1, type paramètre2) : (type retour)

---

Les boucles et tests:

Code:

---

1 2 3 4 5

while (variable > y) //indentation //commentaires à la "C" if (variable < z) //indentation

---

Quant aux classes, je ne les utilise que très rarement en algorithmique...

L'utilisation des lettres grecques me semble indispensable, contrairement aux accents qui me semblent superflus...

Je n'aime pas trop utiliser le signe égal pour les affectation, j'aime bien différencier l'égalité de l'affectation. De plus, le symbole <- semble admis de tous.

Oui, et c'est ce qu'on apprend en cours d'algo. en DUT info. (cf. aussi ma proposition).

Bonjour a tous (ou bonne nuit vu l'heure);)

La manière dont j'ai appris à concevoir les algorithmes ne dépend d'aucun langage informatique.

C'est un mélange entre les mathématiques et un algèbre de Boole sur des conditions.

Je n'y ai donc pas de notions sur les pointeurs (qui seraient vue comme une fonction),
les fonctions, les procédures et encore moins les classes...
(Bien qu'il semble faire moins de propositions,
il y aurait moins de vocabulaire à connaitre et il serait plus aisé d'écrire...)

Je ne crois pas qu'un algorithme est besoin de notion de classe ou faire la différence entre une fonction et une procédure.
Si je dois utiliser des classes alors j'utilise un langage de programmation.
( c'est mon opinion pas une vérité ! :P )

Voici quelques exemples des notions abordées :
// Je met des commentaires
// J'affecte une variable à un type. (avant l'écriture de l'algorithme.)
x : entier
// J'affecte une variable à la valeur 2 à l'initialisation de l'algorithme.
Init F(x) = F(2)
// J'affecte une variable à la valeur 5 à l'appel de l'algorithme.
(x > 0) => F(x) = F(5)
// Je fais un appel depuis un autre algorithme.
// F(x) est écrit et on connait son initialisation (2).
// le 'et' et le 'ou' logique.
(x > 0) & ((a = 0) || (a = x)) => G(x,a) = F(x)
// Les éléments d'une liste. ici L,l1,l2 une liste d'entier
// le . représente la concaténation
L,l1,l2 : Liste
c1,c2 : entier
(c1 <= c2) => F(c1.l1,c2.l2) = c1. F(l1,c2.l2)
// Les éléments d'un tableau.
// les [] permettent d'accèder à l'élément du tableau.
// le Swap (ou échange) est représenté ici par <->
T : Tableau
i,j : entier
(T[j] < T[i]) & (i < j) => Tri(i,j,T) = Tri(i+1, j, T[i]<->T[j])
...

Voici un exemple partiel d'algorithme :
// Tri Par Insertion
T : Tableau
i,j : Entier (des compteurs)
A : Entier valeur temporaire
N : indice maximum du tableau.

Init : TPI(i,j,A,T,N) = TPI(0,1, T[1], T,N)

(j <= N) & ((T[i] > A) || (i >= 0)) => TPI(i,j,A,T,N) = TPI(i-1, j, T[i], T[i]<->T[i+1], N)
...

//La trace pour voir le fonctionnement

...

//Le calcul des ressources utilisées par l'algorithme

//Complexité temporelle : (n * (n - 1)) / 2=> O(n²) => polynomiale.
// Complexité spatiale : O(1) (pas de besoin supplémentaire donc)
// Complexité dans les déplacements ...

voilà ...;)

Citation:

---

C'est un mélange entre les mathématiques et un algèbre de Boole sur des conditions.

Je n'y ai donc pas de notions sur les pointeurs (qui seraient vue comme une fonction),
les fonctions, les procédures et encore moins les classes...
(Bien qu'il semble faire moins de propositions,
il y aurait moins de vocabulaire à connaitre et il serait plus aisé d'écrire...)

Je ne crois pas qu'un algorithme est besoin de notion de classe ou faire la différence entre une fonction et une procédure.
Si je dois utiliser des classes alors j'utilise un langage de programmation.
( c'est mon opinion pas une vérité ! )

---

J'ai des doutes sur ce que tu avances, en effet, il faudra bien à un moment ou à un autre que dans tes algorithmes tu puisses utiliser des types abtraits de données (on ne parle pas de classes, de surcharge de fonctions qui sont des domaines réservés aux langages), avec ta notation, j'aimerai bien savoir comment tu peux parler de graphes. De plus, la notation utilisée va dépendre très fortement du niveau d'abstraction auquel tu te places.

Code:

---

1 2	// J'affecte une variable à un type. (avant l'écriture de l'algorithme.) x : entier

---

Jusqu'ici ça va à peut près (ton commentaire me semble faux, on affecte pas un type à une variable).

Citation:

---

// J'affecte une variable à la valeur 2 à l'initialisation de l'algorithme.
Init F(x) = F(2)

---

Ici ça se gâte, a quoi correspond Init ? Doit on le rajouter à chacune des initialisations ? Ensuite, a quoi correspond le F ? c'est un mot clé (qui n'aurait pas de sens en algorithmique) de plus la notation est ambigüe en effet elle peut suggérer une égalité ou une affectation. Ensuite vouloir affecter 2 à x de cette façon laisse presque supposer que le paradigme de programmation que tu utilises est du lambda-calcul.

De plus, pourquoi distingues tu l'initialisation de l'affectation ?

Code:

---

1 2	// J'affecte une variable à la valeur 5 à l'appel de l'algorithme. (x > 0) => F(x) = F(5)

---

Ici ta notation est ambiguë, le symbole => peut correspondre à un opérateur de comparaison, ça ne facilite pas la lecture. Même si ta notation est assez compacte, pour la même opération je préfèrerais écrire ceci :

[code]
SI x > 0 ALORS
x <- 5
FIN SI
[\code]

Code:

---

1 2	// le 'et' et le 'ou' logique. (x > 0) & ((a = 0) || (a = x)) => G(x,a) = F(x)

---

Ici, tu te rapproches trop d'un langage de programation, pour un néophyte, savoir que || correspond au OU logique n'est pas chose aisée. De plus ici tu utilises un ET logique à un seul symbole lorsque le OU en possède deux, c'est une bizarrerie qui me semble renforcer la difficulté du "langage".

Ensuite, sur la fin de la notation :

Code:

---

G(x,a) = F(x)

---

Ici, j'ai du mal à te suivre, lors d'une initialisation F(x) = F(2) ça signifiait affecter 2 à x, or ici, tu as à gauche une fonction d'arrité 2 et à droite une fonction d'arrité un, alors je ne vois pas au premier abord ce qu'il faut affecter.

Tu dois me trouver sévère mais ce que j'avais proposé, c'est de trouver une notation qui puisse être adaptée à bon nombre d'utilisations et qui soit aussi facile d'accès pour quelqu'un qui ne fait pas d'algorithmique. Même si tout le monde semble d'accord sur le fait qu'une notation universelle n'existe pas.

Merci pour ta réponse :king: (au pluriel)

- Non je ne te trouve pas sévère, il faut être clair sinon déjà que ce n'est pas évident de se comprendre
dans une même langue alors si on se donne des difficultés ... :P

- Oui je n'affecte pas un type à une variable (il était un peu tôt (ou tard) désolé)

- Quand je marque Init F(x) = F(2) je veux indiquer que l'algorithme commence par 2
quelquesoit x et F est le nom d'un algorithme.

Par exemple un algorithme utilisant des compteurs
Disons ALGO(i, j, T) ou i et j sont des entiers utilisés comme compteurs et T un Tableau.

Init ALGO(i, j, T) = ALGO(0, 0, T).
Donc l'appel de ALGO(v,w, T) donnera ALGO(0,0, T) quelquesoit v,w.

- Je ne distingue pas l'initialisation de l'affectation,
je montrais comment affecter à une valeur dans ma notation et l'initialisation est une obligation.

Au lieu d'écrire X:=2(pascal...) ou x=2(C...) ou ...
j'écris
MesConditions => MONALGO(x,y,...) = MONALGO(2, y, ...)

- Pour les & et les || je suis d'accord il est important de lire facilement et
donc il serait mieux venu d'écrire ET et OU directement.

- Pour l'arité, ce n'était pas le but ici.

On peut trés bien avoir un algorithme qui ne dépendent que d'une partie des données présentes d'où l'appel que j'ai fait !
Ce n'était peut-être pas bienvenue car effectivement on pouvait le voir aussi comme cela.

On peut tout aussi écrire (a>x) => G(x,a) = F(x, (a-x))

Merci encore...

P.S. : Avec cette méthode d'écriture j'ai appris à voir et calculer les complexités.
Puisque l'algorithme se retrouve à être une liste de
'Pour çà => l'algo(...) = l'algo(...)'
Je peux décelé le cas Max assez rapidement.

Peut-être que d'autres méthodes le font tout aussi mieux voire mieux ! (en tout cas j'ai appris dessus :D )

Citation:

---

- Quand je marque Init F(x) = F(2) je veux indiquer que l'algorithme commence par 2
quelquesoit x et F est le nom d'un algorithme.

Par exemple un algorithme utilisant des compteurs
Disons ALGO(i, j, T) ou i et j sont des entiers utilisés comme compteurs et T un Tableau.

Init ALGO(i, j, T) = ALGO(0, 0, T).
Donc l'appel de ALGO(v,w, T) donnera ALGO(0,0, T) quelquesoit v,w.

---

Je ne comprend toujours pas pourquoi tu le fais avec le nom de tes fonctions ou procédures (ou algorithme ce qui revient aussi au même).

En fait pourquoi ne pas faire l'initialisation directement après la déclaration de la signature de ton algo.

Citation:

---

- Je ne distingue pas l'initialisation de l'affectation,

---

Si, visiblement c'est ce que tu es en train de faire, tu distingues l'initialisation de ton algorithme de l'affectation d'une variable nécessaire à ton algorithme. En fait sur ce que je comprend tu as une approche relativement orienté sur les noms des algorithmes, j'aurai tendance à avoir une orientation plus du coté des variables, ça m'aide à avoir des invariants de boucle ou de structure facilement (surtout au niveau de la lourdeur de l'écriture).

Citation:

---

Envoyé par PRomu@ld

Je ne comprend toujours pas pourquoi tu le fais avec le nom de tes fonctions ou procédures (ou algorithme ce qui revient aussi au même).

En fait pourquoi ne pas faire l'initialisation directement après la déclaration de la signature de ton algo.

Si, visiblement c'est ce que tu es en train de faire, tu distingues l'initialisation de ton algorithme de l'affectation d'une variable nécessaire à ton algorithme.

---

On peut, y a pas de soucis, j'ai appris comme cela. :D
L'habitude est tenace surtout dans l'erreur...
J'ai rien contre modifié cet aspect.
Je distingue uniquement initialisation de affectation par le mot init devant
sinon c'est la même chose (c'est pour cette raison que j'ai indiqué que je ne les distinguais pas ;) )

Citation:

---

Envoyé par PRomu@ld

En fait sur ce que je comprend tu as une approche relativement orienté sur les noms des algorithmes, j'aurai tendance à avoir une orientation plus du coté des variables, ça m'aide à avoir des invariants de boucle ou de structure facilement (surtout au niveau de la lourdeur de l'écriture).

---

Tu peux me montrer comment, je ne vois pas trop là ?

Salut à tous,

Ayant fait pas mal d'algorithmique, je trouve quelques unes de vos réponses un peu bizarre... (je sais, vous allez dire "le mec, il est même pas membre du club, il a écrit 4 pauvres messages, et il arrive tranquille..." ^^)
Bref, je me permets de rentrer dans cette discussion, parce qu'il me semble que l'algorithmique est quelque chose d'absolument intéressant. (vous allez penser "le fou !!!" :aie: ) En fait, dans la plupart des cours que j'ai eu, on écrivait des algo de la façon la plus proche possible du langage naturel. Je m'explique :
Quand on déclare une variable, on écrit

Code:

---

Entier x

---

Pour les affectations de variables, il est vrai qu'il est préférable de les démarquer des tests d'égalité, c'est pourquoi je préfère le

Code:

---

x := valeur

---

Les structures de controle doivent avoir des "début" et des "fin"

Code:

---

1 2	POUR i allant de 0 à 10 FAIRE <div style="margin-left:40px">BEGIN</div><div style="margin-left:40px">...</div><div style="margin-left:40px">END</div>FINPOUR

---

Généralement, plutôt que d'écrire

Code:

---

x = F(y)

---

On préfère détailler ce que fais la fonction et y ajouter ces paramètres du genre

Code:

---

trier le tableau T en partant de l'indice i

---

Enfin, tout ces manières de faire peuvent sembler étrange, mais à la relecture de l'algorithme, même quelqu'un qui n'a jamais fais de programmation (ou autre choses velues :mouarf: ...) arrive facilement à comprendre l'algo

Voila, ce sera ma petite comtribution à ce topic ^^

:king:

Merci pour ta contribution Gueritarish :king:

Je comprends ce que tu veux dire !
J'ai fait de l'algorithmique comme cela avant et
elle (l'algorithmique) était présentée comme cela pour
s'harmoniser avec un langage de programmation qu'on allaient apprendre après (le pascal) ...

C'est lisible mais pas trés efficace pour calculer les complexités, (détection de cas max, d'appel à d'autres algorithmes ...)
j'ai essayé, mais sinon c'est plus proche d'une langue maternelle c'est sûr ! :P

Comme pour les algorithmes on veut aussi calculer leur performences,
il est intéressant de se poser la question de l'écriture au niveaux de la visibilité des calculs dans ce domaine.

Par suite aussi pour écrire dans un langage commun, nous devons nous rapprocher d'un langage commun.

+ n'est pas écrit différement dans les autres langues ?
mais 'trouver l'élément' n'est pas lisible pour quelqu'un ne parlant pas le français.

Or ce que l'on cherche c'est d'avoir une méthode plus universelle et intuitive
quelquesoit le contexte (langue, langage) de la personne qui lira l'algorithme aprés celui qui l'ai écrit.

Le but étant, je crois le partage d'informations et sa vulgarisation ! ;)

Citation:

---

Or ce que l'on cherche c'est d'avoir une méthode plus universelle et intuitive
quelquesoit le contexte (langue, langage) de la personne qui lira l'algorithme aprés celui qui l'ai écrit.

---

On a pu voir dans un autre post qu'un langage unique et universel pour décrire un ou des algorithmes n'était pas possible. Je te renvoie à la discussion suivante :

http://www.developpez.net/forums/sho...d.php?t=263397

Citation:

---

C'est lisible mais pas trés efficace pour calculer les complexités, (détection de cas max, d'appel à d'autres algorithmes ...)
j'ai essayé, mais sinon c'est plus proche d'une langue maternelle c'est sûr !

Comme pour les algorithmes on veut aussi calculer leur performences,
il est intéressant de se poser la question de l'écriture au niveaux de la visibilité des calculs dans ce domaine.

---

On peut très bien se servir de la notation de Gueritarish pour calculer la complexité d'un algorithme, le tout est je pense une question d'habitude.

Citation:

---

On peut très bien se servir de la notation de Gueritarish pour calculer la complexité d'un algorithme, le tout est je pense une question d'habitude

---

Tout à fait d'accord avec toi (et donc avec moi...8O bizarre)

Dans le principe de ma notation, il s'agit en fait d'écrire un algo par raffinage successif. Je m'explique, on peut écrire

Code:

---

Trier le tableau T

---

Puis dans un autre raffinage, expliquer la méthode de trie.

Enfin, voilà, il est vrai que c'est une question d'habitude, mais on peut calculer la complexité de manière assez simple une fois que toutes les parties de l'algo on était raffiné.

Je sais pas si vous m'avez tous suivi, mais c'est une notation possible :mrgreen:

Citation:

---

Puis dans un autre raffinage, expliquer la méthode de trie.

---

Oui, il faut adapter la verbosité de l'algorithme en fonction du niveau d'abstraction auquel on veut se placer et aussi dont on a besoin.

Biensûr qu'avec n'importe quelle notation on peut, avec ou sans expérience, calculer la complexité. :mouarf:

Oui un langage unique et universelle n'est pas possible ! :mouarf:

Cependant, tu devras re-écrire ton algorithme dans chaque langues pour qu'il soit compris par tous. :P
Ou faire comme les anglais avoir un "monopole linguistique".
(Bien que ce forum soit francophone, l'idée principale est le partage, non ?
C'est dans cette optique que je propose cette différence de point de vue !)

Un algorithme peut s'expliquer en idées avec des mots,
donc lié à une langue ou être traduit dans un langage.

Quelle est la notation recherchée ici ? le français ou une méthode d'écriture
permettant à tous de reconnaitre des idées ?

D'où j'en ai conclu pas de lien entre l'algorithmique et les langues.

Nous pouvons aussi nous lier avec un langage de programmation ((pascal, C, Java, ...)
mais je ne crois pas que cela fera une bonne chose.
L'algorithmique doit être, en mon sens :aie:, une liste d'opérations d'idées représentées par des structures de données et uniquement cela !
Pourquoi l'algorithmique devrait se poser les questions sur la notion d'objet ou encore sur la portabilité d'une variable !

Je pense que ces notions (intéressantes) doivent rester à leur place, dans les langages !
D'où j'en ai conclu pas de lien entre l'algorithmique et les langages informatiques.

Voilà ... ;)

Citation:

---

L'algorithmique doit être, en mon sens , une liste d'opérations d'idées représentées par des structures de données et uniquement cela !
Pourquoi l'algorithmique devrait se poser les questions sur la notion d'objet ou encore sur la portabilité d'une variable !

---

N'y aurait-il pas un léger lien entre la notion d'objet et de structure de donnée, si on accepte l'un on doit accepter l'autre.

Comme on a pu le voir dans le lien que j'ai mentionné plus haut, la façon dont tu veux décrire ton algorithme devrait être différente suivant le paradigme de programmation utilisé. Si tu utilises un paradigme fonctionnel ou logique, tu ne va pas présenter la chose de la même façon que dans un paradigme itératif.

Quand je parle de notion d'objet, je sous-entends ( ce n'était pas claire :oops: ) les questions qui peuvent adhérer.

Pour moi, un objet est définit par une structure de données... d'où le lien ;) .

Mais, je ne souhaite pas intégrer l'objet plus en avant dans la notation,
afin de rester dans une lisibilité du code malgrès le manque de vocabulaire pour certaines notions.

En fait, au lieu d'écrire simplement un objet par une notation apropriée,
je préfère avoir une fonction y faisant référence.

C'est plus long, dans le sens ou l'on cherche à savoir ce que représente l'algorithme,
cependant cela n'alourdit pas la base des connaissances à partager,
et le code écrit devient plus une spécification qu'une connaissance de base
à acquérir en plus dans un vocabulaire de base peut-être déjà trop lourd...:aie:

Par contre j'aurais une question sur le lien entre
l'algorithmique et les paradigmes de programmation.

Peut-on être indépendant des paradigmes ?
Il me semble que non ! D'où , il faudrait savoir lequel serait le plus apte à être lu ?

Dans la méthode que j'utilise :
Conditions => fonction(paramètres) = fonction(paramètres)

On peut clairement voir si tout les cas on été vérifiés en faisant une tableau de Karnaugh.
par exemple la condition (i<0) => algo1(i) = algo1(i+1)
on peut voir qu'il nous manque également les tests sur
(i=0) et (i>0) que l'on peut vérifier aussi !

Si notre algo1 ne nécessite pas de ces deux conditions supplémentaires
alors on aura tester tout les cas pour cette condition.8O
(mais que ferait-il avec i=0 et i>0 ? pas de conditions d'arrêt !)

Dans un cas moins simple :
(i>0) et (j<i) ou (k=j) par exemple
il y aura beaucoup plus de cas à vérifier ...
De cette manière on voit les bornes (i = 0) (j = i) ...
mais le nombre de cas à vérifier vas croissant et même beaucoup plus (ici 3^3 => 27 cas au minimum) :aie:
(i = 0), (i < 0), (i > 0) et
(j = i), (j < i), (j > i) et
(k = j), (k < j), (k > j)

Peut-être est-ce tous => pas de cas de bornes supplémentaires du style (j = k-i) ou d'autres joyeusetés...:aie:

On peut aussi éliminer des cas impossibles comme (i<0) => 9 cas en moins...

Qu'en pensez-vous ...

Citation:

---

En fait, au lieu d'écrire simplement un objet par une notation apropriée,
je préfère avoir une fonction y faisant référence.

---

Ici, tu restes sur un paradigme impératif, ça ne pose cependant pas trop de problème.

Citation:

---

Peut-on être indépendant des paradigmes ?
Il me semble que non ! D'où , il faudrait savoir lequel serait le plus apte à être lu ?

---

La question n'est pas une question de lisibilité. Si tu fais du lambda-calcul pur, tu ne peux pas utiliser les structures FOR, IF, ... . Les utiliser représenterait une erreur, en fait tu auras une notation par paradigme, et on ne parlera pas de lisibilité.

Citation:

---

Envoyé par O( N )

Par contre j'aurais une question sur le lien entre
l'algorithmique et les paradigmes de programmation.

Peut-on être indépendant des paradigmes ?
Il me semble que non ! D'où , il faudrait savoir lequel serait le plus apte à être lu ?

---

Par définition, les algorithmes sont: "une suite d'opérations permettant de résoudre par calcul un problème." (wikipedia)

Dès lors, il ressort un aspect "séquentiel" dans les algorithmes. Et donc la programmation impérative semble la plus naturelle.

De toutes facons, de part la nature des processeurs actuels, tout programme finit par etre executé comme une suite séquentielle d'instruction. Ne pas utiliser une description "impérative" pour un algorithme ne fait que repousser le probleme. Tot ou tard, le programme devra etre "serialisé", que ce soit par le compilateur, le run-time, ou l'OS.

Utiliser une description non-impérative, spécifique a un langage n'est plus de l'algorithmie (a mon sens). Ca ressemble plus a un "snippet".

Citation:

---

Utiliser une description non-impérative, spécifique a un langage n'est plus de l'algorithmie (a mon sens).

---

Donc un algorithme récursif n'a pas de sens selon toi ? De plus, lorsque les processeurs futurs fonctionneront suivant un mode quantique (je sais, nous n'y sommes pas encore), faudra-t-il réécrire tous nos algorithmes suivant ce mode de pensée ?

Je pense que le principal problème est que nous raisons tous sur un modèle plus ou moins proche d'une machine de Turing, mais il ne faut pas oublier qu'il ne s'agit pas du seul modèle.

Citation:

---

Envoyé par PRomu@ld

Donc un algorithme récursif n'a pas de sens selon toi ?

---

Ca a un sens tant que l'algorithme utilise des fonctions récursives primitives.

Pour moi, l'ecriture recursive est une maniere élégante (= compacte) pour décrire un algorithme itératif de profondeur variable (quicksort, hanoi, ...).

Non que je veuille critiquer les dialogues, mais il serait intéressant d'avancer un peu
et de ne plus discuter autour de ce sujet ! :D

Avez-vous choisie une notation pour laquelle nous pourrions déjà voir des résultats
(pas une précédente notation qui était 'un défaut' avant cette discussion) ? :P

Où sinon pourrait-on écrire des algorithmes simples sous différentes notations
et les faire comparer par autruis pour trouver la notation la plus cohérente ! :mouarf:

qu'en pensez-vous ... ;)

Salut !

Vu qu'il n'est rien proposé depuis un bail, je (re)propose ceci : souligner les mots-clés, indenter, commenter comme C, C++, Java, Pasca, etc. c'est-à-dire selon le langage cible et donc se limiter à :

Code:

---

// ça, sur 1 ligne

---

Code:

---

1 2	/* ça sur plusieurs lignes */

---

Code:

---

1 2	(* ou ça *)

---

Code:

---

1 2	/** éventuellement ça pour de la doc, mais on entre plutôt dans la programmation et de toutes façons, c'est égal au 2e. */

---

On devrait permettre l'utilisation des accents, ligatures (œ, etc.) et autres symboles diacritiques (ç, etc.) puisque l'on parle français* ou des lettres grecques, éventuellement, pour ceux qui arrivent à les taper, mais c'est tout.

Voici donc une petite application :
pour une fonction :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

fonction maFonction(élément : Entier, truc : Réel) : Entier i <- 0 // affectation tant que i < 20 faire i <- i + 1 ftq // fin tant que retourne i fin lexique i : Entier, variable temporaire

---

Pour une procédure (ES = entrée/sortie):

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procédure échangerVariables(ES x : Entier, ES y : Entier) tmp <- x x <- y y <- tmp fin lexique tmp : Entier, variable temporaire pour permettre l'échange x : Entier, premier paramètre qui sera remplacé par y y : Entier, second paramètre qui sera remplacé par x

---

Pour une classe (si nécessaire, on peut toujours la définir, on sait jamais) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

classe Arbre /** Un attribut */ attribut : Entier /** Un nœud de l'arbre. Il est aussi un arbre. */ nœud : Arbre constructeur(toto : Entier) // corps du constructeur fin finclasse

---

* : À moins de ne pas le faire en français mais dans une langue construite (espéranto, lojban, etc.), comme ça pas de jaloux, elles ne sont langues nationales d'aucun pays. :D

Citation:

---

Vu qu'il n'est rien proposé depuis un bail,

---

Ca n'est pas parce que rien n'a été proposé qu'il faut se forcer, si on a rien à ajouter de plus. ;)

J'ai des doutes sur l'utilisation de blocs de commentaires, je suis plus pour les commentaires c++ ou ada, il débute et se finissent par la fin de ligne, ça permet d'éviter les ambiguïtés.

Citation:

---

On devrait permettre l'utilisation des accents, ligatures (œ, etc.) et autres symboles diacritiques (ç, etc.) puisque l'on parle français* ou des lettres grecques, éventuellement, pour ceux qui arrivent à les taper, mais c'est tout.

---

Oui, dans la mesure où on ne multiplie pas les symboles (trop de symboles tuent les symboles).

Citation:

---

Pour une classe (si nécessaire, on peut toujours la définir, on sait jamais) :

---

J'aimerai qu'on évite la notion de classe en algo, je trouve ça trop proche des langages. Je préférerais qu'on parle de notion d'objet.

Salut,

A titre personnel, j'utilise le nassi-schneiderman quand je dois créer un algorithme, et je comprend bien qu'il est difficile d'imposer ce point de vue, ne serait-ce que ca fait appel aux "petits dessins"...

Aussi, quand il s'agit de transmettre l'idée de manière verbeuse plutot que de manière imagée, je crois que la solution la plus simple et la plus compréhensible sera toujours la solution la meilleure ;)

N'oublions pas non plus que la balise CODE permet une coloration synthaxique -du moins, dans les autres sections, et on peut regretter le fait qu'il faille préciser le langage utilisé dans celle-ci - qu'il me semble intéressant d'utiliser, car, l'un dans l'autre, tout ce qui peut donner une indication supplémentaire (le fait qu'il s'agisse d'un commentaire, pour aider à comprendre ce qui est fait, par exemple) sera de nature à faciliter la compréhension... ce qui est le but recherché.

Il est, à mon sens, impossible d'envisager de mettre tout le monde d'accord sur une notation trop fixe, justement, parce que la grande partie des propositions sera issue plus ou moins directement inspirée de ce qui est fait dans un langage ou un autre, particulièrement adaptée à ce langage, mais potentiellement désastreuse dans un autre.

Pour les structures de tests et de boucle, je suis d'avis que le début et la fin des structures doivent etre tres clairement définies, ce qui m'inciterait à répéter ce qui a déjà été proposé: majuscule et indentation, avec marqueur explicite de fin de structure:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

SI truc = bidule ce qui doit etre fait SINON ce qui doit etre fait FIN SI POUR a=0 à 10 ce qui doit etre fait FIN POUR TANT QUE test ce qui doit etre fait FIN TANT

---

L'affectation est à mon sens plus claire, et visiblement admise par tous, si on l'indique avec <-

Code:

---

a <- nouvelle valeur

---

L'acces à un élément de structure - que ce soit une valeur/sous structure ou l'appel d'une fonction - peut tres bien etre représenté sous la forme de -> ou de .: aucune des solutions ci-dessous ne pose réellement problème à mon sens

Code:

---

1 2 3 4 5

a -> suivant <- b -> precedent a.suivant <- b.precedent a <- b->LaFoncitonQuiFaitTruc(valeur) a <- b.LaFonctionQuiFaitTruc(valeur)

---

Les commentaires sont souvent les bienvenus, pour toute une série de raisons...

Comme je l'ai indiqué plus haut, la balise CODE fournit une coloration synthaxique qu'il serait, à mon sens, domage de ne pas utiliser...

Maintenant, il n'y a, à mon sens, pas énromément d'intéret à se chamailler pour savoir si la notation C est meileure que la notation VB ou delphi, ou pire, à inposer d'écrire un Commentaire: (...)

Code:

---

1 2 3 4

/* ceci est un commentaire en C */ // ceci est un commentaire en C++ /* un commentaire en COBOL est indiqué par l'étoile en position 7... */

---

Pour l'introduction aux procédures/fonctions, j'apprécie de fournir les indications pertinantes avant meme de fournir le prototype de la fonction... Encore une fois, la coloration synthaxique des commentaires peut nous venir en aide:

Code:

---

1 2 3 4 5 6 7 8

/* Fonction dont le but est de (...)  * @in: nom et type du premier parametre  * nom et type du deuxieme parametre  * ...  * @out: type du retour éventuel  */ type retour LaFonction(param1, param2, param3)

---

De la meme manière, je n'ai aucun scrupule, si le nombre de variables utilisées est important, ou si l'existance de plusieurs variables d'un meme type sont de nature à rendre la compréhension incertaine, à quarrément préciser leurs nom, types et utilité:

Code:

---

1 2 3 4 5 6 7 8 9

/* SOIT a est un pointeur sur entier servant à (...)  * b est un (...) servant à (...)  */ /* debut: pointeur sur structure de type (...) utilisé pour garder une trace du   début de la chaine   fin: pointeur sur structure de type (...) utilisé pour garder garder une   trace de la fin de la chaine  */

---

Au delà des quelques remarques déjà faites sur la représentation des structures de controle et sur l'affectation, cela ne me dérange absolument pas de laisser libre cours aux préférences de chacun pour les autres conventions.

On pourrait, effectivement, essayer de généraliser l'une ou l'autre habitude - de commenter son algorithme, par exemple - mais, toute tentative d'ériger des regles trop strictes à la présentation d'un algorithme serait, à mon sens, contre productive ;)

Je ne vois pas trop l'interet de réinventer une enième syntaxe de langage imperatif, structuré par block, ...

J'ai l'impression que vous refusez d'utiliser la syntaxe d'un langage connu (basic, c/java, ...) sous pretexte de respecter la sacro-sainte règle d'indépendance entre algo et langage. A mon sens, ce n'est pas parcequ'un algo est indépendant du langage qu'il est INTERDIT de le définir dans un langage donné (et connu).

Ce qui devrait etre "interdit" c'est juste d'utiliser les fonctionalités spécifiques d'un langage (comme la reflexion, la definition dynamique, ...).

Parceque si c'est juste pour remplacer

Code:

---

1 2 3 4

FOR a=0 TO 10 ce qui doit etre fait NEXT

---

par

Code:

---

1 2 3 4

POUR a=0 à 10 ce qui doit etre fait FIN POUR

---

je ne vois pas la "valeur ajoutée"... :roll: