Bonjour,
je programme habituellement en TI-basic sur ma calculatrice, vu que je me contente de petits programmes mathématiques qui font surtout usage des fonctions de l'AMS.
Je sais (je crois) que l'on peut utiliser les fonctions mathématiques de la TI en C, mais gagne-t-on en vitesse d'exécution là-dessus ?
A part pour les graphiques, où gagne-t-on sensiblement en vitesse en passant au C ? Manipulation de listes, boucles for ?
Zeph Le 06/10/2009 à 21:44 Si tu utilises les fonctions natives de la Ti en C, je ne suis pas sûr que tu gagnes tant que ça. Un peu, certes, puisque toute l'exécution même de ton programme se passe d'une couche d'interprétation qui est excessivement lente. Mais les fonctions mathématiques d'AMS manipulent des structures de données pas toujours prévues pour être traitées rapidement, et que tu sois en C ou en Basic il ne se passera rien de miraculeux de ce coté.
Par contre, si tu peux transcrire les traitements simples de tes programmes en C et ne conserver des appels aux fonctions mathématiques que pour les parties un peu plus complexes, tu pourras probablement en tirer un gain beaucoup plus intéressant.
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Merci de la réponse rapide !
En ce moment, j'essaie d'améliorer un fonction de résolution que j'avais prévue pour l'utilisation avec le programme RPN. Comme on peut mettre des raccourcis clavier dans tous les sens avec RPN, et qu'il est tellement rapide j'avais il y a un certain temps créé une fonction gsolve() [guess_solve, quelle contradiction!], qui en gros ne prenais qu'un argument, l'expression à résoudre, et gsolve devait déterminer s'il s'agissait d'une équation à une ou deux inconnues, d'une equa diff, qu'elle était la variable et à quoi c'était égal, pour ensuite tout balancer au solve() de l'AMS. Parce que je suis traumatisé par la syntaxe des eqd ou des équations simultanées que je n'arrive jamais à retenir, et que j'en ai marre d'écrire que la variable c'est x, ou que oui ! l'équation est bien égale à 0 (je suis physicien...).
genre gsolve(3x+2 and y-2x=a), ou gsolve(3x+2 = 0 and y-2x=a), ou gsolve({3x+2,y-2x=a}) me renverrait {x=-2/3,y=(3a-4)/3}.
Bon, je m'enflamme un peu.
En résumé, j'essaie de faire une analyse de l'expression entrée (c'est pour cela que je révise la fonction part() sur l'autre rubrique du forum). Alors, ça n'était pas très long, mais... un petit temps de réflexion avant d'afficher le résultat, que j'aimerais, pour l'utile et pour le plaisir, réduire au minimum.
Il y a beaucoup de IF dans mon programme (je fais des SWITCH/CASE, mais en TI-BASIC...), donc là-dessus on peut gagner un temps significatif ? Mon programme n'est pas très gros ni très lent... disons 1/2 s supplémentaire à l'exécution, mais ça créé une latence qui ne fait pas propre.
Comme dit Zephyr, faut savoir si la latence est principalement dûe à tes structures de contrôle (if, for, manipulation de variables etc...), ou alors aux fonctions de calculs mathématiques. Si ce sont les fonctions mathématiques qui bouffent le temps, t'auras pas grand chose à y gagner. En C, tu ne feras que les appeler différemment, mais ce seront les mêmes fonctions.
Par contre, en effet, t'as gros à gagner sur l'algorithme de ton programme.
A toi de voir ce que signifie gros dans ton cas, si c'est quelques centièmes de seconde, tu ne gagneras que ça...
Zeph Le 06/10/2009 à 22:16 (cross avec la réponse de Folco)
On sort un peu du cadre du C, mais de mémoire les "if" ne sont pas les plus consommateurs de temps dans les programmes en Basic. La seule chose à vraiment éviter ce sont les goto (et pire, les goto avec indirections, mais je ne me souviens plus s'ils sont traités à part) qui provoquent une recherche dans l'intégralité du programme pour retrouver le label correspondant.
Mis à part ça, je ne sais pas trop... mais pour résoudre des équations je suppose que la grosse partie est traitée par solve() et autres fonctions Basic, et donc passer en C ne donnera, à mon avis, rien qui vaille le coup de consacrer du temps à une conversion.
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
(cross aussi)
C'est vrai, ça risque de n'être que quelques dixièmes de secondes...
Mais c'est peut-être pour moi l'occasion de me lancer dans le C... j'ai toujours eu un peu peur de me frotter à sa syntaxe quelque peu obscure à mon goût. Jamais réussi à dépasser le basic, à part quelques infidélités en python.
Bah, je me lance, et je reviens demander de l'aide dans pas longtemps !
Bah, j'aurai ainsi l'occasion d'apprendre des choses, ça n'est jamais inutile.
La programmation du CAS est beaucoup plus puissante, et bien sûr plus rapide, quand elle est faite en C (plutôt qu'avec "part").
La puissance vient du fait qu'on peut utiliser des fonctions de plus bas niveau, et donc utiliser des algos totalement différents. C'est ce que j'avais fait quand j'avais réimplémenté le Delta^2 d'Aitken de MathTools en C: utilisation de replace_top2_with_sum() plutôt que de créer une nouvelle liste et de la stocker dans une variable (ce que faisait la version BASIC).
Donc ça veut dire que l'on pourrait réécrire en C la fonction solve() et gagner en vitesse ? Ou réécrire une fonction desolve(), parce que celle de la ti est lente et pas très efficace...
On peut donc dire que le calcul formel est plus puissant et plus rapide si on le programme en C ?
Non, le calcul formel de ta TI est déjà écrit en C. Par contre, si tu cherches de la vitesse, tu pourrais, au moins pour te renseigner, jeter un oeil sur le CAS de PedroM qui est 100 fois plus efficace.
PpHd Le 07/10/2009 à 19:33 La version à jour de MAYLIB n'est disponible que dans le répertoire src/lib de l'archive PedroM 0.82 (l'archive dans l'archive).
(Et il n'y a pas de fonction solve).
uview ne marche pas sous PedroM ????????
uview sur PedroM 0.82 : ROM CALL NOT AVAILABLE (plein écran, blanc sur fond noir pour le texte)
RPN sur PedroM 0.82 : error : invalid command (dans une fenêtre)
(sur TiEMu)
***
merci pour l'adresse de MAYLIB
et du LaTeX, quel bonheur !
Invalid command pour RPN, c'est normal.
uView, c'est plus surprenant. En traçant dans TIEmu, je vois qu'uView utilise des relocations style kernel (jsr xxx.l vers la routine qui déclenche l'erreur), ce qui va rendre le debugging plus difficile :'(
[EDIT: c'est dans une fonction qui exécute HeapAllocPtr(2*LCD_SIZE) puis deux memcpy(dest, LCD_SIZE, src), avant de faire un jsr xxx.l vers la routine qui déclenche l'erreur. On n'a pas les sources d'uView.]
Pour ma culture, pourquoi c'est normal pour RPN ?
Farewell Le 07/10/2009 à 19:58Edité par Farewell le 07/10/2009 à 20:03 Parce que j'imagine qu'il utilise des fonctions du Ti-Basic sur l'estack, non impémentées dans PedroM.
)).
##tisogni##
.