PpHd (./41) :

Pollux (./40) :
OK, enfin c'est un tout petit peu crade quand même Faut pas avoir envie d'allouer une zone de Data avec MAY pour mettre le code d'une fonction dedans

Je crois que sous linux, MAY alloue une zone non executable

Mais sur TI non

Pollux (./40) :
Et aussi c'est super crade de pas pouvoir faire la différence entre f(1,2) et f({1,2})

Bug du parseur.

? Bug de la spec de may_subs_c surtout...

Pollux (./40) :
Comment ça ? Tu peux le réutiliser pour parser un flottant, oui, mais la structure arborescente tu es obligé de la recréer entièrement toi-même par exemple. Ou y a une API pour ça ?

Dans ce que j'ai cité, tu parses (sans évaluer) en utilisant may_parse_c, tu fais un may_subs_c pour faire les changements en extension, puis tu évalues.

Ok mais ça c'est pour les changements simples (assez simples pour qu'il y ait une regexp transformant par exemple les crochets de mes matrices custom en parenthèses d'appel de fonction), dès que ça devient un tout petit peu plus compliqué il faut tout réimplémenter. Enfin c'est pas très grave hein ^^

Pollux (./40) :
Sinon actuellement en quoi appeler plusieurs constructeurs avant d'évaluer est plus rapide que de faire l'évaluation au fur et à mesure ? Ca évite juste de faire plusieurs parcours de l'arbre (gain d'un facteur O(nb_de_constructeurs)) ou ça permet aussi de faire des optimisations top-down ? (gain d'un facteur arbitrairement grand)

Réponse 1: parcours de l'abre, et des GC en moins.

Ben l'arbre t'es pas obligé de le reparcourir si tu mets des flags pour dire que t'es déjà passé ; le GC en moins ok, mais c'est peut-être que c'est juste pas le bon modèle mémoire ? (i.e. peut-être que ça pourrait être intéressant de laisser volontairement des saletés sur la pile pour éviter de faire des memmove() 50 fois)

Pollux (./40) :
Ok ; à propos de ce que tu cites, comment est-ce que tu gères e / e où e est très compliquée et pourrait en particulier être nulle sur une surface de mesure non nulle ?

Exemple ?

(real(x)+abs(real(x)))/(real(x)+abs(real(x))) ?

Pollux (./40) :
Est-ce que ce serait pas une bonne idée de pouvoir rajouter un flag au domaine qui empêcherait ce genre d'optimisation, pour éviter les problèmes de solutions ratées comme sur TI ?

Sinon e / e est parsé en e * e^ -1. Et l'extension peut décider de ne pas retourner e ^ -1 lors d'évaluation si elle sait que e * e ^ -1 peut poser des problèmes. Si e est complexe, alors e/e est toujours simplifiée en 1.

Oui justement, je parle pas des extensions mais des nombres complexes : AMS peut rater des solutions à cause d'optimisations style e/e = 1. En fait c'est sûrement possible de faire ça avec des extensions, e/e serait représenté par l'extension when(e=0,UNDEF,1) -- il suffit d'avoir un flag pour dire à May de toujours le représenter par ça plutôt que par 1

Pollux (./40) :
Si je veux regarder si (1+[matrice1])*(1+det([matrice2])) commute, les deux arbres sont les arbres des deux expressions (avec pour feuilles les entiers/matrices).

Si une extension renvoie 1+E, toutes les simplifications faites sur les complexes s'appliqueront (donc la commutativité s'appliquera). Il faut qu'elle encapsule çà dans un EX(1+E) pour qu'elle gère elle-même sa sauce (et la commutativité s'appliquera quand même car 1+det est complexe).

Ah, ok... Donc en fait le type d'une expression évaluée est entièrement déterminé par le premier noeud, et c'est exactement comme si les types étaient explicites. Si je veux faire des calculs sur des matrices je dois donc définir une extension matrix qui évaluerait ça en un truc comme :
matrix(1+matrix([matrice1]))*(1+det(matrix([matrice2])))


(hmm tout ça ça me fait un peu penser à "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." )