Fermer

Algorithmique et lancer de rayons sur calculette graphique

Technique, mais ça en jette ! :)

Envoyé par Libel le 5 février 2023 à 18h27

Précédent

Touche Q ou GAUCHE pour passer au fichier précédent

14 commentaires

         

 

Tri par popularité  

  Tri chronologique

Suivant

Touche D ou DROITE pour passer au fichier suivant
+ 2 -

lebaud07

Énorme taf
Il y a 1 an
+ -2 -

magnussoren Ver (re-)cyclable

ok..quand je pense que j'avais une piètre image de moi ce dimanche parce que je m'emmerdais un peu et que j'ai enregistré 2 chansons WTF ....
Il y a 1 an
+ 1 -

KukuLele Vermisseau

Ah oui belle prouesse.Seule une partie du code est en assembleur. Je me demande si entièrement en assembleur il y aurait un gain significatif en vitesse.
Dommage, je n'ai que la Ti-83, je ne sais pas si je peux tester.
Il y a 1 an
+ 4 -

Lalinea Vermisseau

J’ai passé toute ma scolarité à coder en Basic sur ma Ti 82 stat fr et sur le site http://tout82.free.fr/forum/
J’ai fait une bonne trentaine de programmes.
Je suis content de voir que les gens continuent dix ans après :)
Il y a 1 an
+ 2 -

Toto769 En réponse à Lalinea Vermisseau

Dommage que je ne connaissais pas ce site à l'époque.
J'avais codé aussi plusieurs jeux sans grandes prétentions (enfin pas autant que toi) pendant les cours de maths et d'histoire (ouai c'était plus difficile de justifier le fait que je passais tout le cours sur la caltos!).
Je me demande si je l'ai toujours ou si j'ai fait des sauvegardes de mes programmes.
Il y a 1 an
+ 1 -

KukuLele En réponse à Lalinea Vermisseau

Le site d'un pote d'enfance (dont hélas je n'ai plus de nouvelles) : http://tiplus.free.fr/
Un vrai fada. A l'époque, il avait réussi à souder un haut-parleur à sa TI-89 et il avait donc des jeux avec l'audio :)
Il y a 1 an
+ 1 -

john5 En réponse à Lalinea

Pareil j’étais très fan. J’avais réalisé une sorte d’équivalent de "maze war" sur une Casio graph35, et j’avais même fait l’éditeur de niveau qui va avec :)
Gros challenge technique d’ailleurs car avec la faible vitesse d’affichage il fallait utiliser des astuces toutes pétées pour avoir quand même une vitesse de jeu correcte...
Image de john5
Il y a 1 an
+ 8 -

john5

Il dit que la raison pour laquelle c’est lent est que c’est un langage interprété. Bullshit ! Un interpréteur bien optimisé peut être quasiment aussi performant qu’un programme compilé.
La vraie raison est que le business des calculatrice est une arnaque en bande organisée. Malgré les progrès technologiques, les calculatrices n’ont quasiment pas évolué depuis 20 ans continuent pourtant à se vendre pour un prix prohibitif. Par exemple, la TI84 utilisée dans cette vidéo coûte 160€. Qu’est-ce qui justifie ce prix ? Rien du tout, il n’y a aucune technologie particulièrement coûteuse dedans, le processeur est ridicule, l’écran est un vieux LCD dégueulasse en basse résolution, bref, un raspberry pi à moins de 40€ est dix fois plus puissants et a 10 fois plus de technologies et de fonctionnalités embarquées. C’est un racket organisé dont les écoliers (ou plutôt leurs parents) sont les premières victimes...
Il y a 1 an
+ 1 -

robby En réponse à john5 Vermisseau

alors je vais répondre qu'au deux premières phrases car sur le reste je sus assez d'accord. Un langage interprété est toujours largement plus lent qu'un programme compilé. Je pense que tu fais une confusion entre un interpréteur et un transpileur ou une compilation au lancement. Interprétation est toujours très longue car elle demande de répéter tout un tas d’opération à chaque instruction. Et pour certain langage c'est la seule solution car les références ne peuvent pas être résolues avant l’exécution du code afin d'en connaître un contexte (assez courant pour les langages non typé).

Dans le cas du Basic c'est effectivement un langage facile a optimiser, mais les calculatrices actuelles sont limités en consommation d’énergie, ce qui implique des microcontrôleurs lents et une faible quantité de mémoire. Ce qui empêche l'optimisation de interprétation, et une compilation au lancement. Malgré tout on trouve des calculettes qui demandent de compiler les applications avant de les exécuter.

voila, c’était le moment technique qui n'apporte rien, vous pouvez fermer ce site est reprendre un activité normale
Il y a 1 an
+ 0 -

john5 En réponse à robby

Heu, non c’est faux, pas "largement". Les différences peuvent dépendre de pleins de chose et notamment du à quel point le code est optimisé pour la tache qu’on veut lui faire faire, mais globalement les différences sont d’un certain pourcentage et certainement pas de plusieurs ordres de grandeur
On pourrait discuter longuement sur les détails mais les chiffres parlent mieux que des mots : 
https://www.sci...60481/60481.pdf
Ce qui est sûr que ce n’est pas la raison PRINCIPALE pour laquelle le monsieur de la vidéo met 6 heures pour générer une frame.
Il y a 1 an
+ 0 -

robby En réponse à john5 Vermisseau

je vais pinailler, mais dans le document la catégorisation entre interprété/compilé et faite en fonction du langage ce qui est clairement une erreur aujourd'hui. Il existe très peut de langage (sur ordinateur) qui sont encore exécuté en mode purement interprété.

après on peut s’arrêter sur les chiffres comme ils sont plus parlant, sur le premier test le meilleur langage compilé (Clojure) fait a peut prés 169 fois plus rapide que le plus rapide des langages interprétés (Perl). Dans le document les résultats sont présentés sur une échelle logarithmique.
Il y a 1 an
+ 0 -

jul En réponse à robby Lombric

Vous avez fait du langage machine ?
Tu charges les données relativement au code, puis le code et ensuite tu pointe vers la pile d'instruction et la Execution Unit (CPU du passé) dépile en décodant instruction après instructions.
L'assembleur compile en langage machine qui lui au final est toujours interprété.
Tout les langages finissent interprétés. La lenteur relative interprété/compilé est en fait surtout dû à savoir si les instructions du langage sont proches du métal (surtout l'accès mémoire)
Ex le M1 d'apple interprètent à la volée du code machine X86 (rosetta2) sans quasiment de faiblesse sur un RISC car les malins d'apple ont intégrés les instructions TRES lentes à émuler de la FPU et le réordonnancement mémoire dans la CPU.

Au final le code est *TOUJOURS* interprété. L'interprété est donc toujours plus rapide :D
Il y a 1 an
+ 0 -

Libel En réponse à john5 Vermisseau

Moi j'aime bien quand les moyens sont proportionnées au besoin Pourquoi équipé les collégiens en raspberry ? Pas besoin.

Et tant qu'à dénoncer un racket fait à l'éduc. nat., autant parler de l'instabilité des programmes pour faire acheter des manuels. En papier.

Et enfin, non. Non un langage interprété ne peut décemment entré en compétition avec un langage de programmation compilé quant à la rapidité d'exécution.
Il y a 1 an
+ 0 -

john5 En réponse à Libel

Est-ce que j’ai dit qu’il fallait équiper les collégiens de raspberry pi ? J’ai dit que c’était une arnaque au prix où c’était vendu. Je n’aurais aucun problème pour les équiper avec du vieux matos qui fait le taf tant que c’est vendu au prix que ça vaut vraiment.
Sur les langages interprétés, voir ma réponse à Robby.
Il y a 1 an
Inscrivez-vous ou Connectez-vous pour envoyer un commentaire
84