Kevin Kofler (./39) :
WTF?! Tu traîtes les pointeurs différement selon leur adresse?! C'est quoi cette API?

Si p est un pointeur sur char, la norme m'autorise à savoir si p pointe dans char Tab[ 10];
C'est tout ce que je fais (même s'il y a un cast de void (*)(void) vers void* non autorisé mais je fais avec sauf si on me trouve une marchine sur laquelle il y a un compilateur C99 et où ca ne marche pas).

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

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.

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.

Pollux (./40) :
Si bar devient complètement invalide ça veut dire qu'on peut juste créer une chaîne (linéaire) de constructeurs plutôt qu'un arbre quelconque, c'est peut être gênant au niveau performance ?

D'après mon expérience, pas tellement.

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.

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 ?

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.

Pollux (./40) :
Comment est-ce que ton extension fait pour intercepter ça ?

Pour l'expression 0*24*2^(sqrt(2))*E où E est l'extension. sa fonction de multiplication recoit 0*E et c'est à elle de décider ce qu'elle en veut.

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).

Pollux (./40) :
En pratique je crois que même en 32 bits on a besoin d'alignements sur 16 octets pour que les SSE soient efficaces (inversement si on parle d'alignement pour la correction plutôt que pour la performance, c'est possible que 1 octet suffise sur x86 non ?)

Surement.