Problème avec condition AND

Je ne sais pas si cela a déjà été signalé mais je rencontre un petit soucis avec la condition AND

Code:

Tri_insertion:
  FOR i=1 TO n
    x=t(i)
    j=i
    while j>0 AND t(j-1)>x : ' <--- ça plante ici
      t(j)=t(j-1)
      j=j-1
    end_while
    t(j)=x
  next i
return

Même si la première condition n'est pas remplie (j>0), l’interpréteur vérifie la 2eme.
Donc si j=0 , l’évaluation de t(j-1) me provoque un "index overflow".

Et pourtant, si j'ai mis le test j>0 c'est bien pour éviter cette erreur...

Normalement, dans le cas d'un AND, si la première condition n'est pas remplie, il n'est pas nécessaire de contrôler la 2ème, non ?

Peut-être que ce n'est pas AND qui pose problème,
mais t(j-1).
Est-ce que le DIM contient cette possibilité ?

Si c'est pas la première fois, d'ailleurs j'ai un vieux poste là dessus.
Pour ce type de codage, lorsque la deuxième condition peut engendrer une erreur si elle était exécuté, ça ne passe pas. Il faut obligatoirement faire une condition suplémentaire:

Code:

If j > 0
  while...
  end_while
end_if

ou alors ici:

Code:

if j>2 then j=j-1:else:exit_while

C'est toujours un problème pour moi avec les conditions multiples en Panoramic. Tout n'est pas accepté.

En effet Cosmos,
je connais la solution :

Code:

Tri_insertion:
  FOR i=1 TO n
    x=t(i)
    j=i
    c=0
    IF j>0
      if t(j-1)>x THEN c=1
    END_IF
    while c=1
      t(j)=t(j-1)
      j=j-1 : c=0
      if j>0
        if t(j-1)>x then c=1
      end_if
    end_while
    t(j)=x
  next i
return

Mais je trouve dommage qu'il faille utiliser une variable intermédiaire pour réaliser cette opération:
Dans la solution ci-dessus, j'ai carrément viré l'utilisation du AND et j'utilise à la place deux IF imbriqués...

Je n'ai pas compris ce qui plante, si je fais:

Code:

dim i, j, n, x, t(100)
label Tri
for i = 1 to 100: t(i) = int(rnd(100)): next i
list 1: height 1, 400: list 2: left 2, 120: height 2, 400
for i = 1 to 100: item_add 1, str$(t(i)): next i

n = 100: gosub Tri
for i = 1 to 100: item_add 2, str$(t(i)): next i
end

Tri:
  FOR i = 1 TO n
    x = t(i)
    j = i
    while j>0 AND t(j-1)>x : ' <--- ça plante ici (??)
      t(j) = t(j-1)
      j = j-1
    end_while
    t(j)=x
  next i
return

ça marche très bien ?

C'est normal JL35 que ça marche très bien, vu qu'il n'y a aucune condition qui porte à l'erreur.
J'ai simplement modifié une variable, et mis une vu sur l'erreur:

Code:

dim i, j, n, x, t(100)  :label er
on_error_goto er
label Tri
for i = 0 to 100: t(i) = int(rnd(100)): next i
list 1: height 1, 400: list 2: left 2, 120: height 2, 400
for i = 1 to 100: item_add 1, str$(t(i)): next i

n = 100: gosub Tri
for i = 1 to 100: item_add 2, str$(t(i)): next i
end

Tri:
  FOR i = 1 TO n
    x = t(i)
    j = i
    while j>0 AND t(j-1)>x : ' <--- ça plante ici (??)
      t(j) = t(j-1)
      j = j-1
    end_while
    t(j)=x
  next i
return

er:
message j
return

Comme tu peux le voir, la première condition n’arrête pas le teste.

Je ne comprends quand même pas, le seul fait que tu fasses un on_error fait apparaître une erreur qui n'est pas signalée autrement ?
En plus, si je mets dans le s/p er:

Code:

er:
message "Erreur " + error_type$+" Ligne " + STR$(error_line)
return

l'error_line est farfelu (la ligne de l'étiquette er), et l'error_type: 'Pas trouvé de END_WHILE correspondant'.
S'il y a un problème sur le While... End_While, il n'est pas signalé s'il n'y a pas de on_error_goto, et de plus le traitement est fait correctement jusqu'au bout, alors je suis perplexe...

J'avais pas vu, mais effectivement tu as changé mon 'for i = 1 to 100' en 'for i = 0 to 100' et là ça fait une erreur d'index overflow.

Je suis désolé d'avoir été imprécis. D'ailleurs je ne devrais pas répondre dans la journée.
Je regarde en passant se qui se passe sur le site, et régulièrement lorsque j'interviens, je dois conclure rapidement, parce que dérangé par autre chose. Je ne me plaints pas sur le fait, mais évidemment, ça pose parfois des problèmes.

Tout est dis là :

Citation :

while j>0 AND t(j-1)>x : ' <--- ça plante ici

Citation :

Même si la première condition n'est pas remplie (j>0), l’interpréteur vérifie la 2eme.
Donc si j=0 , l’évaluation de t(j-1) me provoque un "index overflow".

Dans une condition AND et à plus forte raison dans un test, normalement, dès la première assertion fausse rencontrée, on doit sortir du test...

Non, je ne pense pas. Lorsque l'interpréteur évalue l'expression, in en sait pas du tout ce qui va suivre, avant d'avoir tout évalué. Imagine ceci:

Code:

while j>0 AND t(j-1)>x OR a=b

Tu sois bien qu'on ne peut pas s'arrêter d'interpréter l'expression. Et il serait vraiment trop compliqué d'arrêter d'interpréter juste la sous-expression et évaluer le reste. Exemple:

Code:

while (k>0 OR m=1) AND (j>0 AND t(j-1)>x) OR A=B

Une expression, logique ou arithmétique, est un tout et évaluée jusqu'au bout, intégralement, et produit un seul résultat, qui est ensuite utilisé. il est da la responsabilité du programmeur d'assurer la validité de tous les éléments intervenants.

Il me semblait que dans mes anciens basic, cela fonctionnait ainsi, et pour résoudre le code que tu poses, personnellement, je codais ainsi:

Code:

while ( j>0 AND t(j-1)>x) OR a=b

Cela dis, le cas sans parenthèses je suis obligé de te donner raison! T'es compliqué, cela me donne envie d'aller me coucher. Mais c'est pas l'heure

en C cela fonctionne également.

Klaus, je suis d'accord avec toi : l'analyseur syntaxique doit faire son boulot
mais au moment de l'exécution les ordre de priorité des opérateurs logique/binaire sont déjà fixés et je pense que :
dans le cas d'une condition ( a . b ) si a est faux, il n'y a aucune raison de tester b
En C et je pense dans d'autres langages (faut que je fasse le test sous Delphi) dès qu'une condition n'est pas rempli les autres sont ignorés...

Voir l'algèbre de boole pour les priorités :ici

Je sais que dans certaines versions de Fortran (langage que j'ai pratiqué beaucoup), on avait un compilateur optimisé qui effectivement pouvait dynamiquement éliminer des sous-expressions dans une expression logique en fonction du résultat de la sous-expres​sion("false" dans un AND, "true" dans un OR, etc). Mais cela n'est pas simple, car il faut savoir qu'en général, à la compilation, une expression su type ci-dessus est décomposée en opérations de gestion de pile. Exemple:

Citation :

while j>0 AND t(j-1)>x

est compilé comme ceci (représenté en pseudo-code, SP représentant le pointeur de pile, X et Y des registres):

Citation :

sp := sp + 1
j --> (SP)
SP := SP + 1
0 --> (SP)
(SP) --> X
SP := SP - 1
(SP) --> Y
SP := SP - 1
résultat de Y>X --> X
SP := SP + 1
X --> SP
SP := SP + 1
j --> (SP)
SP := SP + 1
1 --> (SP)
(SP) --> X
SP := SP - 1
(SP) --> Y
Sp := SP - 1
résultat de X-Y --> X
SP := SP + 1
X --> (SP)
SP := SP + 1
adresse de t --> (SP)
(SP) --> X
SP := SP - 1
(SP) --> Y
SP := SP - 1
contenue de (X)+Y --> X
SP := SP + 1
X --> (SP)
(SP) --> X
SP := SP - 1
(SP) --> Y
SP := SP - 1
resultat de Y and X --> X
SP := SP + 1
X --> SP
SP := SP + 1
adresse de x --> (SP)
(SP) --> X
SP := SP - 1
(SP) --> Y
résultat de Y>X --> X
if x=true then...

L'interprétation de peut que procéder pas à pas. Sauf effort énorme de "compréhension" de m'expression, on ne peut pas prendre des décisions en cours d'évaluation.

EDIT

Nos messages se sont croisés. D'accord avec toi, mais cela impose, comme c'est fait dans Delphi, qu'au niveau du code généré, on "comprenne" la structure de l'expression logique et que l'on intercale des instructions de test de la valeur de chaque sous-expression, pour que dynamiquement, les valeurs soient prises en compte. Cela peut être fait dans une "usine à gaz" comme Delphi où des équipes nombreuses de programmeurs travaillent sur le noyau, mais cela me semble exclu dans un langage comme Panoramic. D'ailleurs, cela ne concerne pas seulement les expressions logiques, mais tout le domaine très vaste de l'optimisation du code. Et, soit dit en passant, suivant les méthodes d'optimisation, on peut obtenir des effets secondaires pas piqués des hannetons, comme c'est le cas dans Fortran, où le même code en apparence correct ne marche plus d'une version à l'autre, justement à cause des optimisations de code.

Un AND pour moi c'est une suite de IF qui se suivent, il n'y a rien de compliqué la dedans


if a=0 and b=7

revient à écrire :

Code:

' test de J
  ldd  OFST-2,s  ; récupère a dans la pile
  beq _Endif
  ldd OFST-4,s  ; récupère b
  cpd #7
  beq _Endif
  ..
  etc,etc..
_Endif:
  rts

Bon c'est clair que Jack ne descend pas si loin dans le code sinon on aurait un veritable code executable, compilé...
mais un AND reste un AND:
ecrire condition1 AND condition2

C'est la même chose que :

Code:

if condition1
  if condition2

et on voit bien que si condition1 n'est pas remplie on passe pas sur le test de la 2eme condition...

while j>0 AND t(j-1)>x
Je suppose que Jack interprète ce qu'il y a à gauche puis ensuite à droite du AND (peut être que le traitement d'une expression est fait à partir d'un arbre binaire voir ici pour ceux que cela intéresse)

là on ne parle pas d'optimisation de code ou d'expressions "tordues", compliquées...
Le forum regorge d'expression beaucoup plus compliquée que mon simple while...

Certes, mais transformer ton "IF c1 AND c2" en "IF C1 IF C2" est déjà une des techniques d'optimisation du code généré. Pour avoir eu moi-même des difficultés avec des expressions logiques complexes, je sais que Panoramic ne fonctionne pas ainsi. A Jack de le dire, mais je pense que l'élaboration se fait selon une méthode proche ou dérivée de la notation polonaise inversée (PRN - polish reverse notation), ce qui est le principe de ma démonstration dans mon précédent poste.

Pour ma part, j'ai maintenant recours, la plupart du temps, à des IF imbriqués comme on le faisait à l'ancienne.

D'ailleurs, regarde le code suivant:

Code:

dim i%, j%, m%, t%(5)
i% = 1
m% = 3
jJ = -1
if i%>4 AND t%(j%)=0 OR m%<10 then print "La condition est vraie"

Dans certains FORTRANs avec lesquels j'ai travaillé, le message serait imprimé, mais PANORAMIC et la quasi-totalité des autres langages produiront une erreur. Car si l'on poussait ta logique un peu plus loin, il est évident que le second terme (celui après le OR) est "vrai" et que donc, quelles que soient les autres valeurs, la condition est "vraie". Mais seule une optimisation poussée du code généré permettrait de gérer des cas comme ça. Et c'est pourquoi Panoramic ne peut pas prendre une décision sur la valeur globale avant d'avoir évalué l'ensemble des constituants d'une expression.