Forum TI-Planet.org

Merci pour ta réponse.
Ton résultat en NPI est correct même si pas écrit dans le même ordre que celui que j'ai mentionné.
J'utilise le langage c car il me permettra de compiler le compilateur d'un nouveau langage de programmation oncalc (ti83pce et éventuellement nspire).
Il y avait bien des cas boiteux avec des pointeurs, mais l'algorithme reste en gros correct et est fidèle à la source.

Je ne suis pas un spécialiste de la NPI, j'en connais que les grandes lignes. L'avantage de python est que les machines que tu cites l'utilise déjà...

C'est exact en théorie; cependant, le pauvre petit ATSAMD21 des 83PCEEP est extrêmement limité
Utiliser C/C++ pour les TI-Z80 est clairement la bonne méthode, d'autant qu'ainsi, le nouveau langage fonctionnera également sur les modèles non Python; comme cela n'a pas de sens de faire et maintenir deux implémentations dans deux langages différents, donc l'implémentation Nspire devrait elle aussi être C/C++.

La 83PCEEP dispose d'un processeur ARM 32 bits dédié pour python. L'autre avantage de python est que le code écrit pour un modèle est utilisable dans une autre sans trop de modifications. Les seules modifications concernées étant liées à tout ce qui touche à l'affichage. Avec les langages C, il faut une compilation pour chaque modèle... Le vrai problème dans le cas présent est le besoin de mémoire et de puissance de calcul. Or seul un processeur multicore comme un ARM est adapté pour ce genre d'applications parce qu'une analyse lexicale et une analyse syntaxique ne se traitent pas de la même manière. En conséquence, sauf à relire plusieurs fois les même données, avantage python...

Non, le coprocesseur ARM des CE est trop peu puissant pour lui donner l'avantage malheureusement. Une base commune C/C++ est donc la seule alternative viable pour calculatrice. Elle pourra être compilée pour Nspire et CE, avec juste la couche d'interaction clavier+affichage de spécifique à la calculatrice ciblée.

Mais bon, faites des essais dans plusieurs langages si vous voulez voir quand même ce que ca donne

Ce qui ne laisse que les nspire comme machine cible. Le C est à oublier, il ne peut pas gérer de threads. Il ne reste plus que le C++ et python. Le second est plus abordable, il n'y a pas de pointeurs à gérer. Comme langage de prototypage, c'est le meilleur choix. Rien n'empêche par la suite une implémentation dans un langage plus typé...

Le C peut parfaitement gérer les threads, qu'est-ce que tu racontes lol.

Mais de toute façon, C'est pas comme si la CE était multithreadé ou multi-core. Sur la Nspire il y a des sortes de threads, oui, mais propriétaires a l'environnement Nucleus.

Mais pourquoi y aurait-il besoin de threads En premier lieu ?

Si le but est de faire un proto rapide sur ordi, oui, go utiliser python. Ca permettra de valider l'algorithme etc. Mais il me semblait que ce n'était pas le but ici.

J'ai posté mon code c de Shunting yard dans un post précédent. J'ai fini par trouvé l'erreur, c'était dans la récupération des priorités des opérateurs avec la liste op_priority[]. L'algorithme respectait bien l'algorithme de shunting yard.
Quant au débat python/C, je pense que le C est bien plus rapide pour une compilation et pour l'interprétation d'un langage. On a accès au code natif également.

Mais pourquoi y aurait-il besoin de threads En premier lieu ?

En TLN une analyse lexicale et une analyse syntaxique sont deux choses différentes, ce qui veut dire deux traitements au minimum...

Le C peut parfaitement gérer les threads, qu'est-ce que tu racontes lol.

En programmation objet, le C n'est pas ce qu'il y a de mieux dans la famille C, en particulier au niveau des structures de données...

C est bien plus rapide pour une compilation et pour l'interprétation d'un langage

Le prototypage consiste à vérifier si un programme fonctionne, pas à chercher à plusieurs endroits une possible erreur de programmation. Ce problème est d'autant plus important que le programme est volumineux. Et je ne parle pas des importations de bibliothèques et autres exotismes...

newprog_creator a écrit:J'ai posté mon code c de Shunting yard dans un post précédent. J'ai fini par trouvé l'erreur, c'était dans la récupération des priorités des opérateurs avec la liste op_priority[]. L'algorithme respectait bien l'algorithme de shunting yard.

Ah, tant mieux si le problème a été trouvé et résolu

newprog_creator a écrit:Quant au débat python/C, je pense que le C est bien plus rapide pour une compilation et pour l'interprétation d'un langage. On a accès au code natif également.

Pour une implementation finale, oui en effet, il n'y a pas vraiment débat. Si tu te sens deja a l'aise avec ca, pourquoi pas

rentech7289 a écrit:

Mais pourquoi y aurait-il besoin de threads En premier lieu ?

En TLN une analyse lexicale et une analyse syntaxique sont deux choses différentes, ce qui veut dire deux traitements au minimum...

Et depuis quand 2 choses différentes = 2 threads différents ?
Les traitements n'ont aucun besoin d'être fait en parallèle. Ce qui ne serait de toute manière pas possible sur calculatrice et ne rajouterait que des contraintes inutiles.

Le C peut parfaitement gérer les threads, qu'est-ce que tu racontes lol.

En programmation objet, le C n'est pas ce qu'il y a de mieux dans la famille C, en particulier au niveau des structures de données....

Il n'y a aucun rapport entre le style de programmation (objet ou non), les structures de données disponibles, et la capacité (ou le besoin) à gérer les threads.

Tu sembles faire beaucoup de mélanges faux/inutiles pour je ne sais quelle raison, et ca risque de perdre tes interlocuteurs qui ne sont pas forcément experts.