PpHd
a écrit :
J'ai dis que la représentation est choisie est + grosse que celle d'AMS, mais plus pratique (Entre autres le champ size, même si on a des expressions a sauter quand même -car Free ne bouge pas les blocs mais les marquent comme 'a effacer' - Mais le surcout est facilement reductible-).
Il vaut mieux utiliser une représentation plus compacte. À quoi te sert-il d'avoir des fonctions qui prennent 1s de moins si tu te tapes une erreur de mémoire dès que tu essayes de faire un calcul un peu plus compliqué?
Il faut bien evidemment faire le test pour transformer x 3 * en sa représentation exacte. C'est le role de la fonction eval. Mais cette fonction ne le fera qu'une fois. Et la fonction is_constant est loin d'être trivial, ni rapide à faire.
Mais il faudra la faire de toute façon. Et quand elle est faite, ce n'est plus qu'un appel de fonction tout bête.
(2+3sqrt(2)) est constant.
Tiens, ça me rappelle une chose: Tu le représentes comment, le produit "3 sqrt(2)"? Avec un "scalaire"? Avec une multiplication "normale"?
Ce que je propose est de faire deux EStack séparés (Estack de Ti et l'EStack de chez AMS), et le CAS en application séparée, ainsi que des fonctions CAS séparées (avec quelques fonctions d'import/export).
2 CAS séparés? Je pensais que tu voulais une ROM de petite taille???
Ne te souviens tu pas des critiques contre la vitesse d'AMS ? Elles sont en grandes parties dues a ce format qui ne permet pas d'aller vite.
Comment t'expliques-tu que Samuel Stearley ait écrit une version de
next_expression_index qui gère le format AMS complet et qui est nettement plus rapide que celle de AMS? On peut faire plus rapide tout en gardant le format de AMS!
On passe son temps a deplacer la memoire par push_between ou delete_between, et a sauter les arguments par next_ESI_index.
Mais ça a aussi des avantages:
* représentation plus compacte
* possibilité de copier des expressions entières plus facilement
* possibilité de remplacer facilement une expression par une autre. La substitution est une opération très importante pour un CAS! Si on doit modifier à chaque fois un paquet d'indicateurs de taille quand on substitue, c'est lourd!
...
>Tu n'as pas l'air de connaître le format de AMS suffisamment bien pour te rendre compte à quel point il est pratique. Et même chose pour PpHd.
Je connais très bien le format d'AMS et je ne le trouve pas pratique : push_between, delete_between, next_expression_index sont des fonctions inadaptées en vitesse.
Ce sont des fonctions simples et suffisamment rapides.
Par contre cela permet de gagner en taille : bien + compact.
En effet.
Cependant l'EStack de ce CAS pourra etre fixé a 150Ko par exemple (Alors que le max sur AMS est de 64K), ce qui compensera un peu.
Ce n'est pas une solution. Consommer une grande partie de la RAM juste pour la pile d'expression n'est pas une bonne stratégie. Ça empêche de garder plusieurs variables en RAM par exemple. Or, si on veut calculer sur des variables contenant des expressions formelles, on a autre chose à faire que de les archiver et désarchiver en permanence (ce qui use aussi la FlashROM d'ailleurs).
Ensuite la compatibilite basique / expressions AMS sera a mon avis assez difficile a faire. Mais rien n'empeche de faire 2 CAS en meme temps. Un compatiblite, un rapide.
Et
Pedrom passera de ROM légère à bolide qui consomme les 2 MO en entier...
Je pensais que
Pedrom se voulait optimisée en taille, pas en vitesse...
nEUrOne a écrit :
paxal: il est peut-être suffisant de faire un mini-Cas numérique. Je crois que l'on a pas vreaiment besoin de littéral la haut dans les écoles 
Si c'est numérique uniquement, ce n'est pas un CAS!
Pollux
a écrit :
A mon humble avis le mieux est de faire un émulateur de CAS AMS pour les progs en C qui en ont besoin, ça permet de garder la compatibilité tout en évitant de perdre du temps à développer deux CAS.
Mais cet "émulateur" sera soit un CAS à part entière, soit une horreur qui convertit à chaque fois entre les 2 formats (donc lente!), consomme au moins le double de mémoire (donc bonjour les erreurs de mémoire) et ne respecte pas entièrement les règles de simplification de AMS (parce que sinon la conversion sera encore plus lente). Et un non-respect des règles de simplification de AMS veut dire une incompatibilité avec les programmes qui attendent une représentation simplifiée correctement (la représentation "internally simplified" dans la plupart des cas).
Le fait que tu n'y ais pas pensé me surprend énormément.
et à mon avis pour la compatibilité, faudra remanier les sources c'est tout.
)
(et ça peut arriver, boucles de copie, etc...)
