probleme sur mon morpion

[critor]

je n'ai pas compris le truc du not(J-J) je ne comprend pas en quoi cela inverse le J=0 de plus dans mon programme une troisieme possibilité entre en compte celle de la présence de l'ia (le joueur a le choix entre jouer seul ou a deux )

C'est de la logique.
Sur les TI-z80, 0 veut dire faux, et 1 veut dire vrai.
not(J) signifie tout simplement le contraire de J.
Le contraire de 0 est 1, et le contraire de 1 est 0.

[tama]

en fait, not(J)->J ça serait la même chose que (pour prendre un code à ton niveau) :

Lbl 1
...
If J = 1
Then
Goto 2
End
If J = 0
Then
Goto 3
End
Lbl 2
0 - J
Goto 1
Lbl 3
1 - J
Goto 1

Ca fait une belle optimisation non ? 15 lignes en moins, pouf, 1/2 page Word en moins avec une seule instruction
J'avais ouvert un topic y a longtemps pour mettre quelques astuces (optimisation/codes utiles...) = http://tibank.forumactif.com/programmat ... -t1251.htm

[jacques]

jbofcalc : si tu ne comprends pas trop ce que tama t'explique (il n'y a pas de honte : moi aussi j'avais du mal au début ; et même toujours maintenant), je te conseille quand même de bien prendre le temps d'étudier ça car le Ti-basic étant un langage assez lent et peu lisible (sur un écran de TI) on a tout intérêt à faire un code le plus optimisé possible.

[tama]

disons que ce n'est pas spécialement important au début, on doit d'abord avoir un code qui marche avant de penser à l'optimiser et on est tous passés par là au début, même les meilleurs d'entre nous aujourd'hui, mais tu te rendras vite compte que tes programmes sont lents et alors il faudra penser à optimiser, enlever un maximum de goto pour les remplacer par des boucles For/While par exemple. D'ici 2 ans si t'es toujours en train de programmer, tu regarderas les 20 pages que tu viens de faire et tu te marreras bien en pensant à tous les progrès que tu as fait depuis

[Bisam]

disons que ce n'est pas spécialement important au début, on doit d'abord avoir un code qui marche avant de penser à l'optimiser

Je ne suis pas tout-à-fait d'accord.
Un bon code est un code qui n'a pas besoin d'être optimisé car il a été réfléchi et structuré avant d'être rédigé. L'idéal est d'écrire directement le meilleur code qui soit.
En pratique, il y aura toujours un petit malin qui dira : on peut améliorer ci ou ça... mais l'essentiel est d'avoir réfléchi à pourquoi on l'a écrit de telle manière et comment on aurait pu faire autrement.

PS : Même après des années de programmation, tu oublieras toujours un cas particulier auquel tu n'avais pas pensé ou plus simplement une parenthèse fermée au mauvais endroit qui te fera des erreurs complètement inattendues, etc...

[Marco]

(A ne prendre en compte que lorsque le programme est fini, optimisé
 

Show/Hide spoilerAfficher/Masquer le spoiler

Enfin c'est vrai jusqu'à un certain point sur 83+ (et les z80 en général) : il faut optimiser le code, mais AUSSI la taille, étant donné qu'il y en a peu de disponible. On en a à gogo sur un PC mais sur TI, ça reste un challenge de faire le plus court possible.

Sinon +1 Bisam : toujours faire au brouillon avant, surtout quand on débute. Avec l'expérience on s'habitue à prendre plus de distance avant de commencer, mais il faut toujours avoir une bonne idée de la structure du programme auparavant.

[tama]

+1 Bisam aussi, il faut commencer par coder sur papier avant de se lancer dans la programmation sur TI/machine, et réfléchir sur comment coder telle fonction pour qu'elle marche bien.
Ce que je voulais dire dans mon post c'est qu'une fois le code commencé, il faut le finir et ne pas penser aux optimisations qu'on pourrait faire en plein milieu d'une fonction, réserver ça pour après quand on est sûr que ça marche, parce que si ça foire, il faut remettre ce qu'on a modifié et ce n'est pas toujours évident, surtout si le code est mal fait/mal commenté
Pour le PS je suis aussi totalement d'accord, les erreurs de débutant arrivent aussi aux meilleurs programmeurs du monde, les points-virgules oubliés en C ou les "=" au lieu des "==", des petites erreurs comme ça qui provoquent une cascade d'autres erreurs, et on passe parfois plus de temps à les chercher qu'à coder (expérience malheureusement vécue )

[Marco]

Pour le PS je suis aussi totalement d'accord, les erreurs de débutant arrivent aussi aux meilleurs programmeurs du monde, les points-virgules oubliés en C ou les "=" au lieu des "==", des petites erreurs comme ça qui provoquent une cascade d'autres erreurs, et on passe parfois plus de temps à les chercher qu'à coder (expérience malheureusement vécue )

Au fait tu cherches toujours une corde ? (Je dois bien avoir un truc comme ça qui traîne...)

[tama]

nan c'est bon j'ai trouvé un cable RJ-45

[jbofcalc]

merci beaucoup en fait dans le not(j) ce que je n'avais pas compris c'était le fait que la calculette considère 0 comme l'inverse de 1 et merci pour ces conseils ^^