yugos a écrit :
[...]
2)En c je n'ai jamais u l'occasion de le verifier parce qu'il ne me serait jamais venu l'idee de gerer une partie de puissance 4 en quitant chaque tour le programme principale.
Oui je dis bien gerer une partie de puissance 4 car il me faut + que la colonne joué par l'adversaire ou meme le tablo actuelle.
Il me faut les stat des 2 joueurs, le nb de coup joué depuis le debut autant de parametre me diras tu ethaniel qui peuvent etre calculé à partir du dernier coup joué.
Mais bon il est aussi question d'efficacité entre une incrmentation de 1 pour le nb de coup joué et recompter a chak fois toutes les piece....
Bref je vais pas m'emmerder a rajouté des fonctions pour recalculer, convertir, enregistrer,lire des variables pour satisfaire MONSIEUR qui veut absolument faire son arbitre.
Donc t'as solution est trop contraignante surtout quand il existe des solutions + simple donc on oublie cettte histoire d'arbitre on a pas besoin d'un programme pour savoir qui est la meilleur ia.
[...]
Ps:la discussion est clause ethaniel ton idee n'est pas genial et meme si elle l'est il y a plus simple.
faire le tournoi manuellement ou avec link duera tres certainement - longtemps ke cette polymik de 10 pages sur l'arbitre.
[...]
Puisqu'il faut une argumentation par a+b, allons-y gaiement ...
Hypothèses de départ :
(A) je ne programme qu'en TI-Basic, pas en C ou en Asm
(B) il était prévu de faire tourner les 2 (deux) IA sur 1 (une) seule calculatrice
(C) on ne peut pas faire tourner simultanément 2 programmes sur une TI
(D) toutes les IA sont sur un pied d'égalité
Je précise que la proposition (B) a été énoncée explicitement il y a maintenant 2 ans (et 11 jours), dans
ce post, et que tout le monde était d'accord avec ça jusqu'à aujourd'hui ...
(A) => mon IA sera en TI-Basic
=> il existera pour le concours au moins une IA en TI-Basic
=> (A') le protocole de jugement des IA doit accepter les IA en TI-Basic
(B) ET (C) => (E) il faut qu'une IA appelle l'autre IA en tant que sous-routine OU (E') il faut qu'un programme tiers appelle les deux IA à tour de rôle
Or (E) est incompatible avec (D), donc (B) ET (C) ET (D) => (E')
On a (E') => (F) le programme tiers appelle les deux IA en tant que sous-programmes OU (F') le programme tiers appelle les deux IA en tant que librairies
Or (F') <=> (F'') les IA sont des librairies écrites en C ou en Asm
Donc (F') est incompatible avec (A'), donc (A) ET (B) ET (C) ET (D) => (F)
Et (F) => (G) les deux IA sont des programmes qui démarrent, jouent leur demi-coup, puis s'arrêtent
Mon idée d'arbitre (apparue en page 4 seulement, d'ailleurs) est donc un IMPERATIF dû aux 4 hypothèses de départ.
Pour faire autre chose, il faut donc obligatoirement invalider une de ces 4 hypothèses.
Il est totalement impossible d'invalider (A), point barre.
J'ai déjà un nombre incommensurable de projets en attente (dont certains datent de 5 ans maintenant) donc apprendre le C ou l'Asm sur TI devra attendre que quelques-uns de ces projets soient achevés pour libérer de la place, c'est-à-dire pas avant quelques années.
Il est totalement impossible d'invalider (C), c'est un impératif technologique.
Invalider (D) revient à définir certaines IA comme Master, lesquelles lanceront les autres IA définies comme Slave, lesquelles doivent de toute façon s'arrêter complètement une fois leur demi-coup joué, donc ça ne résoud rien.
Et comment faire s'affronter 2 Masters ou 2 Slaves ?
Donc (D) ne peux pas être invalidé.
Il ne reste donc que (B) qui puisse être invalidé, ce qui donne :
NON(B) on utilise 2 calculatrices, une par IA
Et NON(B) => ceux qui n'ont qu'une seule calculatrice à disposition sont dans la mouise ...
Et personellement, je n'ai qu'une calculatrice à disposition ...
D'ailleurs, par câble, on ne peut transmettre que des variables TI de base, donc ton programme en C devra de toute façon gérer au moins une variable TI de base (qui, au hasard, s'appelera
colonne 
!) ... enfin à vrai dire, je ne sais pas comment sont gérés
SendCalc et
GetCalc en C et Asm.
La seule différence, c'est que là, au moins, ton IA n'aura pas à s'arrêter à chaque demi-coup, pour la simple raison qu'elle monopolisera en permanence une calculatrice à elle toute seule

!
Pour moi, ça ne changera pas grand-chose, puisqu'il me suffira de dire à mon arbitre que l'adversaire d'EthanIA est un autre programme qui, au lieu d'être une vraie IA, ne servira qu'à faire le lien entre l'arbitre et le câble (10 lignes de TI-Basic à tout casser).
Il faudra juste que l'on me prête une calculatrice pour lancer l'adversaire d'EthanIA.
Je propose donc de reprendre le protocole détaillé au
post 196, et d'offrir deux possibilités :
* soit le programme met à jour
colonne dans son dossier et s'arrête (cas de mon IA)
* soit le programme envoie
colonne par
SendCalc, puis se met en attente par
GetCalc
Attention cependant : lorsqu'il faut transmettre à la fois
colonne et
nom par câble, l'ordre est important, et
colonne sera reçue/envoyée avant
nom (puisque c'est la valeur de
colonne qui détermine s'il faut gérer
nom en même temps).
Grâce à ça, toutes les IA se comprendront facilement, et les IA ne sont pas obligées de s'arrêter à chaque demi-coup.
Note : EthanIA première du nom n'est pas un réseau de neurones formels, c'est un algorithme textuel tout bête.
Par contre, EthanIA Jr (je n'ai pas encore cherché de nom) sera bien en RNF + AG.
@++