AutoIt Français

Pas d'accord, grammaire algébrique à revoir!

Intéressant
Cet exemple : Msgbox(0,"", 3-1^2 ) semble contredire la priorité des opérateurs telle que décrite dans le fichier d'aide
jc tu as certainement une explication ?

Oui, ce n'est pas le seul problème avec l'évaluation arithmétique ainsi qu'avec les litéraux numériques.

Normalement on distingue deux opérateurs différents :
o) le "moins unaire" qui indique qu'on désigne l'opposé d'une quantité (par rapport à l'addition),
o) la soustraction ou "moins d'arité 2" qui demande deux opérandes.

De ce point de vue, -1^2 peut valoir 1, ce n'est pas une convention absurde ni contradictoire avec l'arithmétique de l'épicier du coin.
Par contre, dans 0-1^2, le signe - est manifestement une soustraction de 1^2 à 0, ce qui vaut obligatoirement -1.

Il y a donc un autre problème à solutionner pour Jon.

EDIT :
Je ne cautionne pas particulièrement la convention du "moins unaire". Je préfère de beaucoup l'évaluation de -x sous la forme (-1) * x avec -1 considéré comme une valeur spéciale, la seule valeur négative possible. Ce type d'évaluateur transforme ainsi une expression comme
(a + 3 - x^y - (2 - z))^-2
en
Power[Plus[1, a, Times[-1, Power[x, y]], z], -2]
exemple de ce que délivre Mathematica, qui est certainement l'évaluateur le plus complexe et le plus subtil de tous les langages existants.

Il y a donc un autre problème à solutionner pour Jon.

Je parierais bien qu'il n'y touchera pas... ce serait un script breaking change terrible
Il n'y a jamais eu de ticket là-dessus ? c'est étonnant !

mikell a écrit :Je parierais bien qu'il n'y touchera pas...

Je sais pas, ça discute. D'un côté, un langage de programmation (ou de scripting) qui ne respecte pas les priorités d'opération c'est limite, dans le sens où on se sert de calculs tout le temps même si ces derniers ne sont pas des calculs savant non plus.
De l'autre cela dit si des UDFs se basent sur ce genre de "grossièreté", attention les dégâts... Moi perso je mets toujours les parenthèses implicites pour éviter ce problème d'évaluation d'expression justement. Comme ça, si un calcul est faux, je ne peux m'en prendre qu'à moi même et non à Jon haha !

Tu veux dire "explicites" ?
Oui, c'est un solide préservatif.

Ca fait un bout de temps que Jon n'a pas trop montré le bout de son mulot et je suppose que son contrat actuel ne lui en laisse guère le temps.
Il est parfaitement légitime de fixer une erreur manifeste, même si ça doit être un "script-breaking change". Ca a déjà été fait, heureusement.

Hmmm. Evidemment que c'est légitime... je voulais dire que c'est tellement gros que les développeurs doivent certainement être au courant depuis longtemps - mais le "bug" est toujours là
J'ai cherché mais pas trouvé le moindre ticket sur le sujet
Une rectification pourrait signifier de forcer l'usage de parenthèses dans les expressions avec signes moins et exposant, en "oubliant" la précédence (pas de problème avec 3+1^2 ou 3*1^2 où la précédence théorique est respectée)
D'ailleurs le fichier d'aide est excessivement laconique sur l'usage des parenthèses, il n'y a que pour l'opérateur ternaire que leur usage est strongly recommended