Tokenisation des expressions - Page 1

En voulant tokeniser des expressions "Ti-Basic-like", je comptais essayer de rester le plus proche possible des conventions du TiOS.

Donc j'ai stoqué des trucs genre "a+b*c->d" puis examiné d pour voir à quoi ressemblait l'expression tokenisée. On a dans le cas de 1+2*3-4 par exemple : 123*+4-, jusque là tout est normal.

Par contre avec les operateurs de comparaison (> et < entre autres), les operandes sont inversées, par exemple 1*2<3+4 -> 34+12*<. Je me demande à quoi peut ressembler leur code pour avoir un résultat comme ça, j'ai fait un petit tokeniseur d'expressions simples, et il semblait logique d'avoir toujours une conservation de l'ordre des valeurs (1, 2, 3 et 4 dans mon exemple, ce qui donnait 12*34+<). Pourquoi est-ce que le TiOS inverse les operandes pour <, > (et surement d'autres operateurs) ?

Autre chose si quelqun sait : quand il parse une expression, il commence au premier caractère ou au dernier ?

Moi ça me semble autant logique d'inverser les expressions lors d'une comparaison que de ne pas les inverser.

Oui mais au niveau du code, ça me parrait bien plus compliqué et je ne vois pas quel avantage ça apporte

Tu as raison.

Normalement, une expression tokénisée se lit de droite à gauche. C'est l'ordre utilisé pour < et > qui est l'ordre normal, pas celui utilisé pour + et * (qui sont des exceptions).
Et il y a le code source de Tokens89 OCX: http://members.chello.at/gerhard.kofler/kevin/francais/pcprogs/.

Il m'avait semblé que - et / avait le même ordre, mais je n'en suis plus sûr, à vérifier. Je vais jeter un oeil à Tokens89, merci.

P.S : L'expression tokenisée se lit de droite à gauche, ok (de toute façon la lire de gauche à droite serait impossible, puisque la taille des expressions est indiquée à la fin lorceque c'est nécessaire). Mais pour parser l'expression entrée par l'utilisateur, le TiOS lit de droite à gauche ou de gauche à droite ?

Vertyos
: Il m'avait semblé que - et / avait le même ordre,

Oui. Mais ^ a un ordre différent (l'ordre "normal").

P.S : L'expression tokenisée se lit de droite à gauche, ok (de toute façon la lire de gauche à droite serait impossible, puisque la taille des expressions est indiquée à la fin lorceque c'est nécessaire). Mais pour parser l'expression entrée par l'utilisateur, le TiOS lit de droite à gauche ou de gauche à droite ?

Gauche à droite, je pense.

Gauche à droite, je confirme. Ce serait vraiment tordu de le lire dans l'autre sens, de toute façon

Bah déjà que je ne vois pas très bien pourquoi certaines operations sont placées dans un sens et d'autres dans l'autre ...

C'est le charme du TIOS

Et puis même si pour toi, ça peut être compliqué de parser à l'envers, pour eux ça ne change pas grand chose (un petit push_between et hop! c'est plus lent mais de toute façon il y a des trucs comme ça partout...) Il suffit que ça simplifie quelques tests au niveau du calcul formel pour que ça soit intéressant pour eux (par exemple, le TIOS utilise 2*x et pas x*2, donc pour limiter les changements pour la conversion représentation interne -> externe, il vaut mieux que l'endroit où c'est le plus facile de tester s'il y a une constante corresponde au premier argument).

Parser dans un sens ou dans l'autre, ça ne pose pas vraiment de problème. Par contre placer les arguments dans un ordre différent selon l'operateur, c'est déjà nettement moins normal

Je voulais commencer un petit tokeniseur / évaluateur d'expressions, pour l'instant il ne connait que quelques operateurs, mais rester compatible avec la "logique" du TiOS risque d'être la chose la plus compliquée dans tout ça

Oui bien sûr. Mais l'explication que j'ai donné plus haut explique (au moins en partie) pourquoi l'ordre dépend de l'opérateur. Par exemple, pour ^, c'est certainement plus utile de connaître la constante de droite (contrairement à la multiplication où c'est le contraire), parce que c'est elle qui intervient dans toutes les fonctions de base (polynômes...) Evidemment, c'est possible que je raconte n'importe quoi, mais ça m'a l'air assez plausible

Vertyos :
Bah déjà que je ne vois pas très bien pourquoi certaines operations sont placées dans un sens et d'autres dans l'autre ...

Je pense que c'est parce que l'associativité par défaut est différente. 1+2+3 est lu comme (1+2)+3, 1^2^3 est lu comme 1^(2^3).

Pollux
: (par exemple, le TIOS utilise 2*x et pas x*2, donc pour limiter les changements pour la conversion représentation interne -> externe, il vaut mieux que l'endroit où c'est le plus facile de tester s'il y a une constante corresponde au premier argument).

Il y a quand-même des ordres à changer parfois. Par exemple, la forme externe est x+3, mais la forme interne est 3+x.

Kevin Kofler
:

Vertyos :
Bah déjà que je ne vois pas très bien pourquoi certaines operations sont placées dans un sens et d'autres dans l'autre ...

Je pense que c'est parce que l'associativité par défaut est différente. 1+2+3 est lu comme (1+2)+3, 1^2^3 est lu comme 1^(2^3).

Ben, + est associative, nan ?
Encore, pour - et /, je comprendrais, mais pour * et +, je vois pas l'intérêt...

Moumou> + et - ont la même priorité, donc on est obligé de choisir la même associativité pour les deux...

Kevin> Oui, mais ils ont dû essayer de limiter ça. Peut-être qu'au début ils voulaient laisser 3+x tel quel, puis ils se sont rendu compte que c'était souvent plus lisible avec x+3 ?

Pollux > Ah oui, j'y avais pas pensé.

De plus, l'addition n'est pas associative en virgule flottante! Et la calculatrice permet aussi le calcul en virgule flottante.

Bon... Bah le code que j'ai pour être compatible avec les conventions du TiOS est nettement plus gros et compliqué que celui que j'avais avant

Kevin> Toujours est-il que le fait d'avoir une associativité bien définie n'importe pas (puisqu'on peut mettre des parenthèses selon l'associativité qu'on veut, donc lorsqu'on veut (epsilon2-epsilon1)+huge, on n'écrit pas epsilon2-epsilon1+huge puisque c'est ambigu)... En plus le détokeniseur TIOS supprime de toute façon toutes les parenthèses même si elles sont utiles (i.e. détokenize(tokenize("x+(y+z)"))="x+y+z" et pas "x+(y+z)"), donc on ne peut même pas s'attendre à une associativité bien définie (sauf si on suppose que c'est toujours associatif à gauche, mais on peut presque considérer ça comme un bug).

ben il n'y a pas d'associativité pour le + mais il faut bien au moment de parser en définir une.. la plus "logique" a été prise a savoir 1+2+3 = (1+2)+3

enfin sa c'est mon avis perso..

Ca depend. Certains calculs formels reclassent completement les termes avant d'evaluer:
1e-10+1e10-1e10 sera interprete par 1e10-1e10+1e-10.

Sinon aussi pour se qui est de l'affichage de x+3 au lieu de 3+x c'est parceque la TI classe les puissances par ordre décroissant

ie :

x^3 + 4x^2 + 2x + 3

Logique

Tout a fait, mon cher PpHd