Posté le 06/12/2017 13:35
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 67 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 06/12/2017 14:33 | #
Si on peut faire largement, mieux, je te retrouve un lien.
Ajouté le 06/12/2017 à 14:35 :
Vlà : http://www.planet-casio.com/Fr/programmation/tutoriels.php?id=21
Ajouté le 06/12/2017 à 14:37 :
Bon à la réflexion t'étais pas si loin que ça de la solution optimale, mais y'a d'autres astuces qui sont évoquées dans le tuto x)
Citer : Posté le 06/12/2017 18:21 | #
Personnellement j'aime le C, je fais des bibliothèques en C, pas en Basic !
Si tu veux que ton utilisateur puisse entrer du code sur le long terme, tu ne pourras pas te contenter d'une formule qui fournit les numéros de touches. Car il faudrait d'abord que tu vérifies que ce que tu manipules est bien un numéro de touche... et ça risque de commencer à te coûter cher.
Darks a bien répondu pour ce qui est des chiffres ; le problème d'optimisation dans le cas plus général est ardu car le Basic n'a aucune notion respectable de programmation. Le mieux serait de séparer l'analyse du code de touche récupéré en paquets, par exemple un paquet pour gérer chaque ligne, et de déléguer chaque paquet à un sous-programme. À ce moment-là, les optimisations précédentes ne s'appliquent plus.
Citer : Posté le 06/12/2017 21:18 | #
3-Int(K-52)/10)+3Ans->A
devient
3-Int(K-52)/10)+3MOD(K-52, 10->A
2 octets d'économisés (Ans et retour à la ligne).
Ensuite LpWhile K=0 devient LpWhile Not K. Ca n'économise pas d'octets, le "Not" prenant 2 octets, mais ça rend le programme un peu plus rapide.
Bien sûr il faudra enlever ce Locate 2, 1, " " qui bouffe quand même 10 octets.
On peut encore grapiller quelques octets sur les Do/LpWhile. Les instructions Do et LpWhile font 2 octets, et une boucle peut être remplacée par des Lbl/Goto qui font 1 octet.
Ainsi
Locate 2, 1, " " //problème initialisation
Locate 1, 1, A
Do
Getkey->K
LpWhile K=0
MOD(K-52, 10
3-Int(K-52)/10)+3Ans->A
A=29=>0->A //le 0 ne marche pas dans cette formule
LpWhile 1
est remplacé par
Locate 2, 1, " " //problème initialisation
Locate 1, 1, A
Do
Getkey->K
LpWhile K=0
MOD(K-52, 10
3-Int(K-52)/10)+3Ans->A
A=29=>0->A //le 0 ne marche pas dans cette formule
Goto 1
Ca économise encore un octet.
On peut remplacer Locate 1, 1, A par juste A, par contre ça affichera les chiffres tapés en succession. Ou sinon ClrText:A qui prend moins d'octets que le Locate.
On peut optimiser cette boucle :
Getkey->K
LpWhile K=0
On utilise la variable Ans, ce qui fait :
Getkey
LpWhile Ans=0
(-2 octets)
On ne peut pas mettre le GetKey dans la condition (LpWhile GetKey=0) car dans ce cas Ans ne marche pas.
Ensuite on peut faire quelques optimisations, si tu affiches A à la fin (d'ailleurs je ne sais pas pourquoi tu l'affiches au début : au tout début il prendra une valeur affectée par le programme juste avant).
On a :
A=29=>0->A
A
LpWhile 1
Il faut savoir que les conditions renvoient 1 pour vrai ou 0 pour faux. Ainsi A=29 renvoie 1 si A=29 et 0 si A != 29.
On peut donc transformer les 2 premières lignes de code en (A≠29)(3-Int(K-52)/10+3MOD(K-52, 10 -> A
Si A != 29 alors 3-Int(K-52)/10+3MOD(K-52, 10->A est multiplié par 1, ce qui lui donne la valeur que tu veux. Si A = 29 c'est multiplié par 0 et donc A = 0.
Par contre vu que A n'est pas encore calculé, ce ne sera pas A mais Getkey (Ans), et pas 29 mais la valeur de la touche 0 qui est 71.
Enfin, on utilise l'affichage implicite :
(Ans≠71)(3-Int(K-52)/10+3MOD(K-52, 10
...qui devrait marcher mais apparemment non, pour une quelconque raison. Du coup on utilisera un Locate.
On remarque qu'on a un Lbl 1 et un Do qui se superposent. Si on convertit la deuxième boucle en label, on peut éliminer le Do, au coût d'un If inline sur le LpWhile Not Ans :
GetKey
Not Ans => Goto 1
Locate 1,1,(Ans≠71)(3-Int(Ans-52)/10+3MOD(Ans-52, 10
Goto 1
Ca économise 2 octets (3 pour le Do+retour à la ligne, -1 pour le If inline)
Si on faisait Ans - 52 avant de faire le calcul, on pourrait remplacer tous les Ans-52 par Ans : ça économise 6-5 = 1 octet.
Locate 1,1,(Ans≠29)(3-Int(Ans)/10+3MOD(Ans, 10
On peut alors économiser 2 octets de plus en enlevant les parenthèses autour du Int(Ans) :
Locate 1,1,(Ans≠29)(3-Int Ans/10+3MOD(Ans, 10
GetKey
Not Ans => Goto 1
Locate 1,1,(Ans≠29)(3-Int Ans/10+3MOD(Ans, 10
Goto 1
D'ailleurs, j'ai testé et ton code originel ne marche pas, du coup j'ai remplacé la ligne par Locate 1,1,(Ans!=71)((Ans-31MOD(Ans,10))/-10+2.
Le code final est donc :
GetKey
Not Ans=>Goto 1
Locate 1,1,(Ans!=71)((Ans-31MOD(Ans,10))/-10+2
Goto 1
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 06/12/2017 22:03 | #
L'optimisation c'est important, mais pas au point de déconstruire toute l'algorithmique. En outre, je suis prêt à parier que les sauts inconditionnels sont significativement plus lents que de garder les boucles si tenté que l'interpréteur soit pas implémenté avec les pieds.
Moins d'octets mais largement plus de clignotement désagréable à l'écran ! Pour cette fois où le nombre ne fait que grandir donc l'effet de bord lié au « non-effacement » n'est pas gênant, c'est pas le moment de laisser filer l'occasion.
Le code final est admirable, mais pitié, ne raisonnez pas en termes d'octets. Raisonnez en termes d'algorithme...