[mOved] Un CAS pour Pedrom? - Page 3

>Et tu as implémenté les trucs vraiment compliqués, de style les nombres DMS (1°2'3")?
Non. Je ne savais meme pas que ca existait tellement je m'en sers souvent.

Ensuite, il faut debattre sur le format sous la forme avantage / inconvenient.

Format d'AMS:
+ Compatibilite AMS.
+ Compatibilite programmes / fonctions TI-BASIC.
+ Compatibilite programmes asm utilisant des fonctions mathematiques.
+ Prend peu de place.
Mais :
- Impossibilite de savoir combien de param pour une fonction rapidement.
- Impossibilite d'acceder rapidement aux differentes sous-expression.
- Impossibilite de sauter rapidement des expressions.
- Beaucoup de pushage/popage sur l'EStack.

Je vais vous proposer mon format (le dernier en date) de gestion de calcul formel (J'en change tres recemment).

Il faut repondre a ces contraintes :
+ Quelles sont les fonctionnalites frequemment necessaires pour un CAS ?
+ Rapidite
+ Taille
Etc

N'y aurait-il pas un moyen d'utiliser les deux formats, avec par exemple un token spécifique pour dire que ce n'est pas le format d'AMS?!
L'inconvénient est certainement que cela risque fort de doubler la taille dudit CAS...

Fonctionnalités fréquemment nécessaires:
- les opération arithmétiques de base (+,-,*,/);
- les fonctions plus calculatoires: fonctions trigonométriques (hyperbolique), logarithmes et exponentielle;
- les tests de comparaison

Je pense qu'on tient là l'essenciel du CAS.

Rapidité et taille:
La taille à mon avis ne devrait pas dépasser 64ko de fonctions (pour ne pas dépasser un bloc en ROM, si j'ai bien compris toutes ces histoires).
La rapidité, quand à elle, n'est pas fondamentale, puisque le but de PedRom n'est pas d'avoir un CAS sofistiqué et ultra-rapide. Ceux qui veulent des maths ne prendront pas PedRom de toute manière, ils garderont AMS pour un résultat plus sur (quoi que parfois...)

Peut-être vaudrait mieux-t-il convertir à chaque fois les entrées et les sorties, pour les rendre compatibles. Le seul inconvénient est la duplication de certaines fonctions d'AMS, ce qui ralentirait le programme d'une part, et augmenterait la taille de la liste des ROM_CALL de l'autre.

paxal: Tu n'es pas rentre assez dans le detail des fonctions élémentaires. Decomposent les fonctions formelles de base. Comment ecrire la derivee ?

Déjà, - et / sont remplacés par +(-1*x) et *x^(-1)...
Les fonctions hyperboliques n'ont à mon avis pas besoin de token spécifique, on peut se contenter de remettre en forme le résultat (et c'est peut-être ce que fait le TIOS)
Reste plus que exp, ln, sin, cos, tan(?), dérivée, primitive.

A mon avis il faut encore abs et sign

alors à ce moment là +,*, et neg.
le ^-1 est un peu lourd je trouve, / est une bonne solution.
Surtout que à mon avis "^" demande ln et exp. ln ne demande pas de division mais exp si.

privitive est difficile à coder, parce que dès qu'il y a une multiplication, ca se complique. J'ai encore rien vu à ce sujet du reste dans des documents sur Internenette.


Pour la dérivée, c'est de l'induction structurelle: une fonction qui s'appelle avec comme arguments la fonction, et la variable.

Autre chose: ne pas oublier les opérateurs logiques.

> alors à ce moment là +,*, et neg.
> le ^-1 est un peu lourd je trouve, / est une bonne solution.
Je ne crois pas, 1/x^2 risque d'être un peu lourd à gérer à ce moment là. En plus ça simplifie toutes les règles de distributivité.

> Surtout que à mon avis "^" demande ln et exp. ln ne demande pas de division mais exp si.
mmm on peut faire un tag '^' pour les puissances entières? ça simplifierait tout ce qui est développement par le binôme de Newton. Je ne sais pas trop ce que fait AMS...

> privitive est difficile à coder, parce que dès qu'il y a une multiplication, ca se complique. J'ai encore rien vu à ce sujet du reste dans des documents sur Internenette.
Primitive c un peu THE fonction (avec solve ), à mon avis il faut tenter de faire des intégrations par parties sur les termes en cherchant dans des tables, mais ça doit être très très chaud.

> Pour la dérivée, c'est de l'induction structurelle: une fonction qui s'appelle avec comme arguments la fonction, et la variable.
Oui, a priori pas besoin d'optimiser l'opérateur de dérivation (seul d(f(x),x) restera à la fin de l'évaluation et préliminaire, et en plus c plutôt rare)

> Autre chose: ne pas oublier les opérateurs logiques.
yup mais c plus le domaine du calcul formel (même si ça reste dans le domaine de l'évaluateur)

Primitive c un peu THE fonction (avec solve ), à mon avis il faut tenter de faire des intégrations par parties sur les termes en cherchant dans des tables, mais ça doit être très très chaud.

T'as oublié deSolve

ca va être

BiHi
a écrit : Kevin Kofler> "Personnellement". C'est peut-être pas le cas de tout le monde, donc laisse chacun faire son choix, et n'essaye pas de détruire ce projet.

Mais arrêtez de dire que je n'essaye pas de détruire son projet! C'est du n'importe quoi mis en circulation par Thibaut! Tout ce que je dis est que GTC n'a pas les fonctionnalités de TIGCC contrairement à ce que prétend Thibaut! Arrêtez de croire tout ce que dit Thibaut!

Retour au sujet:

PpHd a écrit :
>Et tu as implémenté les trucs vraiment compliqués, de style les nombres DMS (1°2'3")? Non. Je ne savais meme pas que ca existait tellement je m'en sers souvent.

Je me disais bien que ton parser est très loin de tout supporter sauf les "détails" que tu as mentionnés (qui ne sont pas des détails d'ailleurs - c'est plus de la moitié du travail de push_parse_text!)

Format d'AMS:
+ Compatibilite AMS.
+ Compatibilite programmes / fonctions TI-BASIC.
+ Compatibilite programmes asm utilisant des fonctions mathematiques. + Prend peu de place.

Et ces critères-là sont les plus importants.

Mais : - Impossibilite de savoir combien de param pour une fonction rapidement.

Les tags sont groupés en fonction du nombre de paramètres qu'ils prennent. Quelques comparaisons de rangées suffisent.

- Impossibilite d'acceder rapidement aux differentes sous-expression. - Impossibilite de sauter rapidement des expressions.

Tu connais le next_expression_index de Samuel Stearley? (Cf. forum TICT.) Il est nettement plus rapide que celui de AMS. Donc on peut aller vite tout en gardant la compatibilité avec AMS!

- Beaucoup de pushage/popage sur l'EStack.

Pourquoi penses-tu qu'il y en aurait moins avec un format différent??? Le nombre de pushes/pops de la pile d'expression dépend des algorithmes de calcul utilisés, pas de la représentation tokénisée exacte.

Je vais vous proposer mon format (le dernier en date) de gestion de calcul formel (J'en change tres recemment).

Il faut repondre a ces contraintes : + Quelles sont les fonctionnalites frequemment necessaires pour un CAS ?

Il va de soi que les premières fonctionnalités à implémenter sont celles utilisées le plus fréquemment, mais il faut quand-même viser à tout implémenter! Parce que les fonction utilisées peu fréquemment sont quand-même utiles, et nécessaires pour la compatibilité avec AMS.

+ Rapidite
+ Taille Etc

Ces critères sont beaucoup moins importants que la compatibilité avec AMS. Et la taille (à la fois celle du code et celle de la tokénisation utilisée) est plus importante que la rapidité. Peu importe que ta routine prend 1s de moins si elle donne une erreur de mémoire dès qu'on lui passe une expression un peu plus compliquée à cause d'une représentation tokénisée excessivement longue.

Link a écrit :
N'y aurait-il pas un moyen d'utiliser les deux formats, avec par exemple un token spécifique pour dire que ce n'est pas le format d'AMS?! L'inconvénient est certainement que cela risque fort de doubler la taille dudit CAS...

... ce qui fait que c'est une très mauvaise idée.
Et je ne comprends pas votre obsession à vouloir faire un format incompatible avec celui d'AMS. Quel intérêt? Le format d'AMS a fait ses preuves, il marche très bien.

paxal a écrit :
Rapidité et taille: La taille à mon avis ne devrait pas dépasser 64ko de fonctions (pour ne pas dépasser un bloc en ROM, si j'ai bien compris toutes ces histoires).

Un CAS complet en 64 KO??? C'est du n'importe quoi.
Si c'est pour faire un CAS 4 opérations, ce n'est pas la peine.

La rapidité, quand à elle, n'est pas fondamentale, puisque le but de PedRom n'est pas d'avoir un CAS sofistiqué et ultra-rapide. Ceux qui veulent des maths ne prendront pas PedRom de toute manière, ils garderont AMS pour un résultat plus sur (quoi que parfois...)

Je ne vois pas pourquoi tu veux limiter la portée de ton projet de cette manière.

paxal
a écrit : Peut-être vaudrait mieux-t-il convertir à chaque fois les entrées et les sorties, pour les rendre compatibles.

Pourquoi pas travailler directement sur la représentation de AMS? C'est plus rapide et plus simple (donc donnera du code plus petit).

Pollux a écrit :
Déjà, - et / sont remplacés par +(-1*x) et *x^(-1)...
Les fonctions hyperboliques n'ont à mon avis pas besoin de token spécifique, on peut se contenter de remettre en forme le résultat (et c'est peut-être ce que fait le TIOS) Reste plus que exp, ln, sin, cos, tan(?), dérivée, primitive.

Pour les transformations effectuées par AMS, cf. http://tigcc.ticalc.org/doc/estack.html#top_estack.

paxal a écrit :
alors à ce moment là +,*, et neg. le ^-1 est un peu lourd je trouve, / est une bonne solution.

AMS utilise ^(-1) pour coder la division en interne, et ils ont certainement une bonne raison.

Surtout que à mon avis "^" demande ln et exp. ln ne demande pas de division mais exp si.

AMS garde les ^ tels quels si l'exposant est entier, mais les convertit en exp et ln s'il ne l'est pas.

Pollux a écrit :
> alors à ce moment là +,*, et neg.
> le ^-1 est un peu lourd je trouve, / est une bonne solution. Je ne crois pas, 1/x^2 risque d'être un peu lourd à gérer à ce moment là. En plus ça simplifie toutes les règles de distributivité.

Et en plus c'est ce qu'utilise AMS.

> Surtout que à mon avis "^" demande ln et exp. ln ne demande pas de division mais exp si. mmm on peut faire un tag '^' pour les puissances entières? ça simplifierait tout ce qui est développement par le binôme de Newton. Je ne sais pas trop ce que fait AMS...

AMS, dans sa forme simplifiée pour usage interne (celle donnée par push_internal_simplify) utilise le tag correspondant à ^ pour les puissances entières et les tags exp et ln pour le reste.

> Autre chose: ne pas oublier les opérateurs logiques. yup mais c plus le domaine du calcul formel (même si ça reste dans le domaine de l'évaluateur)

Si, un CAS est censé simplifier not (not x and not y) en x or y par exemple. (AMS le fait.) Ça reste du calcul formel.

Mais arrêtez de dire que je n'essaye pas de détruire son projet!

Labsus extrêmement révélateur

paxal> je n'ai pas trop essayé desolve, mais je ne crois pas qu'il sache résoudre bcp plus que des équations linéaires jusqu'au 2è ordre? il suffit d'utiliser une intégration et hop

> Si, un CAS est censé simplifier not (not x and not y) en x or y par exemple. (AMS le fait.) Ça reste du calcul formel.
Moui, mais il ne simplifie pas vraiment plus que ça ((x and y) or (x and not y)) C plus ce que j'appelle de l'évaluation

Bon j'ai peut-etre pas bien reflechit sur la taille. Toujours est il que ce CAS n'est pas là pour se substitué à celui de TI. La ROM n'est pas faite pour faire des maths.

Ben, je pense que la compatibilté pour le CAS entre AMS et PedRom n'est pas primordiale si qqn trouve une meilleure facon d'implémenter la tokénisation ...

Et je ne comprends pas votre obsession à vouloir faire un format incompatible avec celui d'AMS. Quel intérêt? Le format d'AMS a fait ses preuves, il marche très bien.

Pouvoir réutiliser ou adapter du code existant ? Eviter de devoir coller à AMS sachant que tout ne sera pas forcement implémenté au final ?

Ca fait une contrainte en moins, c'est toujours ça, surtout sur quelque chose d'aussi compliqué qu'un CAS.


Quelqu'un a regardé PariGP ?

Il n'y avait pas de calcul formel très élaboré à l'époque où je m'y étais intéressé (intégration numérique uniquement par exemple, dérivé formelle limitée) mais les fonctions de base étaient là.

Et en plus il y a un coeur en ASM68k, mais avec peut-être des instructions pas disponibles sur 68000 de base (ça compile sur 68030 en tout cas). Je sais pas si c'est dûr à adapter ou pas.

Et surtout c'est en GPL

Double-K->Moi non plus je ne vois pas trop l'utilité d'un CAS incompatible avec AMS... Et rien qu'en postant la remarque sur la taille double je savais que cea était impensable... Je pense que la compatibilité est primordiale (et je suis connu ici pour cela)

Littleboy
a écrit : Eviter de devoir coller à AMS sachant que tout ne sera pas forcement implémenté au final ?

Même une implémentation partielle, mais compatible (pour ce qui est implémenté) est mieux qu'une implémentation totalement incompatible (et également partielle).

Et puis une implémentation partielle peut être complétée avec le temps.

Même une implémentation partielle, mais compatible (pour ce qui est implémenté) est mieux qu'une implémentation totalement incompatible (et également partielle).
Et puis une implémentation partielle peut être complétée avec le temps.

Je suis parfaitement d'accord avec ça

Mais tu ne prend pas en compte une donnée "légèrement" importante

Pour le moment on a le choix entre:
-une possible implémentation incompatible mais cohérente et éprouvée (je dis possible parce qu'il faut voir ce qu'on peut garder; encore une donnée à prendre en compte)
-pas d'implémentation du tout

Maintenant si tu es en mesure de fournir quelque chose d'équivalent à PariGP et compatible AMS, ne te gène pas .

En attendant je préfère avoir quelque chose d'incompatible que rien du tout...

Paxal et autres parlent de réimplémenter un CAS, pas d'en adapter un existant.

LittleBoy non plus, on parle de qqc d'équivalent. Mais comme je l'ai déjà dit, le but n'est pas de concurrencer le CAS de TI. Pour ceux qui veulent des maths il y a la ROM officielle

de toute façon avec les fonctions d'import/export, c possible d'émuler le CAS d'AMS, non?

A mon avis il n'y a aucun problème, excepté peut-etre pour les variables crées. Par contre ces fonctions ralentiront les programmes

oui, mais le but c pas avant tout qu'ils marchent?

Alors prenont un format compatible

J'ai commence a porter le coeur de pari en 68000 pur.

> Alors prenont un format compatible
pkoi? je vois pas le rapport avec le "alors"...

bah si tu veux que tous les programmes marchent, ca va être très dur, sauf si on utilise un format externe, utilisé par la machine, celui de TI, et un format interne. C'est peut-etre possible après tout... faut voir, faut reflechir.

PpHd: J'ai commence a porter le coeur de pari en 68000 pur.

Je vais regarder la source de plus près

> sauf si on utilise un format externe, utilisé par la machine, celui de TI, et un format interne. C'est peut-etre possible après tout... faut voir, faut reflechir.

A mon avis c la meilleure solution puisque ça offre pas mal de flexibilité en plus.

Et ya pas moyen, pour les TI-92 normales avec module + de shunter tout ou partie du CAS (pour les fonctions panquantes par exemple) qui sont présentes sur la ROM de base ?
Je sais que ça n'est pas une solution correcte (surtout si les deux CAS sont incompatibles), et surtout, je ne sais pas si c'est possible.