Bug avec la priorité des opérations arithmétiques ?

Je pense avoir trouvé un bug avec la priorité des opérations arithmétiques. En principe, Deux divisions successives doivent se dérouler l'une après l'autre, en évaluant l'expression de gauche à droite. C'est vrai avec une expression simple:

Code:

print 18/2/3

imprime bien le bon rfésultat: 3.

Or, ce n'est plus vrai avec une expression plus complexe. Il suffit de regarder le code suivant:

Code:

dim x%,w%,sp%,t%

w% = 80
sp% = 3
t% = 21

x% = int((w%-sp%-t%)/sp%/2)


memo 1 : width 1,500 : height 1,400 : font_size 1,12
item_add 1,"w%="+str$(w%)
item_add 1,"sp%="+str$(sp%)
item_add 1,"t%="+str$(t%)
item_add 1,""

item_add 1,"w%-sp%-t%="+str$(w%-sp%-t%)
item_add 1,"(w%-sp%-t%)/sp%="+str$((w%-sp%-t%)/sp%)
item_add 1,"(w%-sp%-t%)/sp%/2="+str$((w%-sp%-t%)/sp%/2)+" <== erreur ici !"
item_add 1,"int((w%-sp%-t%)/sp%/2)="+str$(int((w%-sp%-t%)/sp%/2))
item_add 1,""

item_add 1,"Le résultat devrait être: "+str$(int((w%-sp%-t%)/sp%*2))

end

La formule complète est donnée en ligne 7. La ligne 19 affiche le résultat réel de Panoramic, et ce résultat est faux. Il faut remplacer la dernière division par une multiplication pour obtenir le bon résultat, comme en ligne 22. Or, cela ne s'explique que si "sp%*2" est effectué avant la division de ")/sp%". Et ce n'est pas normal.

C'est vrai. Y a un bug que j'ai souvent rencontré mais je l'ai minimisé car en mettant la première division entre parenthèse et ainsi de suite tu aura le vrai résultat. C'est à dire que PANORAMIC ne prend en priorité que les opérations entre parenthèse. Mais ça reste un bug où Jack devrait revoir s'il a un peu de temps.

Code:

print "(80-10+20)/9/5 = DONNE UN RESULTAT FAUX = "+ str$((80-10+20)/9/5)
print "===> La 2eme division devient multiplication"
print "((80-10+20)/9)/5 = DONNE UN RESULTAT VRAI = "+ str$(((80-10+20)/9)/5)

A+

Tu as raison. Avec les parenthèses, on peut "forcer" l'ordre d'exécution des opérations. Cela reste néanmoins un bug, et je suis certain que Jack aura à coeur de corriger cela. Sinon, à quoi servirait la notion de priorité des opérateurs, si l'on devait placer des parenthèses partout pour forcer l'ordre d'exécution !

En fait dans les opérations arithmétiques, la deuxième division d'une opération par un nombre X est égale à la multiplication de ladite opération par l'inverse du nombre X, mais PANORAMIC multiplie non pas l'inverse du nombre mais le nombre en question.
A+

En fait dans les opérations arithmétiques, la deuxième division d'une opération par un nombre X est égale à la multiplication de ladite opération par l'inverse du nombre X, mais PANORAMIC multiplie non pas l'inverse du nombre mais le nombre en question.
A+

Ouuppss! mille excuses, j'ai envoyé 2 fois un même texte.

Exact. Mais cela ne se produit que si'il s'agit d'une expression complexe. La preuve:
print 18/2/3 imprime bien 3 et non 27 !

Tout dépend comment ce mécanisme est implémenté. Dans une machine virtuelle à une seule pile, on trouverait sur la pile:
0: 18
1: 2
2: / <== SP
exécution, résultat:
0: 9
puis on continue:
0: 9
1: 3
3: / <== SP
exécution, résultat:
0: 3 <== SP

En occurrence, c'est le cas. Or, dans mon exemple, à la place du "18", on devrait trouver le résultat de la parenthèse qui précède le premier "/", car comme cette expression est placée entre parenthèses, elle est obligatoirement évaluée d'abord. Et on doit forcément en venir au cas de figure de cet exemple: 3 valeurs liées par 2 divisions successives. C'est un cas d'école.

mais si j'en crois ce code

Code:

dim a
 a=24
 print a/2/2/2/2

Il n'y a pas d'erreur

Mais là, il y a erreur:

Code:

dim a, b
 a=10
 b=14
 print "(a+b)/2/2/2/2="+str$((a+b)/2/2/2/2)
 a = 24
 print "a/2/2/2/2="+str$(a/2/2/2/2)
 

Pourtant, le résultat devrait être identique !

Perso j'ai toujours rajouté des parenthèses pour éviter toute ambiguïté...
normalement en notation mathématique on a :
{[(a x b)+2.5] / 56} donc pourquoi ne pas appliquer le même principe en basic (au style de parenthèse pres)

Je trouve que cette écriture est plus "limpide" :
((a * b) + 2.5 ) / 56

que ça :

a * b + 2.5 / 56

je crois que l'on a déjà parlé des priorités sur les opérateurs....

Oui effectivement il y a un os.

Je me suis permis de simplifier pour la démonstration

Code:

print 18/2/3
print 9+9/2/3:' si l'on fait cette formule sur la calculatrice le résultat est 3
print (9+9)/2/3:' ????
print (9+9/2)/3:' ????
print ((9+9)/2)/3::' c'est OK

A+

PS: on s'est croisé....