Vous avez du temps pour coder ? concours d'Intelligence Artificielle - Page 9

jfg a écrit : *j'ai rien à dire et je le montre*

Pour ça, il y a les blogs ...

Critiquer le language plus puissant est différent de critiquer le language moins puissant. "C'est comme ceux qui critiquent le fait que je ne programme sur x86 qu'en Asm alors qu'ils trouvent que c'est un vieux langage pourri ... " -> pas une comparaison adapté

On critique tous les langages de programmation que j'utilise (alors que je n'ai pas vraiment le choix, puisque ce sont les seuls que je connaisse) c'est comparable, du moins de mon point de vue.

@++

#mac# tu connais aussi le php

donc le C et tout ce qui fait des blocs entre {} et des if()

je trouve que les discussion partent un peu dans tous les sens.beaucoup s'enflame pour peu de chose.
Rappelons que l'on est dans le forum "algorithmie et optimisation". j'insiste bien sur algorithmie il est pas question de savoir dans quel langage va t'on le programé, pire encore si l'ont va pouvoir faire des passsage de variables...
Il s'agit de faire une ia de puissance 4.
je ne doute pas que tous ceux qui veulent s'y tenter savent faire une interface graphique representant le jeu.
Au risque de decourager ethaniel l'évolution du jeu pour moi est enregistrer dans une struture genre pointeur englobant la map les stat des joueur,le board...
deja il y a tres certainement incompatibilté d'algorithme entre son interface et mon ia, je suppose que pour d'autres ca doit generer d'autre probleme.
J'ai fait pas mal de concours et vous sembler ignorer ce que cela represente.
ds un concours il ne s'agit pas de savoir si il y a egalité des chances (par exemple certainne vienne de prepas d'autre de fac pour un meme concours)
ce que je veut dire, c'est que ceux qui programerons dans un langage plus lent s'exposeront a plus de restrictions
mais attention une ia recursive mal implementer peut tres bien faillir devant un generateur de partie type demandant moins de ressource
conclusionarticiper le plus possible y compris ceux qui ne savent pas programmer (en effet meme si il ne sera pas testé on peut jugé facilement de la complexité de l'algo...)
Meme ceux qui ne sont pas encore au stade de l'ia et qui sont encore au stade de la detection de la victoire proposer un code.
Rien que sur ce point la je connais au moins 5 facons de resoudre ce probleme

La solution: On va tous simplemement reporté les coups joué à la main comme ca deja été fait pour concours ulterieur sur casio en utilisant 2 machine (une ti et vti par exemple)
il suffira simplement d'inclure une interface pour rentrez les coup (en clair humain vs computer)


j'espere que maintenant les messages vont contenir des algo des questions des conseils des optimisations... plutot que des futilité.
ps:j'espere que pas été trop cru.
dsl pour le roman

Oui ça peut être une solution mais c'est assez lourd...

Enfin bon dans le cas d'un interfaçage avec ticon45 on pourrait facilement faire en sorte qu'un des joueurs soit humain ^^

yugos a écrit :
je trouve que les discussion partent un peu dans tous les sens.beaucoup s'enflame pour peu de chose. Rappelons que l'on est dans le forum "algorithmie et optimisation". j'insiste bien sur algorithmie

Certes ...

il est pas question de savoir dans quel langage va t'on le programé, pire encore si l'ont va pouvoir faire des passsage de variables...

Si on veut faire s'affronter des IA facilement, je pense au contraire que si, il est question de savoir si on peut faire des passages de variables (cf. la suite) ...

Il s'agit de faire une ia de puissance 4. je ne doute pas que tous ceux qui veulent s'y tenter savent faire une interface graphique representant le jeu.

Si les 2 IA s'affrontant y vont chacune de leur interface graphique, je te laisse imaginer le bordel monstrueux que ça va donner.
Une IA est faite pour réfléchir et donner le résultat de ses réflexion, pas de dessiner la grille et les pions.

Au risque de decourager ethaniel l'évolution du jeu pour moi est enregistrer dans une struture genre pointeur englobant la map les stat des joueur,le board...

Tu enregistres ça dans ce que tu veux, moi je le fais dans des variables TI de base.
Je rappelle que chaque IA dispose d'un répertoire complet, et dois se terminer (EndPrgm) une fois le demi-coup déterminé.
Le répertoire et toutes les variables qui s'y trouvent servent à enregistrer l'évolution de la partie pour qu'une fois l'IA lancée (le programme repart donc du début), elle sache tout ce qui s'est déjà passé.

deja il y a tres certainement incompatibilté d'algorithme entre son interface et mon ia, je suppose que pour d'autres ca doit generer d'autre probleme.

A part si ton IA est incapable de donner un chiffre entre 1 et 7 et de l'enregistrer dans une variable de base de TI, je ne vois pas du tout ce qui peut être fondamentalement incompatible.

J'ai fait pas mal de concours et vous sembler ignorer ce que cela represente.
ds un concours il ne s'agit pas de savoir si il y a egalité des chances (par exemple certainne vienne de prepas d'autre de fac pour un meme concours)
ce que je veut dire, c'est que ceux qui programerons dans un langage plus lent s'exposeront a plus de restrictions
mais attention une ia recursive mal implementer peut tres bien faillir devant un generateur de partie type demandant moins de ressource
conclusionarticiper le plus possible y compris ceux qui ne savent pas programmer (en effet meme si il ne sera pas testé on peut jugé facilement de la complexité de l'algo...)
Meme ceux qui ne sont pas encore au stade de l'ia et qui sont encore au stade de la detection de la victoire proposer un code. Rien que sur ce point la je connais au moins 5 facons de resoudre ce probleme

A l'origine, ce topic n'est pas prévu pour que chacun mette ses bouts de code au fur et à mesure et se serve de ceux des autres, sans quoi chacun aura au final la même IA.
L'objectif est que chacun cherche de manière assez indépendante afin d'avoir le plus de diversité possible (pas bien grande, certes, mais quand même un peu).
Bien sûr, si quelqu'un a quelques difficultés, on l'aidera, mais on le lui prémâchera pas le boulot (du moins, je ne le ferai pas), sinon, autant directement copier/coller un algo tout prêt trouvé sur Internet, et ce topic/concours perdra au passage tout intérêt.

La solution: On va tous simplemement reporté les coups joué à la main comme ca deja été fait pour concours ulterieur sur casio en utilisant 2 machine (une ti et vti par exemple) il suffira simplement d'inclure une interface pour rentrez les coup (en clair humain vs computer)

1/ C'est vraiment très lourd.
2/ Si ton programme est capable d'afficher un nombre entre 1 et 7, il doit bien être capable de le copier dans une variable de base TI, non ?
Ca se fait tout simplement en TI-Basic, et je doute fortement que ça soit impossible en C ou en Asm.
Si ton IA sait faire ça, c'est bon, elle est déjà compatible aux trois-quarts avec mon arbitre (qui marche parfaitement bien depuis presque un an maintenant, s'il était buggué, je l'aurais vu).

j'espere que maintenant les messages vont contenir des algo des questions des conseils des optimisations... plutot que des futilité.

Pas de code 'prêt à réchauffer' SVP ...

ps:j'espere que pas été trop cru.

Non, pas du tout, tu donnes ton point de vue, je ne décèle aucune trace d'aggressivité, je ne vois donc rien de 'cru' ou désobligeant.

dsl pour le roman

Bof, il y a pire (cf. les plaintes déposées à l'encontre de mes pavés ... mais je tente de me corriger).

@++

Ethaniel
:

Au risque de decourager ethaniel l'évolution du jeu pour moi est enregistrer dans une struture genre pointeur englobant la map les stat des joueur,le board...

Tu enregistres ça dans ce que tu veux, moi je le fais dans des variables TI de base.
Je rappelle que chaque IA dispose d'un répertoire complet, et dois se terminer (EndPrgm) une fois le demi-coup déterminé. Le répertoire et toutes les variables qui s'y trouvent servent à enregistrer l'évolution de la partie pour qu'une fois l'IA lancée (le programme repart donc du début), elle sache tout ce qui s'est déjà passé.

L'argument "en Basic ça se fait très bien" n'est pas très convaincant

Qu'est-ce qui 'se fait très bien en TI-Basic' ? Enregistrer l'évolution de la partie (je crois avoir compris, à l'instant, ce que voulait dire la phrase doublement citée ci-dessus) ?
Si c'est ça, oui, ça se fait très bien, même si le programme ne tourne pas pendant que l'adversaire joue (l'arbitre est là pour lui dire ce que vient de jouer l'autre).

Voudrais-tu donc dire qu'il est impossible de créer et modifier une variable TI de base avec un programme en C ou Asm ?

Rappel à tous, pour éviter des discussions vaines : je ne programme sur TI-89/92+ QUE en TI-Basic, je n'ai jamais écrit une traître ligne de code de C ou d'Asm pour TI-89/92+, et je ne compte pas m'y mettre avant au moins 2023 ...
Donc même si je sais ce qu'est un pointeur ou une structure, je ne sais pas du tout comment ça marche sur TI.

@++

T'as quand même fait de l'asm x86, non ?

Un pointeur, c'est une variable qui contient non pas un entier, mais l'adresse d'une zone mémoire ; or si tu appelles deux fois le même programme, les adresses vont changer d'une fois sur l'autre. Ce qui fait que pour pouvoir correctement sauvegarder et restaurer l'état du programme, il va falloir parcourir *toutes* les structures de données à sauvegarder, et transformer toutes les adresses en offsets par rapport au début de la zone mémoire (en laissant intact les entiers, en prenant en compte le fait que les adresses peuvent venir de pleins de zones mémoires différentes, etc...), puis faire la transformation inverse pour la restauration.

Pourquoi sauvegarder et restaurer l'état du programme ?
Pourquoi ne pas enregistrer l'état de la partie (une matrice 6x7 remplie de 0, 1 et 2, par exemple) dans une variable externe au programme (au hasard, une variable TI de base) ?
A chaque demi-coup, lorsque l'IA est relancée, elle lit le contenu de cette variable externe, elle lit le contenu de colonne, autre variable externe, et elle sait donc où en est la partie et peut choisir son demi-coup en conséquence.

Si les IA en C doivent obligatoirement être lancée en début de partie et ne se terminer qu'en fin de partie, comment lancer 2 IA en même temps, pour la même partie, sur la même calculatrice ?

@++

Ethaniel :
Pourquoi sauvegarder et restaurer l'état du programme ?
Pourquoi ne pas enregistrer l'état de la partie (une matrice 6x7 remplie de 0, 1 et 2, par exemple) dans une variable externe au programme (au hasard, une variable TI de base) ?
A chaque demi-coup, lorsque l'IA est relancée, elle lit le contenu de cette variable externe, elle lit le contenu de colonne, autre variable externe, et elle sait donc où en est la partie et peut choisir son demi-coup en conséquence.

Mais on s'en fout de *où* c'est stocké (variable externe ou pas), le pb c'est qu'on ne peut pas stocker des pointeurs sans avoir des grosses routines de conversions pour que les pointeurs restent valident à la prochaine exécution...

Si les IA en C doivent obligatoirement être lancée en début de partie et ne se terminer qu'en fin de partie, comment lancer 2 IA en même temps, pour la même partie, sur la même calculatrice ?

C'est tout l'intérêt des bibliothèques : ça permet de charger deux bouts de progs en même temps, et d'appeler l'un puis l'autre à tour de rôle.
Le pb c'est que ça interagit mal avec les IA en Basic : il y a bien une fonction kernel pour lancer un prog, mais elle n'est (selon PpHd) pas très stable pour les progs basic.

J'en reviens donc à ma question initiale, le noeud de l'affaire : est-il possible, oui ou non, de gérer les variables TI de base avec un programme en C ou en Asm ?

@++

Oui, mais c pas le "noeud"... Le pb c'est qu'il faut faire plein de conversions...

Bof. Moi je vois pas pourquoi entre 2 coups, t'aurais forcément 200 pointeurs à sauvegarder.

y'a plein de fonctions pour lire des variables et faire renvoyer des valeurs, déconnez pas.

http://tigcc.ticalc.org/doc/htretval.html

bon ben ethaniel moi j'ai fini mon ia de puissance 4.
quand a ton arbitre je suis pas convaincu.
poste la source de ton arbitre pour que je change mon code en consequence.
parce qu'il est difficile de faire un code sans savoir comment est le coup de l'adversaire.
Deuxio tu semble n'avoir pas saisie le probleme soulevé par pollux
Mais demander à un programme de gerer l'evolution du jeu en se redemarant à chaque tour (puiskil va etre lance tous les demi coup n'est vraiment pas pratik et ce sans prendre le moindre argument) d'autant plus qu'il pose des probleme d'adresse de pointeurs.
genre l'evolution du jeu "game_state" doit etre conserver à chaque tour d'autre probleme se pose comme tu fois le savoir à la fin de partie toutes la memoire utilisé par un programme en c doit etre liberer.
Or tu proposes que ce soit ton arbitre qui gere la detection de la victoire.Il y a d'autre chose qui pose problemes...
de + l'interetde ton arbitre est limité il complik enoremement la gestion de la partie et la gestion des variables.
Comme l'as fait remarqué pollux, si c'est pour verifier qu'aucun programme ne triche (un peu parano) la meilleur solution est tous simplement de reporter les coups ainsi on en sera sur. Ca permet à chacun de faire la gestion de la partie comme il l'entends, c'est universel du moment que tous le monde dessine une grille 7*6.
en plus ce system n'est pas lourd du tout contrairement a ce que tu pense.2 ou 3 partie suffiront à departager une ia puisque de toutes facon aucune des deux n'est aptes à apprendre sur ses defaites.
Surtout il n'y a pas enormement de participants ca sera vite fait de departager les ia.

Ps: pour te montrer que je ne fais pas preuve de muavaise volonté j veux bien voir comment arranger mon code pour qu'il soit compatible avec ton interface mais dans ce cas la post ta source.
Mais bon je ne te cache qu'elle n'est vraiment pas lumineuse ton idee.

yugos a écrit : bon ben ethaniel moi j'ai fini mon ia de puissance 4.

Vraiment ? Chapeau !
Perso, j'espère pouvoir terminer ma première IA (avec une algorithmie classique) d'ici 2023 ...
Plus sérieusement, le temps libre me manque énormément.

quand a ton arbitre je suis pas convaincu. poste la source de ton arbitre pour que je change mon code en consequence.

J'espère donc que voir mon arbitre à l'oeuvre de convaincra un petit peu plus !
Par contre, comme je l'ai déjà expliqué, mon arbitre détecte les alignements avec une méthode optimisée qui, de par sa spécificité, est à la base même de mes IA (ou plutôt, pour ma seconde IA, 'qui sera' #vapor# ).
La politique de non-prémâchement de code et de méthode allant à l'encontre d'une sortie publique anticipée (comprendre 'avant les confrontations'), j'ai donc commencé à le reprogrammer avec un algo beaucoup plus basique, tout en y intégreant des features au passage ...
Au risque de me répéter, j'espère pouvoir rendre disponible la version finale (en TI-Basic) d'ici fin décembre, mais je ne promets rien ...
Mais j'ai déjà expliqué comment rendre ton IA compatible avec mon arbitre : savoir lire (le demi-coup venant d'être joué par l'adversaire) et écrire (le demi-coup que ton IA décide de jouer) dans une variable TI nommée colonne, et garder une trace de la partie en cours pour les périodes où le programme ne tourne pas.

parce qu'il est difficile de faire un code sans savoir comment est le coup de l'adversaire.

Le demi-coup que vient de jouer ton adversaire est indiqué dans ta propre variable colonne (c'est-à-dire celle qui est dans ton répertoire).

Deuxio tu semble n'avoir pas saisie le probleme soulevé par pollux
Mais demander à un programme de gerer l'evolution du jeu en se redemarant à chaque tour (puiskil va etre lance tous les demi coup n'est vraiment pas pratik et ce sans prendre le moindre argument) d'autant plus qu'il pose des probleme d'adresse de pointeurs. genre l'evolution du jeu "game_state" doit etre conserver à chaque tour d'autre probleme se pose comme tu fois le savoir à la fin de partie toutes la memoire utilisé par un programme en c doit etre liberer.

Sans le moindre argument : l'argument, c'est la variable colonne ...

Oui, je sais qu'un programme en C (et en n'importe quel langage, d'ailleurs) doit libérer toute la mémoire utilisée lorsqu'il se termine (sauf un hook, évidemment).
C'est pourquoi, en TI-Basic, j'utilise des variables TI de base (enregistrée extérieurement au programme) pour garder une trace de ce qui se passe pendant que l'IA ne tourne pas.
D'ailleurs, vous ne m'avez toujours pas répondu clairement sur la possibilité de gérer ces variables en C ...

Or tu proposes que ce soit ton arbitre qui gere la detection de la victoire.Il y a d'autre chose qui pose problemes... de + l'interetde ton arbitre est limité il complik enoremement la gestion de la partie et la gestion des variables.

Franchement, je ne trouve pas : lorsqu'une IA est lancée, elle lit l'état de la partie juste après son dernier demi-coup, elle lit la réponse de l'adversaire, elle réfléchit, elle enregistre sa réponse dans une variable, et elle s'arrête jusqu'à ce que se soit de nouveau son tour ...
Vraiment, je ne vois pas du tout comment faire plus simple que cela.

Comme l'as fait remarqué pollux, si c'est pour verifier qu'aucun programme ne triche (un peu parano) la meilleur solution est tous simplement de reporter les coups ainsi on en sera sur. Ca permet à chacun de faire la gestion de la partie comme il l'entends, c'est universel du moment que tous le monde dessine une grille 7*6.

Ce n'est pas pour vérifier qu'aucun programme ne triche (c'est impossible), c'est pour faire s'affronter 2 IA sur la même calculatrice alors qu'il est impossible de faire tourner 2 programmes en même temps.

en plus ce system n'est pas lourd du tout contrairement a ce que tu pense.2 ou 3 partie suffiront à departager une ia puisque de toutes facon aucune des deux n'est aptes à apprendre sur ses defaites.

Faux ... ma seconde IA sera du type 'réseau de neurones formels', avec une matrice synaptique optimisée par algorithmes génétiques.

Surtout il n'y a pas enormement de participants ca sera vite fait de departager les ia.

Ca, c'est bien vrai ...

Ps: pour te montrer que je ne fais pas preuve de muavaise volonté j veux bien voir comment arranger mon code pour qu'il soit compatible avec ton interface mais dans ce cas la post ta source.

Plutôt que de décortiquer l'arbitre, il te sera plus simple de lire le comportement que devront avoir les IAs.

Mais bon je ne te cache qu'elle n'est vraiment pas lumineuse ton idee.

Désolé, mais c'est la seule que j'aie trouvée pour faire s'affronter 2 IA en TI-Basic (et j'insiste sur le langage) sans autre action de l'opérateur humain que le lancement de la partie (sauf éventuellement configurer certains paramètres).
Si tu as une autre proposition, je suis preneur ...

@++

je la refais pour les ceusses qui codent en C: http://tigcc.ticalc.org/doc/htretval.html

Il y a un bon moyen d'empêcher de tricher, c'est de faire s'exécuter les deux programmes sur des calculatrices différentes, avec une communication par link uniquement. Comme ça, chaque programme peut vérifier de manière efficace que l'autre ne triche pas.

On risque pas les pertes de com? Bonjour pour synchroniser le protocole.

LIO_Send/RecvData, tu connais? AMS fait tout le travail pour toi! Le link LIO, c'est facile!

ah oui pardon. Mais j'avais essayé, j'avais un problème de timeout. En même temps j'étais moins expérimenté que maintenant. OK.
Par contre, est ce qu'on ne tombe pas (avec un link) dans quelque chose de superbement plus compliqué qu'un petit groupe de variables dans un dossier? j'ai vu tourner le truc d'Ethaniel, je pense que soit vous avez pas compris ce qu'il a fait, soit il vous faut l'essayer, car d'après ce qu'il m'a montré, ca fait ce que vous attendez.

C'est vrai que, indépendamment de la triche (dont on a un peu rien à foutre, quoique un bug involontaire dans une IA pour *vraiment* faire chier l'autre), le link pourrait bien être la manière la plus simple de faire... (avec cmd_sendcalc)

Ethaniel & squalyl> bien sûr que le pb n'est pas de créer ou modifier des variables tios C'est écrire *toutes* les vars C du prog dans les vars tios qui est chiant...

oui mais pourquoi toutes?

A la limite vous utilisez pas de pointeur et vous stockez tout dans un binaire. Une sorte de sérialisation, quoi. Et les variables statiques, ca marche pas sur TI?

Une variable statique ne persiste pas quand tu quittes le programme et que tu le relances.

Et une sorte de sérialisation, oui mais pas une sorte, une sérialisation complète de toutes les données. Et c'est ça qui est chiant.

squalyl^2
: Une sorte de sérialisation, quoi.

Exactement. Et il faut donc reconstituer toute la structure du graphe des références mémoire...

Et les variables statiques, ca marche pas sur TI?

Si (si le prog est en RAM et non compressé), mais encore une fois tu passes à côte de *the* problème : ce n'est pas que les données persistent, c'est que les adresses soient mises à jour pour refléter le déplacement des handles entre les deux lancements...


(j'ai un peu l'impression de répéter 5x la même chose, là )

Pourquoi cmd_sendcalc et pas LIO_SendData? Pour accomoder le BASIC?

Ben oui, si l'arbitre est en basic ?

En tout cas si tu as une solution efficace pour lancer du basic à partir du C, exprime-toi (à part faire une sorte de TSR en faisant croire au TIOS qu'on quitte tout de suite mais en restant en mémoire jusqu'à la fin de la partie)

<HS>
Tiens, en parlant de TSR, ça serait pas une bonne idée de faire un truc propre ?
Genre

BEGIN_PIC_TSR(my_tsr,my_tsr_end)
  void EV_hook2() { ... }
END_PIC_TSR()

void install() {
  ...
  memcpy(block,my_tsr,my_tsr_end-my_tsr);
  execute(block + (EV_hook2-my_tsr));
  ...
}

? (et qui mettrait une erreur en cas de relocation dans la zone indiquée)
</HS>

Ce n'est certainement pas "propre", tu ne peux pas appeler une fonction en dehors de la zone, y compris celles générées automatiquement par GCC (__mulsi3 et co.), et en plus il faudrait changer de flags (activer -mpcrel) au plein milieu du fichier, ce qui n'est pas prévu du tout dans GCC.

Justement, ça permettrait d'encapsuler ça proprement, de mettre les erreurs qu'il faut quand on référence des données en dehors de la zone, etc... Là pour l'instant tous les pbs que tu poses sont entièrement ignorés, ce qui fait que pour l'instant les TSR en C sont des gros hacks immondes