[mOved] Un CAS pour Pedrom? - Page 2

Tout à fait d'accord.
C'est un bon point de départ pour l'affichage, pour l'édition c'est déjà plus chaud, on verra ca après...

Mais les questions les plus importantes sont: doit-on garder le même format que TI, et doit-on réécrire les fonctions d'analyse d'expression (le parseur) et les fonctions sur les entiers et les floats, sinon sous quel format ca se passe?

nEUrOne
a écrit : bah c du GPL ca ..

Ce n'est pas sous GPL. Il faut demander la permission à Samuel Stearley avant de traffiquer la source.

paxal
a écrit : Mais les questions les plus importantes sont: doit-on garder le même format que TI

Je dirais oui. Pedrom a pour but d'être compatible avec AMS.

et doit-on réécrire les fonctions d'analyse d'expression (le parseur) et les fonctions sur les entiers et les floats, sinon sous quel format ca se passe?

PpHd a fait une version très incomplète de push_parse_text. Mais elle n'est pas utilisable telle quelle pour un CAS, il faut rajouter toutes les fonctions manquantes.

tu veux dire les fonctions correspondant aux tags?

Plutôt les tags correspondant aux fonctions.

donc compléter la fonction push_parse_text. OK

Je dirais oui. Pedrom a pour but d'être compatible avec AMS.

Je dirais non si tu veux reproduire la même chose autant rester sur AMS

Mais dans ce cas, tu fais comment pour lancer:
* les programmes TI-BASIC écrits pour AMS?
* les programmes mathématiques en C ou en assembleur écrits pour AMS?

ben on les lance pas

Je reste de l'avis que, si on veut la compatibilité avec AMS, on la veut jusqu'au bout. Donc le CAS devrait également être compatible.

On veut sourtout la compatibilité de la plustart des ROMCALL pour ne pas poser de problèmes avec les progs assembleur.

* les programmes TI-BASIC écrits pour AMS?

Le but que Preos n'a jamais été de faire marcher les prog Basic. Il faudrait refaire tout le suport du Basic! Ce n'est pas vraiment la peine puisse que GT Basic devrait arriver bientôt.
[/cite]* les programmes mathématiques en C ou en assembleur écrits pour AMS?[/cite] Je crois qu'il ne peuvent pas fonctionner vu que la pluspart des ROMCALLs de math ne sont pas implémentés. Mais comme je te l'ai déja dis, Predrom n'est pas concue originellement pour les maths. Si tu veux des math garde AMS.
Je ne voit pas l'interet de tout refaire si c'est pour tout refaire al'identique

Kevin Kofler
a écrit : Samuel Stearley a écrit une réécriture complète et plus rapide. Cf. forum de la TICT.

Moi aussi.

Uther Lightbringer a écrit :
Je crois qu'il ne peuvent pas fonctionner vu que la pluspart des ROMCALLs de math ne sont pas implémentés. Mais comme je te l'ai déja dis, Predrom n'est pas concue originellement pour les maths. Si tu veux des math garde AMS. Je ne voit pas l'interet de tout refaire si c'est pour tout refaire al'identique

Je vous laisse debattre. J'ai autre chose a faire pour PedroM.

Kevin Kofler a écrit :
Je dirais oui. Pedrom a pour but d'être compatible avec AMS.

Oui. Mais on perd en performance et en simplicite.
Je serais pour un nouveau format avec des fonctions d'importation/exportation.

PpHd a fait une version très incomplète de push_parse_text. Mais elle n'est pas utilisable telle quelle pour un CAS, il faut rajouter toutes les fonctions manquantes.

Elle a beau etre incomplete, elle m'a enervee. Et ces defaut sont limitees (dira-t-on):
+ Toutes les VAR sont avec le TAG 0 (Meme a une lettre).
+ Pas de difference entre fonction built-in et fonction externe (sin et toto par exemple).
+ Les matrices marchent pas.
C'est tout je crois.

Je serais pour un nouveau format avec des fonctions d'importation/exportation.

Entièrement d'accord

Pas de difference entre fonction built-in et fonction externe (sin et toto par exemple).

Ca me va aussi

Ca ne veut pas dire que c'est le format a garder !

Sa peut etre un avantage qu'il y ai pas de "différence" entre une fonction interne et externe non ?

Certes. Mais le choix doit etre muri et longuement reflechis.

On est là pour en parler.
C'est un débat de lancé

Uther Lightbringer
a écrit : Le but que Preos n'a jamais été de faire marcher les prog Basic. Il faudrait refaire tout le suport du Basic!

La partie la plus dure du BASIC est le CAS! S'il veut coder un CAS, autant le rendre compatible avec le TI-BASIC!

Ce n'est pas vraiment la peine puisse que GT Basic devrait arriver bientôt.

Il ne marchera jamais sur Pedrom s'il n'y a pas de CAS 100% compatible AMS.

Je crois [que les programmes mathématiques en C ou assembleur] ne peuvent pas fonctionner vu que la pluspart des ROMCALLs de math ne sont pas implémentés.

Justement, l'intérêt du CAS est d'implémenter ces ROM_CALLs!
Et pour que les programmes mathématiques marchent, il faut utiliser exactement la même représentation tokénisée.

Mais comme je te l'ai déja dis, Predrom n'est pas concue originellement pour les maths. Si tu veux des math garde AMS.

Si tu ne veux pas de maths, tu n'as rien à faire dans ce topic, titré "Un CAS pour Pedrom?". Le CAS, c'est pour les maths.

Je ne voit pas l'interet de tout refaire si c'est pour tout refaire al'identique

La but de Pedrom est d'être compatible avec AMS. Si ça ne te plaît pas, écris ta propre ROM. PpHd a réussi à écrire une ROM tout seul, donc je ne vois pas pourquoi tu n'y arriverais pas.

PpHd a écrit :
Oui. Mais on perd en performance et en simplicite. Je serais pour un nouveau format avec des fonctions d'importation/exportation.

Mauvaise idée. Les programmes mathématiques en C ou assembleur dépendent de la représentation tokénisée exacte. Si on veut garder la compatibilité avec AMS, il faut utiliser la même représentation sur la pile d'expressions.

Elle a beau etre incomplete, elle m'a enervee. Et ces defaut sont limitees (dira-t-on):
+ Toutes les VAR sont avec le TAG 0 (Meme a une lettre).
+ Pas de difference entre fonction built-in et fonction externe (sin et toto par exemple).
+ Les matrices marchent pas. C'est tout je crois.

Mais vu qu'aucune fonction built-in n'est reconnue, c'est totalement inutilisable pour un CAS compatible avec AMS.
Et tu as implémenté les trucs vraiment compliqués, de style les nombres DMS (1°2'3")?

Mauvaise idée. Les programmes mathématiques en C ou assembleur dépendent de la représentation tokénisée exacte. Si on veut garder la compatibilité avec AMS, il faut utiliser la même représentation sur la pile d'expressions.

On t'a déjà dit qu'on s'en fout

Mais vu qu'aucune fonction built-in n'est reconnue, c'est totalement inutilisable pour un CAS compatible avec AMS.

Kevin, tu dis qu'il faut releaser n'importe quelle beta et après tu critiques parce que c'est une beta?
(et en plus c même pas une beta releasée )

Sa peut etre un avantage qu'il y ai pas de "différence" entre une fonction interne et externe non ?

Pas forcément, je pense qu'il y a qd même pas mal de manipulations qui seraient simplifiées sans avoir à faire un strcmp à chaque fois
Un truc plus simple serait d'avoir un tag "user func" et 1 ou 2 tags "sys func". Ca permet aux fonctions de manip générale de n'avoir à gérer que 2 ou 3 tags, et aux fonctions de simplification des expr (sin/cos -> tan, etc...) de marcher correctement.
Mais ça reste à voir

Pollux a écrit :
On t'a déjà dit qu'on s'en fout

Je ne vois pas l'intérêt de faire une ROM partiellement compatible avec AMS, mais avec des incompatibilités subtiles. Le but était la compatibilité AMS, pourquoi pas le porter jusqu'au bout?

Putain mais Kevin t'es vraiment pas aidé

Tu préfères un viewer de texte horriblement lent avec DrawChar à un viewer ultra-rapide qu'il faudrait convertir pour passer de la ROM 1 à la ROM 2, tu préfères une ROM avec un CAS bcp plus lent et bcp moins puissant pour que le moindre programme de math puisse être exécuté sans conversion, tu préfères t'abstenir de programmer on-calc si le compilo ne gère pas 2-3 extensions GNU inutilisées (genre nested functions)...

Je pense que tu préfèrerais mourir de faim plutôt que de manger quelquechose dont tu ne connais pas l'origine exacte?

Je pense que tu préfèrerais mourir de faim plutôt que de manger quelquechose dont tu ne connais pas l'origine exacte?

LOL

Pollux
a écrit : Tu préfères un viewer de texte horriblement lent avec DrawChar

Tu n'as pas du tout compris la méthode:
* à l'initialisation, on écrit dans un buffer en RAM avec DrawChar
* à l'exécution, on utilise directement ce buffer en RAM!
Le TICT eBook Reader qui utilise ça n'est pas lent!

tu préfères une ROM avec un CAS bcp plus lent et bcp moins puissant pour que le moindre programme de math puisse être exécuté sans conversion,

Le CAS n'en sera pas "beaucoup plus lent et beaucoup moins puissant"! Le format tokénisé de TI est assez bien pensé!

tu préfères t'abstenir de programmer on-calc si le compilo ne gère pas 2-3 extensions GNU inutilisées (genre nested functions)...

Je ne vois pas pourquoi je devrais utiliser un compilateur techniquement inférieur juste pour pouvoir programmer on-calc. De toute façon, programmer on-calc n'est pas pratique pour tester. Et il n'y a pas assez de mémoire on-calc pour faire tenir tous mes projets. (J'ai l'habitude de travailler un peu sur le projet A, puis un peu sur le projet B, puis un peu sur le projet C, puis de nouveau un peu sur le projet A etc.) Et enfin, j'ai un ordinateur, donc je l'utilise.

Je pense que tu préfèrerais mourir de faim plutôt que de manger quelquechose dont tu ne connais pas l'origine exacte?

Kevin Kofler a écrit :
Je ne vois pas pourquoi je devrais utiliser un compilateur techniquement inférieur juste pour pouvoir programmer on-calc. De toute façon, programmer on-calc n'est pas pratique pour tester. Et il n'y a pas assez de mémoire on-calc pour faire tenir tous mes projets. (J'ai l'habitude de travailler un peu sur le projet A, puis un peu sur le projet B, puis un peu sur le projet C, puis de nouveau un peu sur le projet A etc.) Et enfin, j'ai un ordinateur, donc je l'utilise.

Parceque ça permet justement de programmer on-calc !

Mais comme j'ai dit dans l'extraît que tu as cité, personnellement, ça ne me sert pas vraiment.

Moi ca m'est arrivé de programmer on-calc: je suis parti 3 semaines e Malaysie, et j'avais pas d'ordinateur; et bien résultat j'ai programmé on-calc, avec un petit feuillet de doc, et j'avais qd même internet (1 fois par semaine...) pour chercher les docs que j'avais pas prises.
D'où le on-calc: c'est super!

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.

En tout cas, il faudrait vous décider si le CAS doit être compatible avec AMS ou pas, ou alors faire 2 CAS différents, parce qu'au sinon, vous allez débattre 6 mois et jamais le faire parce que vous serez pas d'accord!