Problème avec la commande If...then\elseif...then\else\endif

#1
Bonjour,
Lorsque j'écris la ligne de BASIC suivante:
Code:
If EntA < 10 and EntB < 10 then NEUTRE: elseif EntA > EntB then DROITE: else GAUCHE: endif
le vérificateur m'indique une erreur de syntaxe à ou avant la position 55 (curseur en dessous du n du 2ème EntB)
et envoie le message:Erreur: Elseif sans If.
Que dois-je corriger pour que cette ligne devienne valide?
Merci de votre aide.
 
Last edited:

PieM

Senior Member
#2
Bonjour,

Code:
If EntA < 10 and EntB < 10 then: goto NEUTRE: elseif EntA > EntB then: goto DROITE: else goto GAUCHE: endif
 
#3
Merci beaucoup,
Cela fonctionne également avec l'écriture suivante:
Code:
If EntA < 10 and EntB <10 then: goto NEUTRE: elseif EntA > EntB then goto DROITE: else goto GAUCHE: endif
Une autre écriture est possible:
Code:
If EntA < 10 and EntB <10 then
              goto NEUTRE
      elseif EntA > EntB then
              goto DROITE
      else
              goto GAUCHE
endif
 
Last edited:
#5
Bonjour,
J'espère ne pas vous froisser, M.PieM, en vous disant ceci:
Ce n'est pas si évident que cela...
En effet, si l'on regarde le dernier code que j'ai écrit, il y a 6 retours à la ligne, alors que seulement 4 ":" ont été suffisants dans le code précédent (5 pour le votre).
Cordialement
 

PieM

Senior Member
#6
Bonjour,
J'espère ne pas vous froisser, M.PieM, en vous disant ceci:
Ce n'est pas si évident que cela...
En effet, si l'on regarde le dernier code que j'ai écrit, il y a 6 retours à la ligne, alors que seulement 4 ":" ont été suffisants dans le code précédent (5 pour le votre).
Cordialement
Je n'ai jamais dit que c'était évident!
Je disais simplement que faire un retour à la ligne est équivalent à ":"

Le problème est que le correcteur de syntaxe accepte parfois des écritures qui ne sont pas forcément conformes. Un "do loop while b1>b2" est parfaitement traduit alors que ce n'est pas la syntaxe classique!
La formulation If xxxx then goto est équivalent à un
if xxxx then
goto yyyy
endif

donc votre elsif qui vient après n'est pas accepté, car il a été précédé d'un endif.

Pour éviter ce genre de désagrément je vous conseille d'utiliser la syntaxe "normale" avec des retours à la ligne ce qui a en plus l'avantage de rendre le code plus lisible.
 
#7
Merci de nouveau.
Vous me répondiez, entre autre:
"Le problème est que le correcteur de syntaxe accepte parfois des écritures qui ne sont pas forcément conformes. Un "do loop while b1>b2" est parfaitement traduit alors que ce n'est pas la syntaxe classique!"

Je saute sur l'occasion pour vous demander si vous connaissez d'autres écritures de ce type.
Je pense que cela devrait intéresser les programmeurs en Basic PICAXE.
Merci de prêter attention à ma requête.
Je peux ouvrir une autre discussion concernant ce sujet, si vous le désirez.
 

PieM

Senior Member
#8
"Le problème est que le correcteur de syntaxe accepte parfois des écritures qui ne sont pas forcément conformes. Un "do loop while b1>b2" est parfaitement traduit alors que ce n'est pas la syntaxe classique!"
Je saute sur l'occasion pour vous demander si vous connaissez d'autres écritures de ce type.
Je pense que cela devrait intéresser les programmeurs en Basic PICAXE.
Très sincèrement je ne vois pas l'intérêt d'utiliser une écriture un peu biaisée, car elle ne fait absolument rien gagner en nombre d'octets programmes !
que j'écrive:
high C.1
high C.2
high C.3
ou
high C.1,C.2,C.3
ou
high 9,10,11
est strictement identique ( 8 octets) mais le dernier n'est pas trop lisible.
 
#9
Bonjour,
Que nenni, ce n'est point pour gagner quelques octets de programme que je vous ai soumis cette requête...
C'eût été crucial lorsque je programmais avec un SINCLAIR (comprenant 1 kilooctet de RAM additionnelle!).
Là, la chasse à l'octet était ouverte...
Il en est tout autrement aujourd'hui, fort heureusement.

Le but de ma demande était de savoir si, depuis 2010, vous aviez recencé des "astuces" de programmation de ce genre,
que l'on ne trouve pas dans les manuels Picaxe,
et, si vous pouviez consacrer, de temps en temps, un peu de votre loisir pour
établir une liste de ces particularités.
Par exemple j'en ai relevé une autre en farfouinant dans ce forum:
b4=b1 min b2 min b3 (pour sélectionner la plus grande valeur parmi 3) ou
b4=b1 max b2 max b3 ( pour isoler la plus petite valeur parmi 3).
Mais peut-être que je me trompe et qu'il n'y ait finalement que très peu de cas.
Cordialement.
 

PieM

Senior Member
#10
Ecrire b4=b1 min b2 min b3 n'est pas pour moi une particularité, car c'est l'application stricte de la commande min ou max.
Au même titre qu'on écrit b4 = b1 + b2 - b3
 
#11
Bonjour,
Bigre! Ma façon de m'exprimer ne doit vous convenir, pour récolter (de telles réponses!)une telle réponse! (#10)
Promis, juré, je ne sors plus des sentiers battus de ce forum...
Je redeviens un toutou docile qui ne posera qu'une seule question à la fois.
Sincères salutations.
 
Last edited:

PieM

Senior Member
#12
Bonjour,
Bigre! Ma façon de m'exprimer ne doit vous convenir, pour récolter de telles réponses!
Promis, juré, je ne sors plus des sentiers battus de ce forum...
Je redeviens un toutou docile qui ne posera qu'une seule question à la fois.
Sincères salutations.
Comment ça? Quels sentiers battus ?

Je vous explique que ce vous voyez comme particularité, n'en est pas une pour moi et je vous explique pourquoi.
Ensuite vous me demandez de vous faire une liste de "particularités" de programmation, alors que nous avons une divergence sur cette appellation.
Je suis désolé mais je n'ai rien recensé dans ce domaine, et n'ai pas le loisir de parcourir les 18000 discussions du forum pour dénicher ces supposées particularités.
Mais peut être avez vous le temps et le loisir de vous y atteler.
Et désolé si mes réponses ne vous conviennent pas; j'éviterai à l'avenir de vous stresser!

Enfin, je vous ferai remarquer que votre toute première interrogation trouvait sa réponse par une lecture attentive du manuel, auquel je ne me suis pas contenté de vous renvoyer.
 

BESQUEUT

Senior Member
#14
Bonjour,
Bigre! Ma façon de m'exprimer ne doit vous convenir, pour récolter (de telles réponses!)une telle réponse! (#10)
Promis, juré, je ne sors plus des sentiers battus de ce forum...
Je redeviens un toutou docile qui ne posera qu'une seule question à la fois.
Sincères salutations.
La réponse de PieM ne me semble nullement offensante.
Il est effectivement difficile d'arbitrer entre "astuce" ou "particularité" et usage "normal" ou "conforme à la doc".

Le fait est que les Picaxes utilisent un BASIC spécifique, en particulier au niveau de l'évaluation des expressions.
Dans le cas cité, l'expression est normale et conforme à la doc Picaxe, mais "particulière" pour quelqu'un qui viendrait d'un autre BASIC, ce qui semble être votre cas.

Sur le fond, et s'agissant d'un BASIC interprété (faut-il expliquer ce terme ?) la comparaison de deux formulations d'une même expression peut conduire à différents constats :
- Constat N°1) les deux formulations sont strictement identiques. En fait, le pré-compilateur fourni le même P-code.
- Constat N°2) une des deux formulations utilise moins de mémoire que l'autre
- Constat N°3) une des deux formulations s'exécute plus rapidement

Dans de nombreuses situations, (notamment quand le code comprends des PAUSEs) la vitesse d'exécution n'est pas critique. Mais un Picaxe étant environ 1000 fois plus lent que le PIC qui le supporte, cet aspect peut prendre une grande importance.

Tant que le P-code tient dans la mémoire, il est en général inutile de chercher à optimiser la taille du p-code. Par contre, dès que le programme devient un peu complexe, il est assez fréquent de sortir le chausse-pieds pour faire rentrer tout ça dans le Picaxe choisi...

La taille du programme source n'a strictement aucune importance dans tous les cas. Par contre, IMHO, sa lisibilité est fondamentale pour différentes raisons :
- si vous souhaitez obtenir de l'aide, plus votre programme sera lisible, plus vous obtiendrez de conseils pertinents...
- si vous revenez sur votre code des mois ou des années plus tard, vous constaterez que ce qui vous semblait évident lors de l'écriture l'est beaucoup moins plus tard...
- l'expérience montre qu'un code très lisible est très souvent aussi très performant (en termes de taille comme de vitesse)
- pour des exemples spécialement parlants (et même si vous ne souhaitez plus lire les excellents conseils de notre ami PieM) recherchez sur le forum anglais les posts de Hippy : il y a effectivement de véritables "astuces" parfaitement documentées mais pas du tout triviales ! Bien souvent, il faut relire la doc trois fois pour comprendre comment ses formulations fonctionnent, mais le fait est que c'est souvent extrêmement brillant.

A titre d'exemple, une de ses toutes dernières propositions http://www.picaxeforum.co.uk/showthread.php?30217-Precise-output-timing
Dans ce cas extrêmement spécifique, l'objectif n'est pas d'optimiser la vitesse, encore moins la taille du code, mais de stabiliser la vitesse d'exécution !
Et si on lit bien, on découvre une véritable astuce de programmation (pour le coup non documentée...)la vitesse d'exécution d'une commande dépends de l'endroit où elle se situe dans le programme !
Très peu en fait et donc négligeable la plupart du temps, ça peut devenir fondamental pour une application "time critical".

Toujours dans les publications récentes, voir http://www.picaxeforum.co.uk/showthread.php?30192-Smart-picaxe-outdoor-light/page5 post #45 ainsi que les réactions de lbenson et newplumber qui suivent...
Je vous préviens : c'est du lourd. Mais si vous cherchez des "astuces", il y a de la matière...

Maintenant, libre à vous de participer au forum ou pas. Sachez que vous serez toujours le bienvenu.
Comme dans tout espace de convivialité, chacun peut avoir ses humeurs. Mais avec un peu de souplesse, les échanges sont la plupart du temps très pertinents et souvent aussi plutôt divertissants, voire humoristiques...
 
Last edited:

BESQUEUT

Senior Member
#15
Bonjour,
J'espère ne pas vous froisser, M.PieM, en vous disant ceci:
Ce n'est pas si évident que cela...
En effet, si l'on regarde le dernier code que j'ai écrit, il y a 6 retours à la ligne, alors que seulement 4 ":" ont été suffisants dans le code précédent (5 pour le votre).
Cordialement
Belle démonstration des effets de la pré-compilation : toutes ces formulations produisent très probablement le même p-code, la preuve en étant que la taille (du p-code) indiquée par PE6 est la même !
PE6 interprête les : et les retours à la ligne de la même façon.
De plus, dans le cas particulier du IF THEN, il est tolérant sur la présence ou pas des :
IF THEN GOTO et IF THEN : GOTO sont acceptés et conduisent au même p-code.

Dès lors, peu importe le nombre de : et/ou de retours à la ligne. D'un point de vue Picaxe, c'est strictement la même chose.
Par contre, pour le lecteur, j'ai tendance à préférer écrire sur plusieurs lignes, sauf dans le cas où il y a plusieurs expressions similaires successives, genre :
if bit1=0 then gosub TOTO else gosub TATA
if bit2=0 then gosub TITI else gosub TUTU
if bit3=0 then gosub TRUC else gosub MACHIN
 
#16
Bonjour,
En refaisant un tour dans le forum, je suis étonné, puis finalement agréablement surpris:
Je constate que mon échange (un peu houleux à la fin!) avec M.PieM a suscité, malgré tout, une longue intervention de votre part M.BESQUEUT.

Je vous remercie d'avoir pris le temps d'écrire ce long paragraphe, en partie, pour ménager la chèvre et le chou.

Je reconnais que j'ai réagi d'une façon peu réfléchie en répondant au message #10.
Veuillez m'en excuser M.PieM.

Merci encore de toutes ces informations et pistes de recherche.
Cordialement.
 
Top