Bonjour,
Sur Wikipedia on trouve ça:
Pièce jointe 584593
Mais si le traitement 1 (ou un autre) modifie les termes de la condition, cette représentation est-elle pertinente:
Pièce jointe 584594
Version imprimable
Bonjour,
Sur Wikipedia on trouve ça:
Pièce jointe 584593
Mais si le traitement 1 (ou un autre) modifie les termes de la condition, cette représentation est-elle pertinente:
Pièce jointe 584594
Ton dessin évoque plus ou moins un comportement du type :
Mais il faudrait supprimer le trait qui sort de traitement1 vers le bas.Code:
1
2
3
4 TantQue <condition> exécuter traitement1 Fin TantQue Exécuter traitement2.
Après traitement1, on retourne systématiquement vers le losange qui symbolise le test 'Si <Condition>'.
Un rectangle qui a 2 sorties, ça n'existe pas dans ce genre de représentation. Il faut un test qui dit quelle sortie emprunter.
Les lignes sont donc obligatoirement des branchements ?
Et on ne peut pas représenter de lien entre une modification des termes d'une condition et cette condition ?
J'ai l'impression que tu racontes un peu n'importe quoi, mais comme je ne pratique pas du tout ces logigrammes, je passe la main.
Bonjour :coucou:
Non. Elle n'est pas pertinente, car tu n'as que 2 branchements possibles. Fabriquer une troisième voie n'a de sens que si tu pointes vers un troisième bloc de traitement.Citation:
cette représentation est-elle pertinente ?
De plus, la condition est évaluée à une date donnée. Ce qui se passe avant ou après n'est pas pris en compte.
Bonjour,
Non, si ta condition est modifiée par ton traitement, alors elle ne peut plus être affectée à la même représentation. Il s'agit donc d'un nouveau test...
@ Flodelarab et Galet:
Vous êtes clairs, mais c'est quand même étonnant qu'on ne puisse pas relier une condition à une commande qui lui envoie du paramètre, en considérant qu'une condition a une sortie (à droite) et une entrée (à gauche).
Donc la gauche et la droite d'une condition sont des sorties ? Et n'y a pas d'entrée autre que par le haut ?
Ce n'est pas une question de pouvoir ou non, c'est une question de savoir quelle signification donner à ça. Tout va dépendre de ce que tu entends par «relier une condition à une commande qui lui envoie du paramètre», hormis le fait bien sûr de rajouter un lien dans un organigramme. Que signifie ce lien dans ton esprit ? Peut-être pourrais-tu nous donner un exemple de ce que tu penses pouvoir exprimer avec ça ?
Est-ce que ça serait quelque chose du genre :
Si c'est cela alors cela revient à faire une boucle tant que.Code:
1
2
3
4
5
6
7
8 calc_cond: condition = f(param1, param2, ) si condition alors modifier(param1, param2, ) aller en calc_cond sinon faire autre chose fin si
Mais c'est peut-etre autre chose dans ton esprit ?
- Ah bon ? Parce que, toi, tu lis un texte autrement que de haut en bas ? Le programme informatique, c'est pareil, et le logigramme qui en découle aussi. Du haut, vers le bas.
- D'ailleurs, tu n'as pas indiqué le sens de circulation sur tes traits, ce qui enlève toute signification.
- Il ne faut pas voir l'entrée comme une donnée unique mais comme un faisceau de données. Tu peux bien avoir un millier d'informations en entrée.
Si une condition subit l'influence d'un paramètre, tout cela est déterminé avant le dessin que tu as posté. Ce sont les éléments précédents.Citation:
relier une condition à une commande qui lui envoie du paramètre,
Par exemple conserver une valeur d'un premier passage
...prog Clic et re-clic
Si flag=1 aller à [passer]
...prog prises de cotes xa, ya
...prog
flag=1
[passer]
...prog prise de cotes xb, yb
Après n clics j'aurai les premières cotes et les dernières.
Suite du 15h17
Si je fais ça, c'est compréhensible ?
Et qu'est-ce qu'on comprend ?
Pièce jointe 584765
Tu as essayé de rentrer dans une pièce par le mur et tu as écrasé ton petit nez.
Un schéma valide serait celui-ci :
Pièce jointe 584767
Bonjour,
Le but du logigramme est de formuler une méthode sans être sujet à interprétation. Si tu dois le compléter par une explication, c'est que la représentation n'est pas claire...donc que la compréhension n'est pas claire.
Si tu n'arrives pas à schématiser une idée, c'est, soit qu'elle n'est pas claire, soit qu'elle est géniale au point de remettre en cause les bases. Il faut reconnaitre que c'est souvent le premier cas qui s'applique.:D
Les règles ont donc 2 grands avantages :
- faire remonter des incompréhensions (qui risquent de se transformer en problèmes ou en bug)
- servir de communication avec d'autres programmeurs (pour partager une tâche ou simplement avoir de l'aide)
Belle journée...
Ah Ok.
Et est-ce que ça c'est valide ? (le petit rectangle est l'endroit ou la variable de test est modifiée)
Pièce jointe 584834
Les graphes sont déformables. Dans la boucle, que tu mettes 1, 2 ou 3 blocs, à gauche en montant, ou à droite en descendant, c'est pareil. Tu pourrais même résumer tes 3 blocs en un. C'est comme les données évoquées précédemment : un bloc n'est pas 1 instruction, mais un ensemble d'instructions.
Quand on voit ce dessin, on comprend qu'on sera prisonnier de la branche qui boucle, jusqu'à ce qu'on s'enfuit à droite. Et on s'enfuira à droite quand la condition sera remplie ( ou non remplie, si un "faux" est nécessaire ).
On appelle ça «une boucle tant que» …
Et on le retrouve même sur la page wiki citée par le PO.
Connais-tu le brainfuck ? C'est un langage de programmation qui a, en tout et pour tout, 8 instructions :
- avancer dans la mémoire
- reculer dans la mémoire
- incrémenter la mémoire
- décrémenter la mémoire
- début de boucle
- fin de boucle
- entrée
- sortie
Et avec ces instructions, on pourrait refaire tous les logiciels du monde. Je rappelle cela pour montrer que la "boucle" sert de condition, de boucle "for", de boucle "tant que", etc. Tout ça, c'est pareil. Et il faut le comprendre.
Tu dis ne pas aimer la boucle "tant que". Mais quand on écrit for (i=0;i<n;i++), c'est bien une boucle "tant que" avec une initialisation (i=0), une condition d'arrêt (i<n) qui est l'échappatoire de la boucle. Et un incrément (i++).
Code:++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Pourquoi je n'aime pas les "Tant que"
Méthode avec "If":
Méthode avec "Tant que":Code:
1
2
3
4
5
6
7
8
9 clic et re-clic Si flag =1 alors-->passer--> Lecture cote xa, ya -->Passer lecture xb, yb suite du prog ... prog...
Où tu place le Fin tant que ?Code:
1
2
3
4
5
6
7
8
9 clic et re-clic Tant que flag=0 Lire xa,ya Flag =1 Lire xb, yb Suite du prog ... prog...
Dans certains langages, il y a les boucles WHILE et les boucles UNTIL, et il y a même 2 formes possibles pour les boucles WHILE.
J'ai découvert les 2 en même temps, dans la même page de cours ou à peu près. Et c'est certainement une très mauvaise idée sur un plan pédagogique.
Très vite, j'ai fait mon choix : Pas de boucle UNTIL. Et je n'ai aucun problème avec les boucles WHILE. Plus précisément, je n'utilise les boucles While que sous la forme que j'appelle basique.
A titre d'exercice, je saurais passer de l'un à l'autre, mais ça demande une gymnastique que je considère inutile.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 ' Forme basique While condition Faire traitement fin While ' Forme n°2 Faire traitement while condition ' Exemple avec Until Faire traitement Until condition ' La forme des années 1950, avec SI et GOTO. Début : Traitement Si condition goto Début
La forme basique peut aussi s'écrire comme ci-dessous, si on aime les GOTO :
L'exemple classique, pour la lecture et le traitement d'un fichier :Code:
1
2
3
4
5 Début : si condition faire Traitement Goto début. Fin si
Je peux comprendre le traumatisme de Valentin03.Code:
1
2
3
4
5 Lire PremièreLigne Tantque LectureRéussie Traiter Ligne Lire LigneSuivante Fin Tantque
On a 3 formes possibles avec WHILE au début, WHILE à la fin, ou UNTIL
Si comme l'âne de Buridan, on n'arrive pas à choisir entre ces 3 organisations, on peut y perdre beaucoup de temps, et faire des trucs faux.
Je pense que dans l'enseignement actuel, on ne parle plus que de la forme que j'appelle basique.
Cet exemple n'a pas de sens puisque la valeur de flag ne dépend pas des valeurs qui sont lues... La sortie de boucle est connue et tout ce code ne sert à rien sauf dans le cas où flag est déjà différent de 0 avant le tant que. Un simple If Flag=0 alors lire xa,Ya suffit.
A la différence d'une boucle For dont la variable de comptage est gérée par le langage, les boucles "jusqu'à" et "tant que" partent de l'apriori que l'on ne connait pas, à l'avance, le nombre de cycles. La variable de bouclage doit donc être modifiée par le programme (souvent par ce qui se trouve dans la boucle mais pas obligatoirement)
Belle soirée...
Même 4. Puisque de la même manière, UNTIL peut être au début ou à la fin.
La différence entre WHILE et UNTIL est que la condition de sortie de la boucle doit être fausse pour l'un, et vraie pour l'autre. Il n'est donc pas utile de créer une instruction UNTIL puisqu'il suffit d'inverser la condition.
Par contre, je regrette que trop de langages ne permettent pas de choisir la condition au début (sans tour de boucle), ou à la fin (après un premier tour de boucle). Ça, c'est une distinction utile. Plus utile que la différence entre WHILE et UNTIL.
Une fois que l'on est programmeur chevronné, je suis d'accord avec toi, cette possibilité de mettre la condition en fin de bloc et non en début, c'est un plus.
Mais j'ai vraiment ce souvenir, quand j'ai appris la programmation d'avoir galéré, à cause de ces 3 options pour le même besoin.
En principe , un besoin = une réponse ( If pour un test, While pour une boucle, CALL pour un appel à un sous-programme ... ...)
Et là, pour un seul besoin, on m'a enseigné d'un coup 3 solutions. Et pour la 1ère fois, je n'ai pas eu 20/20 à l'exercice, j'ai été traumatisé à vie (peut-être que j'exagère un peu). Donc, pédagogiquement, il faut enseigner une seule syntaxe ... TantQue Condition, faire Traitement.
Quitte à proposer plus tard, quand les choses sont acquises, l'autre forme.
Je différencie bien le côté apprentissage, initiation d'une part, et le côté professionnel d'autre part.
La réaction de Valentin03 est typiquement liée à ce problème. Il a lu ou il a appris que dans une boucle TantQue, le test de sortie pouvait être fait avant ou après le traitement... A priori, c'est une option de plus, donc c'est une facilité. Mais à l'arrivée, c'est une option de plus, donc c'est une complexité.
Bonsoir,
la construction des boucles "a l'envers" n'existe pas dans tous les langages et elle est moins lisible que la lecture :
1- tant que ça est vrai, on fait une action
2- On fait une action jusqu'à ça devienne vrai
Pour la formation, comme pour l'algo, c'est directement traçable et programmable. On voit aussi, facilement que la différence la plus importante est que l'action sera obligatoirement exécutée au moins 1 fois dans le cas 2, ce qui n'est pas vrai dans le cas 1.
Il existe encore des langages qui ne proposent aucune de ces 2 boucles en utilisant force de Goto ou Jump...
Mieux vaut avoir trop de choix (pour prendre celui qui convient au besoin et à sa logique) :)
Cordialement,
L’algorigramme (logigramme, organigramme, ordinogramme) est sensé précéder le codage et non l’inverse. Cela dit, l’algorigramme construit à partir d’un programme déjà codé ne devrait pas être différent de l’algorigramme qui aurait dû précéder la programmation. Encore faut-il que la méthode de programmation ayant inspiré le codage corresponde à la réflexion qui inspire la construction à postériori de l’algorigramme.
La représentation graphique du raisonnement doit être indépendante du langage, de ses spécificités, et doit permettre d’appréhender aisément les fonctionnalités du programme. Représenter graphiquement son raisonnement n’est pas la même chose que représenter graphiquement son codage.
On ne construit pas un algorigramme en fonction des instructions du langage que l’on utilise. C’est à la programmation d’interpréter et de traduire l’algorigramme. L’algorigramme reste le même, quelque soient les instructions qu’offre le langage, « IF THEN ELSE », « FOR », « WHILE », « GO TO », etc.
Le « logigramme », autre appellation de l’algorigramme dit bien ce qu’il veut dire, à savoir que c’est une représentation graphique de la logique, donc du raisonnement. Il appartient ensuite au codage de concrétiser cette logique à l’aide d’instructions. La décomposition de l’algorigramme devrait rester au niveau logique des traitements sans descendre jusqu’à l’instruction. Tout dépend de la capacité d’abstraction du programmeur.
Réaliser un algorigramme suppose l’utilisation d’une symbolique qui dépend de la méthode de programmation utilisée, si tant est qu’il y en ait une :
- Norme ISO 5807
- Méthode CORIG (COnception et Réalisation de l'Informatique de Gestion – Robert Mallet, 1967-68)
- Méthode PS (Arbre programmatique et Programmation Structurée – Marie-Thérèse Bertini et Yves Tallineau, 1978)
- Méthode LCP (Logique de Construction de programmes – Jean-Dominique Warnier, 1970-71)
La norme ISO 5807 n’est pas une méthode de programmation, c’est un ensemble de symboles de traitement et de condition de traitement représentant chacun une instruction ou un ensemble d’instructions :
- Symbole général « traitement » : Opération ou groupe d’opérations sur de données, instructions, etc.
- Fonction de sous-programme : Portion de programme considérée comme une simple opération.
- Entrée - Sortie : Mise à disposition d’une information à traiter ou enregistrement d’une information traitée.
- Préparation : Opération qui détermine partiellement ou complètement la voie à suivre dans un embranchement ou un sous-programme. Symbole également utilisé pour préparer une décision ou mettre un aiguillage en position.
- Embranchement : Exploitation de conditions variables impliquant le choix d'une voie parmi plusieurs. Symbole couramment utilisé pour représenter une décision ou un aiguillage.
Cette norme interprète le codage sans règle particulière de raisonnement, elle ne symbolise pas une réflexion indépendante du langage résultant d’un raisonnement méthodique. C’est comme s’exprimer en mode prose (forme ordinaire du discours qui n’est soumise à aucune règle) plutôt qu’en mode poésie (forme des mots disant plus qu'eux-mêmes par leur choix (sens et sonorités) et leur agencement (rythmes, métrique, figures de style).
La méthodologie « LCP » structure le raisonnement selon une démarche par traitements, en analysant la problématique dans une approche top-down (du plus global vers le plus détaillé, par décompositions hiérarchiques successives). La représentation graphique de ce raisonnement adopte une symbolique à base de deux structures types, la structure itérative (répétitive) et la structure alternative. Lorsque les deux structures s’imbriquent, on appelle cet ensemble, une structure complexe.
La construction d’algorigrammes LCP ne se fait qu’en phase d’apprentissage de la méthode, à savoir pendant quatre à six mois selon le degré de résistance à passer d’un mode de réflexion par conditionnements à un mode de réflexion par traitements. Une fois acquis les principes LCP, il n’est plus nécessaire de représenter graphiquement son raisonnement devenu un automatisme imprimé dans la mémoire procédurale.
La séquence codée de Valentin03 que l’on devine se traduit en LCP ainsi :
D_POG et F_PROG peuvent se traduire par un « WHILE » ou un « FOR »┌─────────────────────┐ │ D_PROG │ └──────────┬──────────┘ ├────────────────────────────────────┐ ┌──────────┴──────────┐ │ │ D_TRAIT │ │ └──────────┬──────────┘ │ ┌────────────────────◊────────────────────┐ │ ┌──────────┴──────────┐ ┌──────────┴──────────┐ │ │ TRAITEMENT_1 │ │ TRAITEMENT_2 │ │ └──────────┬──────────┘ └──────────┬──────────┘ │ └────────────────────┬────────────────────┘ │ ┌──────────┴──────────┐ │ │ F_TRAIT │ │ └──────────┬──────────┘ │ ◊────────────────────────────────────┘ ┌──────────┴──────────┐ │ F_PROG │ └─────────────────────┘
D_TRAIT peut se traduire par un « IF THEN ELSE »
Représentation en algorigramme LCPCitation:
Exercice
Faire deviner un nombre (entre 1 et 100, choisi préalablement par vous) par votre programme, en moins de coups possible.
Parmi les algorithmes imaginables, le plus simple consiste à procéder par dichotomie, c'est-à-dire que le programme va à chaque moment proposer comme nombre celui qui se trouve juste au milieu des deux extrêmes possibles.
Par exemple, au tout début, les deux extrêmes étant 1 et 100, il proposera 50.
[B]NB Une variante plus divertissante du programme consiste à lui faire choisir au début un nombre aléatoire entre 1 et 100, différent bien sûr du nombre choisi. Ainsi les séquences de recherche sont-elles plus variées qu’avec un départ systématique à 50…
Imaginons que vous ayez pensé au nombre 23.
Quand le programme demandera si c’est 50 (son tout premier choix), vous lui répondrez (honnêtement) « Non, 50 est trop grand. »
À ce moment-là, le programme est assuré d’une chose : les extrêmes possibles sont dorénavant 1 et 49, au lieu de 1 et 100.
Il proposera alors le nombre juste au milieu de 1 et 49 : 25.
Et ainsi de suite.
Source : Cet exercice est extrait d’un document « Bases de Programmation » (1998-1999) du Pr. Éric Kirsch.
Dans ce document, l'exercice fait l'objet d’une analyse organique comparative :
- En Pseudo-Code
- En Arbre Programmatique,
- En Algorigramme Norme ISO 5807,
- En Langage Pascal.
NB : J’ai pensé à télécharger ce document mais j’ai perdu le lien internet.
Représentation en codage compréhensible┌─────────────────────┐ D_PROG │ CTR = 0 │ │ MINI = 1 │ │ MAXI = 100 │ │ NBRE = 1<n>100 │ │ CHOIX = n │ └──────────┬──────────┘ ├────────────────────────────────────┐ ┌──────────┴──────────┐ │ D_TRAIT │ NBRE :: CHOIX │ │ └──────────┬──────────┘ │ < ┌────────────────────◊────────────────────┐ > │ ┌──────────┴──────────┐ ┌──────────┴──────────┐ │ T_MINI │ MINI = NBRE │ T_MAXI │ MAXI = NBRE │ │ └──────────┬──────────┘ └──────────┬──────────┘ │ └────────────────────┬────────────────────┘ │ ┌──────────┴──────────┐ │ F_TRAIT │ CTR = CTR + 1 │ │ │ « CTR » = CTR │ │ │ « MINI » = MINI │ │ │ « MAXI » = MAXI │ │ │NBRE = (MINI+MAXI)/2 │ │ │ NBRE :: CHOIX │ │ └──────────┬──────────┘ <> │ ◊────────────────────────────────────┘ ┌──────────┴──────────┐ F_PROG │ « CTR » = CTR │ │ « CHOIX » = NBRE │ └─────────────────────┘
{ D_PROG } CTR = 0 MINI = 1 MAXI = 100 NBRE = n CHOIX = n WHILE NBRE <> CHOIX DO BEGIN { D_TRAIT } IF NBRE < CHOIX { T_MINI } THEN MINI = NBRE { T_MAXI } ELSE MAXI = NBRE { F_TRAIT } LET CTR = CTR + 1 PRINT ″ CTR : ″, CTR USING "##&" PRINT ″ MINI : ″, MINI USING "##&" PRINT ″ MAXI : ″, MAXI USING "##&" SKIP 1 LINE LET NBRE = (MINI + MAXI) / 2 END { F_PROG } PRINT ″───────────" SKIP 1 LINE PRINT ″ CTR : ″, CTR USING "##&" PRINT ″CHOIX : ″, NBRE USING "##&"
Pièce jointe 586757
Merci pour ces explications.
salut
la différence entre tansque(while) et repete-jusqua(repeat until)
pour le premier nous ne somme pas obliger dans la boucle alors que dans l'autre cas tu fait au moins un tour
dans ton exemple tu a oublier la boucle for qui n'est ni plus ni moins qu'une poucle while spécialisé
après ce n'est qu'une question de grammaire ... le do while ou le while do pour moi est une hérésie mais le Ciste on le chique pour complexifié leur code