Game of Life
Re: Game of Life
@Clément.7 Il faut stocker le nom d'une variable, appvar, ... dans une Str, qui ensuite, permettra de faire des manipulations. Une variable normale comme A, B, ... ne peut contenir d'adressage comme les Str qui sont prévues pour cela. Si tu faisais de l'ASM, tu saurais que pour modifier une variable, il faut d'abord stocker l'adresse de la Str contenant le nom de la variable puis la charger, et enfin, si elle existe, à partir de l'adresse chargée, y accéder pour la modifier
-
Ti64CLi++Modo
Niveau 16: CC2 (Commandeur des Calculatrices)- Messages: 3441
- Images: 75
- Inscription: 04 Juil 2014, 14:40
- Localisation: Clermont-Ferrand 63
- Genre:
- Calculatrice(s):→ MyCalcs profile
- Classe: ENS Rennes
- GitHub: Ti64CLi
Re: Game of Life
Comme je viens de programmer une version du jeu de la vie en assembleur (eZ80, pour la TI83PCE) Je déterre un peu ce sujet portant sur la version TI-Basic. Peut-être que toutes les pistes d'optimisations n'ont pas encore été exploitées..?
(si l'on s'éloigne de l'algorithme classique qui consiste à "traiter toutes les cellules)
Afin de doubler la capacité d'affichage en mode texte, Je me suis dit d'afficher non pas une mais deux cellules par case:
-le caractère ° ou o représentant une cellule
-le caractère 8 représentant 2 cellules
Ce qui nous donne une grille 16x16
(par contre, le o minuscule sera peut-être plus difficile d'accès sur TI82A, mais ça reste faisable via un transfert depuis un autre modèle TI, ou un fichier manuellement modifié)
(si l'on s'éloigne de l'algorithme classique qui consiste à "traiter toutes les cellules)
Afin de doubler la capacité d'affichage en mode texte, Je me suis dit d'afficher non pas une mais deux cellules par case:
-le caractère ° ou o représentant une cellule
-le caractère 8 représentant 2 cellules
Ce qui nous donne une grille 16x16
(par contre, le o minuscule sera peut-être plus difficile d'accès sur TI82A, mais ça reste faisable via un transfert depuis un autre modèle TI, ou un fichier manuellement modifié)
Dernière édition par grosged le 17 Nov 2016, 15:18, édité 1 fois.
-
grosgedVIP++
Niveau 14: CI (Calculateur de l'Infini)- Messages: 770
- Images: 75
- Inscription: 14 Sep 2011, 12:29
- Genre:
- Calculatrice(s):→ MyCalcs profile
Re: Game of Life
Pas mal comme technique, mais ça oblige à faire plus de test par carré. Après, peut-être que en réel c'est assez rapide.
A tester
A tester
-
Ti64CLi++Modo
Niveau 16: CC2 (Commandeur des Calculatrices)- Messages: 3441
- Images: 75
- Inscription: 04 Juil 2014, 14:40
- Localisation: Clermont-Ferrand 63
- Genre:
- Calculatrice(s):→ MyCalcs profile
- Classe: ENS Rennes
- GitHub: Ti64CLi
Re: Game of Life
Ti64CLi++ a écrit:Il faut stocker le nom d'une variable, appvar, ... dans une Str, qui ensuite, permettra de faire des manipulations. Une variable normale comme A, B, ... ne peut contenir d'adressage comme les Str qui sont prévues pour cela.
Une variable peut parfaitement contenir une adresse! Les str sont juste une adresse statique (totalement deprécated depuis le temps d'ailleurs), alors que si tu stocke l'adresse dans une variable tu peux la modifier. Bon après, accéder à un octet pointé par une variable, c'est un peu plus lent que pour une adresse statique. Donc, qu'il utilise D n'est en soit pas gênant.
Bref, sinon, sur les algorithmes possibles, on pourrait essayer de skipper les larges zones où il n'y a pas de cellules vivantes, puisque on aura pas de naissance dans ces zones. Bon, le problème, c'est que ça risque de n'être valable à peu près que pour l'asm cette opti >_>
-
TheMachine02Modo
Niveau 16: CC2 (Commandeur des Calculatrices)- Messages: 341
- Images: 0
- Inscription: 16 Jan 2013, 18:27
- Genre:
- Calculatrice(s):→ MyCalcs profile
- Classe: Médecine
Re: Game of Life
Pour l'instant , je n'ai pas encore d'idée pour éviter de traiter inutilement les zones désertes.
Quant à l'approche des "cellules mémorisées par groupe de 2", elle comporte certains avantages
Imaginons que l'on code 2 cellules par case en choisissant une dizaine pour la cellule supérieure, une unité pour la cellule inférieure...
L'exemple suivant:
8 o °
o ° 8
sera codé :
1 0 1
1 1 0
0 1 1
1 0 1
la somme des 8 cellules voisines supérieures (c-à-d entourant la cellule 1 ) sera de
11+10int(01/10)+10 + int((01+10+11)/10) = 23
et la somme des 8 cellules voisines inférieures (c-à-d entourant la cellule 1 ) sera de
10fPart((11+01+10)/10) + 01+10int(01/10)+11 = 14
Alors, on remarque que si l'on additionne les dizaines aux unités (donc 2+3 et 1+4) , on arrive bien au résultat de 5 (ce qui correspond au nombre de cases voisines )
On pourrait aussi constituer une table de référence L2 avec L2(23)=5 et L2(14)=5 ... etc...
(à voir si cela s'avérerait plus rapide..?)
Toujours est-il qu'il nous suffit de ne consulter que 6 éléments pour quantifier les voisins de 2 cellules !
Avec une grille de 16x16 stockée dans L1, on va travailler avec 6 variables A,B,C,D,E,F contenant chacunes un groupe de 2 cellules:
A B C
D E F
Au départ, on aura donc...
L1(P→A
L1(P+1→B
L1(P+2→C
L1(P+16→D
L1(P+17→E
L1(P+18→F
puis , on calculera les 2 voisinages (supérieur et inférieur)
Ensuite, ce qui est intéressant, c'est qu'il nous suffira de considérer la zone suivante à traiter comme:
B C A
E F D
Avec A et B les 2 eléments nouveaux à consulter:
L1(P+3→A
L1(P+19→D
...et la 3ème étape sera:
C A B
F D E
donc :
L1(P+4→B
L1(P+20→E
Enfin , la 4ème étape s'apparentera à la toute première:
A B C
D E F
donc :
L1(P+5→C
L1(P+21→F
Etc, etc...
Voilà!...Je n'ai, pour l'heure, encore rien testé, mais comme cette astuce diminue le nombre d'accès-mémoire, je pense que ça ferait moins "ramer" la TI
_______________________________________________________________________________________________________________
EDIT : Je me demande...On pourrait peut-être faire encore moins de calculs, et décider de créer/supprimer/laisser dans l'état les 2 cellules centrales, et ce, rien qu'en analysant judicieusement ces 6 éléments !.. (la table de référence serait alors plus fournie...)
_______________________________________________________________________________________________________________
re-EDIT: ça y est ! ça se précise : avec une table de référence L2 constituée de la sorte:
-les unités contenant la valeur de la cellule centrale,
-les dizaines et centaines contenant le nombre de cellules voisines!
Donc, avec...
A B C
D E F
le pointeur sur la valeur se rapportant au groupe constitué des 9 cellules supérieures sera calculé ainsi:
1+10(A+C)+B+10int(.1(D+E+F
on ajoute 1 car la TI n'accepterait pas L2(0
et le groupe inférieur :
1+int(.1E)+10(D+F+10fPart(.1E)+int(.1(A+B+C
(mmmm...pas terrible ce dernier calcul)
Quant à l'approche des "cellules mémorisées par groupe de 2", elle comporte certains avantages
Imaginons que l'on code 2 cellules par case en choisissant une dizaine pour la cellule supérieure, une unité pour la cellule inférieure...
L'exemple suivant:
8 o °
o ° 8
sera codé :
1 0 1
1 1 0
0 1 1
1 0 1
la somme des 8 cellules voisines supérieures (c-à-d entourant la cellule 1 ) sera de
11+10int(01/10)+10 + int((01+10+11)/10) = 23
et la somme des 8 cellules voisines inférieures (c-à-d entourant la cellule 1 ) sera de
10fPart((11+01+10)/10) + 01+10int(01/10)+11 = 14
Alors, on remarque que si l'on additionne les dizaines aux unités (donc 2+3 et 1+4) , on arrive bien au résultat de 5 (ce qui correspond au nombre de cases voisines )
On pourrait aussi constituer une table de référence L2 avec L2(23)=5 et L2(14)=5 ... etc...
(à voir si cela s'avérerait plus rapide..?)
Toujours est-il qu'il nous suffit de ne consulter que 6 éléments pour quantifier les voisins de 2 cellules !
Avec une grille de 16x16 stockée dans L1, on va travailler avec 6 variables A,B,C,D,E,F contenant chacunes un groupe de 2 cellules:
A B C
D E F
Au départ, on aura donc...
L1(P→A
L1(P+1→B
L1(P+2→C
L1(P+16→D
L1(P+17→E
L1(P+18→F
puis , on calculera les 2 voisinages (supérieur et inférieur)
Ensuite, ce qui est intéressant, c'est qu'il nous suffira de considérer la zone suivante à traiter comme:
B C A
E F D
Avec A et B les 2 eléments nouveaux à consulter:
L1(P+3→A
L1(P+19→D
...et la 3ème étape sera:
C A B
F D E
donc :
L1(P+4→B
L1(P+20→E
Enfin , la 4ème étape s'apparentera à la toute première:
A B C
D E F
donc :
L1(P+5→C
L1(P+21→F
Etc, etc...
Voilà!...Je n'ai, pour l'heure, encore rien testé, mais comme cette astuce diminue le nombre d'accès-mémoire, je pense que ça ferait moins "ramer" la TI
_______________________________________________________________________________________________________________
EDIT : Je me demande...On pourrait peut-être faire encore moins de calculs, et décider de créer/supprimer/laisser dans l'état les 2 cellules centrales, et ce, rien qu'en analysant judicieusement ces 6 éléments !.. (la table de référence serait alors plus fournie...)
_______________________________________________________________________________________________________________
re-EDIT: ça y est ! ça se précise : avec une table de référence L2 constituée de la sorte:
-les unités contenant la valeur de la cellule centrale,
-les dizaines et centaines contenant le nombre de cellules voisines!
Donc, avec...
A B C
D E F
le pointeur sur la valeur se rapportant au groupe constitué des 9 cellules supérieures sera calculé ainsi:
1+10(A+C)+B+10int(.1(D+E+F
on ajoute 1 car la TI n'accepterait pas L2(0
et le groupe inférieur :
1+int(.1E)+10(D+F+10fPart(.1E)+int(.1(A+B+C
(mmmm...pas terrible ce dernier calcul)
-
grosgedVIP++
Niveau 14: CI (Calculateur de l'Infini)- Messages: 770
- Images: 75
- Inscription: 14 Sep 2011, 12:29
- Genre:
- Calculatrice(s):→ MyCalcs profile
25 messages
• Page 3 sur 3 • 1, 2, 3
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 9 invités