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

264> Si , j'ai bien compris le problème des pointeurs, mais est il absolument nécessaire d'en utiliser? Ton graphe est si gros que ca qu'on puisse pas le recopier cash dans la sérialisation? (je n'ai aucune idée de la place qu'il faut pour stocker l'arbre nécessaire à ce jeu)

Je sais qu'un arbre est une liste chainée donc pointeurs vers structs, mais dans le document sérialisé, on peut recopier direct une liste de structs, et les lier par index dans la liste plutôt que par pointeurs vers les suivants/précédents, ou je suis total à côté de la plaque ?

Nan, c'est ça, mais c'est chiant à faire en C à cause de l'absence de réflexion, parce qu'un pointeur peut avoir plusieurs "adresses de base" (i.e. ça peut être pile+index, prog+index, handle 42+index...), etc...

ha bon? je savais pas. je pensais qu'un pointeur (sur ti au moins) était une adresse absolue sur un long.

je vois pas trop ce que tu entends par pile+index, etc... moi je parlais donner un numéro à chaque feuille (sans lien avec l'emplacement mémoire) et utiliser cela pour chainer les feuilles dans la représentation sérialisée.

éthaniel a proposé son arbitre qui aparament ne fait pas l'unanimité.( j'ai moi aussi des pointeurs à sauvegarder et reorganiser mon algo tout'en sachant qu'il y ait des chances que ca plante, ca me fais un peu chier).
Donc la solution la plus simple la moins lourds la moins contraignantes est de tous simplement:
Mettre un bout de code pour receptionner la variable à la place de ngetchx() (la ou vous aves gerez le coups joué par un humain) et de mettre un bout de code pour envoyer le message apres le coup joué.
Ainsi pas la peine de gerer la partie en redemarrant à chaque tour. PLus de probleme de pointeurs, de triche, de conversions de compatibilité avec un "arbitre" qui honettement n'apporte pas grand chose.
Ps : si ca tenait qu'à moi je le repete encore reporter les coup manuellement à l'aide d'un link ou grace à un "arbitre"
peu m'importe.
voila ce qui m'importe:
Qui participe aux concours?(j'espere le plus de monde possible)
A quand fixte t'on la date butoire?(parce kil va bien falloir le faire un jour ce tournoi, de + si elle reste beaucoup de delai je ferais bien de rajouter un petit prog pour que l'ia en apprenne sur defaite, helas ca sera grace aux reseaux de neurones formelles n'est-ce pas ethaniel puiske j'y connais rien mais plutot grace à aux log des defaites)

encore une fois faisons quelques choses qui arrange tous le monde je pense que ca devrait aller ethaniel puisk cmd_send est une commande ti-basic.

démerdez vous

squalyl^2
: ha bon? je savais pas. je pensais qu'un pointeur (sur ti au moins) était une adresse absolue sur un long.

Oui, mais si un handle se déplace en mémoire, ou si tu transfères ton bloc vers une autre calculatrice qui aura forcément un layout du heap différent, ton pointeur absolu n'est plus valide. Donc tu es obligé de passer à une représentation sous forme de HSym (handle+offset, les routines de la VAT utilisent cette astuce à pas mal d'endroits). Et évidemment, le numéro de handle ne sera pas non plus correct sur l'autre calculatrice, il faut le convertir aussi.

exact. Je pensais qu'on parlait de malloc directs. j'avais oublié les handles. ok je comprends.

encore à côté de la plaque squalyl le pb n'est pas que le handle n'est pas locké, le pb c'est qu'il n'aura pas la même adresse d'un lancement sur l'autre (même avec malloc...)

oué bon ca va hein tu connais la vitesse de déformation d'une dislocation coin dans un cristal cubique face centré chauffé à 800°C à 5 mbar? chacun ses études. Je ne fais de la programmation qu'en amateur, et quand j'alloue de la mémoire j'utilise des pointeurs, pas des handles. Je revendique le droit de ne pas y avoir pensé.

On devrait plutôt penser à trouver une solution. Parce qu'après 10 pages on en est au même point, alors que vous êtes censés savoir mieux programmer que moi.

squalyl^2 :
oué bon ca va hein tu connais la vitesse de déformation d'une dislocation coin dans un cristal cubique face centré chauffé à 800°C à 5 mbar? chacun ses études. Je ne fais de la programmation qu'en amateur, et quand j'alloue de la mémoire j'utilise des pointeurs, pas des handles. Je revendique le droit de ne pas y avoir pensé.

[mode=couteau dans la plaie] Justement, ça n'a *rien à voir* avec les handles, et c'est un problème que tu aurais même en C parfaitement standard : si tu fais fwrite(mes_données) dans un fichier, tu ne vas pas pouvoir recharger tes données après avec un simple fread, parce que les pointeurs ne seront pas forcément les mêmes [/mode]
Non, mais je m'en tape
Et le but de mon msg n'était pas de te ridiculiser ou quoi que ce soit, juste de te faire remarquer que c'était pas ce que tu croyais, même si tu croyais avoir compris...

c'est joli en couleurs

je te dirais que je m'en tape un peu aussi, vu que ce dont tu parles, je n'ai jamais eu à le croiser depuis que je programme.

le pb n'est pas que le handle n'est pas locké

mode grain de sel j'ai pompé que zouf: Et on peut pas forcer le pointeur à rester au même endroit?

squalyl^2 :
c'est joli en couleurs

je te dirais que je m'en tape un peu aussi, vu que ce dont tu parles, je n'ai jamais eu à le croiser depuis que je programme.

Mais *justement*, le pb c'est qu'on croiserait ce problème si il fallait rendre la main à l'OS (i.e. si on utilisait la solution d'Ethaniel), or c'est vraiment chiant à gérer DONC la solution d'Ethaniel est bof, ctou...

Et accessoirement, si tu t'en tapes, personne ne t'oblige à répondre... (et promis, si tu fais un topic sur la vitesse de déformation des cristaux à 5 mbar, je répondrai que si ça m'intéresse )

le pb n'est pas que le handle n'est pas locké

mode grain de sel j'ai pompé que zouf: Et on peut pas forcer le pointeur à rester au même endroit?

Exemple pratique :

1er lancement du programme A :
[ul]malloc(12) -> 0x12345
malloc(12) -> 0x23456
-> j'écris {0x12345,0x23456} dans le fichier
Je quitte, les blocs à 0x12345 et 0x23456 sont libérés[/ul]
Lancement d'un autre programme :
[ul]malloc(12) -> 0x12345
Le programme ne libère pas le bloc (par exemple, c'est un fichier qui doit donc rester en mémoire, ou encore le programme ne quitte pas tout de suite)[/ul]
2è lancement du programme A :
[ul]malloc(12) -> 0x23456 (le bloc à 0x12345 n'est plus disponible)
malloc(12) -> encore autre chose[/ul]
Et donc là, on va être dans la merde...

...à moins de disposer d'une mmu

ouais je vois le merdier.
vu comme ça, c'est évident.

Donc il faut que le programme principal ne quitte pas, le mieux (dans l'étendue de mes connaissances) étant d'utiliser une IA par routine, liées à l'exécutable de l'arbitre, donc basic -> poubelle.

je sens la DLL

En plus si tout le monde fait du C, ca permettra aux matchs de ne pas durer 3h si une IA basic fait des calculs de barbare

Donc Ethaniel ouais, ca va être chaud ton arbitre en zicba. Par contre, il se portera facilement en C, si il s'agit juste d'une question d'interface, le C fait ça très bien.

PS: J'y pensais: cela n'exclut pas forcément une IA en basic, si on sait appeler un prog basic depuis un exécutable compilé, et que la valeur de retour de l'IA basic est stockée dans une VAR: l'arbitre asm peut la lire.

Pollux a écrit : 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)

Ca oblige donc les IA à disposer d'un module d'envoi/réception des données et d'affichage graphique, en plus de la fonction de base qui est de décider du coup à jouer en fonction de l'état de la partie.

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...

Et ben voilà, enfin la réponse que j'attendais !

**Toutes** ... il ne faut pas exagérer, tout de même : elles sont au nombre de 2, colonne et etatpart (3 en comptant nom qui n'intervient qu'au tout début et tout à la fin).
La variable etatpart, ou tout autre nom qui vous agréera (evolpart serait ainsi plus adapté pour mon deuxième exemple), pourra par exemple être :
- une matrice 6x7 contenant des 0 (cases vides), des 1 (cases où on a joué) et des -1 (ou des 2, ou des 8, cases où a joué l'adversaire)
- une matrice 6x7 avec des 0 dans les cases vides, la valeur 1 dans la case où a été joué le premier demi-coup, la valeur 2 dans celle où a été joué le deuxième demi-coup, etc.
- une liste de 42 valeurs (juxtaposition des lignes ou des colonnes) correspondant à un des deux cas précédents
- une liste de 42 valeurs contenant des nombre entre 0 et 7 (le premier élément contient la colonne du premier demi-coup, le deuxième élément pour le deuxième demi-coup, etc., et des 0 pour les demi-coups non encore joués)
- n'importe quelle autre représentation plus ou moins alambiquée de l'état ou de l'évolution de la partie
Franchement, je ne pense pas que ce soit la mer à boire ...

A vous lire, j'ai l'impression que vous voulez enregistrer des ko de données, par exemple pour repartir à l'instruction Asm exacte où vous vous en étiez arrêté si c'était possible.
Pourtant, la simple donnée de l'état ou de l'évolution de la partie (etatpart ou evolpart) est amplement suffisant pour décider où jouer.
Imaginez par exemple deux personnes commençant une partie, puis à un moment donné, un joueur quitte la table, son adversaire joue, puis vous remplacez le joueur qui vient de partir.
Tout ce que vous avez, c'est une grille à moitié remplie (cas de la première matrice donnée en exemple, qui donne l'état de la partie à un moment donné), et pourtant, vous pouvez jouer sans problème.
Si vous le souhaitez, vous pouvez même avoir l'historique des demi-coups joués (cas de la seconde matrice donnée en exemple, qui donne l'évolution de la partie jusqu'à un moment donné) pour deviner si le joueur que vous avez remplacé avait commencé à élaborer une stratégie, afin que vous puissiez la mener à bout.
Et si ça se trouve, le joueur précédent aura laissé un petit bout de papier avec écrit dessus quelques idées de startégies possibles selon ce que l'adversaire allait jouer (vous n'êtes pas limité à colonne et etatpart, donc même si c'est chiant, vous pouvez gérer une troisième variable TI de base, ça ne doit pas être le bout du monde).
Ce changement de joueur est strictement équivalent à une IA qui, une fois son demi-coup joué, s'arrête, avant d'être relancée lorsque son tour revient.
Et ne venez pas me dire qu'un humain et une IA ne sont pas comparables en intelligence : le jeu de Puissance 4 est suffisamment simple pour que n'importe quel algorithme basique se débrouille très bien (EthanIA est d'ailleurs un algorithme très basique, hyper-optimisé certes, mais basique tout de même, et il se débrouille très bien rien qu'avec l'état de la partie, il ne garde même pas d'historique des demi-coups joués (quand je vous dis qu'il est basique ...)).
D'ailleurs, je suis à peu près sûr que vos algorithmes, ou du moins leur noyau, se contre-fichent pas mal de prendre une partie en cours, tant qu'ils connaissent l'état ou l'évolution de celle-ci ...
Si vous avez une récrimination majeure à faire concernant cette méthode du je prends la partie en cours de route, je suis toute ouïe.


Je ne commente pas les autres posts, ils sont trop techniques pour moi ...

@++

Je ne commente pas les autres posts, ils sont trop techniques pour moi ...

Tu as tort, toutes les explications sont là pourtant.

non Ethaniel, tu n'as pas encore tout pigé. Pour faire une IA, il faut que des données persistent entre les appels du programme d'IA. Dans le cas d'un programme basic, ce n'est pas un problème, tu utilises des variables globales.

Dans le cas d'un prog en C par contre, les variables de grosse taille sont allouées dynamiquement et nécessitent de stocker les pointeurs.

Or il n'est pas du tout certain qu'un bloc de données référencé par un pointeur soit accessible de la même manière entre les appels, comme l'exemple du post 281.

Je t'en prie, ne fais pas celui qui ne comprend pas le C, ca te va mal

Ce que je ne comprends pas, c'est POURQUOI, en C, personne ne veut enregistrer les données qui doivent persister entre les appels de l'IA, données au nombre de 1 d'ailleurs (etatpart ou evolpart), dans des variables globales TI de base comme le fait un programme TI-Basic, puisque :
1/ les programmes en C savent apparemment gérer les variables TI
2/ ces variables TI ne sont pas soumises au problème de pointage ou autre, puisque l'appel se fait par nom et non par pointeur
3/ la variable qui doit persister a une taille constante et parfaitement connue (pas d'allocation dynamique dans ce cas), à savoir 42 octets plus quelques octets imposés par l'AMS pour typer les variables.
C'est CA que je ne comprends pas ...

@++

Ca, ca s'appelle une sérialisation, c'est une possibilité à laquelle il a déja été fait allusion, mais nous ne sommes pas allés plus loin.

Le tout c'est que le total des données à stocker ne doit pas dépasser 64 ko, ce qui n'est pas évident à priori si ils veulent faire joujou avec des arbres à garder (pour plus gros que 64k, ca va être plus chiant)

Pollux et les autres, une sérialisation des données persistantes est elle envisageable facilement? je pense que oui, à préciser.

En plus si il faut que ce soit généralisé à tous ceux qui bossent en C, ca va être le boxon, ca rajoute une contrainte, cette sérialisation. Alors que si un prog basic est appelable en C comme je le propose en 283, cette contrainte disparait.

#mac#=on

en plus si tu portais ton arbitre en C, ce dernier langage te paraitrait moins mystérieux après

#mac#=off

Bordel faites un mode link et on en parle plus. Ca prend 1/2h et tout le monde pourra facilement utiliser les fonctions. En plus ça exclu les prgm Basic

squalyl^2 a écrit :
Ca, ca s'appelle une sérialisation, c'est une possibilité à laquelle il a déja été fait allusion, mais nous ne sommes pas allés plus loin.

Le tout c'est que le total des données à stocker ne doit pas dépasser 64 ko, ce qui n'est pas évident à priori si ils veulent faire joujou avec des arbres à garder (pour plus gros que 64k, ca va être plus chiant)
[...]

Si le C est si rapide que ça, je ne vois que moyennement l'intérêt de garder un arbre de plusieurs ko, on peut très bien le recalculer à chaque fois à partir de 42 octets (plus 1 octet dans colonne), surtout que le demi-coup que viens de jouer l'adversaire élague 6 des 7 branches.
D'ailleurs, pourquoi ne pas stocker 7 arbres au lieu d'un (ce qui réduira leur taille individuelle), numérotés de 1 à 7 et correspondant à la colonne du coup que va jouer l'adversaire ?
Si l'adversaire joue la colonne 2 (colonne == 2 au lancement de l'IA), seul arbre2 sera chargé, et le premier élaguage sera ainsi fait.

EthanIA recalcule tout à chaque fois (bon, OK, elle ne construit pas d'arbres), et bien qu'elle soit en TI-Basic, ses temps sont honorables.

@++

Attendons l'avis de Pollux, il a l'air de bien maîtriser.

(kross)

Ethaniel :
EthanIA recalcule tout à chaque fois (bon, OK, elle ne construit pas d'arbres), et bien qu'elle soit en TI-Basic, ses temps sont honorables.

càd ?

Ethaniel> En ASM ce serait plus rapide

1)tout d'abord, je confirme si il y a encore des doutes les pointeurs sont des adresses memoires loué dynamiquement.
La premiere chose qu'on nous apprends (pour moi c t en pascal), c'est une fois le programme principale terminer les pointeurs non "liberer" ne sont plus reutilisable.
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.
Preocuppez vous de finir vos ia.
Une fois qu'elles seront toutes publié on sera à meme de jugé qu'elle est la meilleur puisk chacun pourra manuellement reporter les coups (du coup meme les ia en basic sont accepter) pour les + flémard un link pourra etre envisager (c un peu du superflux mais bon) ca doit etre l'histoire de 2 à 3 ligne de codes en + (je me suis jamais interresé au link en c mais je fais confiance à pollux pour nous denicher le code sinon je ferais moi-meme la recherche)
faut savoir simplemement savoir que pour ces raisons le temps de reflexions ne devra pas exceder les 10 sec
quand on sait qu'il y a potentiellement 42 coup à jouer fo pas que la partie dure 3/4 d'heure!
parce qu'on est la aussi pour faire des partie agreable etre efficace.
Ceci dit j'ai hate de voir vos ia à éthaniel pollux, squalil²
on a souvent des surprises des ia plutot faible contre un humain peuvent se revellé grandiose devant certaine 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.
bon + serieusement:
Qui participe?
moi....ethaniel...pollux...squalil²...?
A quand la date butoire?
Je propose juste avant les vacance de noel 1 mois et demi pour pondre kelke chose de correct ca me parait bien (en plus vu l'anceinneté du concours!)?
Link, manuellement, autres solutions?
pour moi manuellemement ca me convient ca sera surtout decouvrir la stratégéie de chak ia qui m'interresera.
(cette question n'est pas super urgente)

voila voila
@+

Au départ je n'avais pas prévu de participer, mais bof pourquoi pas. Au pire si j'ai pas le temps je dirai que je peux pas. Un gros #mac# serait que je ne sais pas comment programmer ce truc, mais bon ce serait vraiement très gros!

Par contre en ce moment je suis en train de faire un clip (ca prend du temps) donc j'ai pas le temps de coder, si vous vous donnez assez de temps je participe sinon non.

bah squalil² fais ton maximum pour etre dans le delai si t'as bien avancé on reculera la date du tournoi je te conseil vivement d'en faire une apres tout c plutot sympa de faire unn petit tournoi d'ia.
nouvelle modalité du concours:

creer un programme qui gere une partie de puissance 4 en mode ia vs humain sur une grille 6 lignes par 7 colonnes.
Seul contrainte : temps de reflexions inferieur à 10 sec.(pe etre à debattre mais ca me parait raisonnable)
presence d'une interface graphique
EVENTUELLEMENT un mode link.
date butoire du tournoi: vacance noel (pe etre à negocier)

Bon je pense que les regles sont assez clairs et peu contraigantes elle laisse libre champs à la maniere dont vous allez gerez votre algo. vous pourrez tres bien disposer d'une base de donnée de parties preenregistrées.

voila n'oublié pas c'est pour le fun qu'on fait se tournoi. Ca permettra surtout de voir quel algo est le plus efficace :
-le minimax implementé par moi meme (je crois aussi que pollux a choisi cette voie) qui consiste à reflechir plusieur coup en avance,
-reseaux de neurones formels implememnté par ethaniel capable d'apprendre sur ses defaites.
-bases de donnees permettant d'assurer un bon commencement de partie (à ce propos la si il y en a qui ne sont pas convaincu je tiens à leur dire que dans puissance 4 les 10 premiere pieces determine le plus souvent la configuration de la partie et donc du gagnant, je parle en tant accros à puissance 4) et meme si le pari est assez risqué, envisager seulement les cases centrales pourra se revellé efficace contre des ia qui on été programmer pour joueur le meilleur coup et non des coups tordus).bref pour ceux qui n'y connaissent rien au minimax ou au reseaux de neurones formels programmer une petite ia avec une base de donnee permetra de faire une bonne ia meme si c'est de la cuisine c'est plutot efficace.

Merci à squalil² d'avoir repondu j'espere que pollux et ethaniel suivront.

Sinon pour avoir des conseils poour le principe du minimax pour faire une fonction d'evaluation, elaguer l'arbre, detecte la victoire ...
laisser un post

détecter la victoire ok mais je n'ai aucune notion des théories dont on a parlé avant. Je vais faire un sale algo, tout ce qu'on va lui demande c'est de marcher!

lol
c'est deja pas mal de detecter la victoire je connais au moins 5 facons de la detecter dont certaine plus elegante ke d'autres.
si j'ai une suggestion à te fair c'est que sur un tablo 7*6 il y a 69 possibilté de gagner.
Finallement une liste de 69 elements representant chacun un alignememnt de 4 cases s revele vraiment pratik pour connaitre l'etat du jeu
j'en dis pas plus mais grace a cela mo ia en basic en + sur casio (c te dire) metait 2 sec à reperer la victoire.
voila voila

tinkiet va repérer des pions c simplex, c pas ca qui me fait peur

ben pour le minimax c'est pas tres compliké si ca t'interresse je pe te filer des conseils
surtout que comprendre comment ca marche mem si tu n'arrive pas à l'implementer te servira enormement
Parce qu'on s'en sert pour la plupart des jeux de reflexions
meme si c vrai ke pour la premiere fois il est preferable d'étudier le morpion en exemple
ps tu l'as pe etre recu en mini message mais j'en étais pas sur alors le voila ou le revoila.