[Lyon-hackerspace] Un petit projet de plus

Chomienne Anthony anthony.chomienne at yahoo.fr
Mar 9 Oct 12:18:49 CEST 2012



De : Yves Quemener <quemener.yves at free.fr>
À : lyon-hackerspace at lists.hackerspaces.org 
Envoyé le : Mardi 9 octobre 2012 11h34
Objet : Re: [Lyon-hackerspace] Un petit projet de plus
 
On 09/10/12 19:36, a d wrote:
> Je n'y avais pas pensé. Une machine virtuelle bien isolée pourrait 
> aller. Sinon, s'il n'y a pas trop de participant, on pose notre code et 
> éventuellement un makefile et tu check le code avant de le balancer.

Dans l'idéal, les gens pourraient tester leur code sans avoir un humain
dans la boucle de lag. Ceci dit ça peut être résolu en proposant une arène
que chacun peut faire tourner manuellement chez soi. Hé, c'est peut être
tout simplement ça la solution!

> Si tu as un lien pour expliquer ce jeu, je suis preneur.

http://fr.wikipedia.org/wiki/Dilemme_du_prisonnier

Grosso modo, deux joueurs choisissent secrètement soit une attitude
collaborative, soit une attitude compétitive. Deux collaborants obtiennent
chacun de bons gains, deux compétiteurs obtiennent de faibles gains mais si
un collabore pendant qu'un est en compétition, le collaborant a le gain le
plus faible et le compétiteur le gain le plus fort.

C'est un modèle très simple d'interactions qui se décline en plein de
possibilités.

> Le mieux serait de ne pas contraindre à un langage et effectivement 
> faire une interface. Je sais pas si c'est possible en python mais 
> utiliser une shared memory pourrait être un peu mieux non? pour les 
> dialogues entre IA plutôt que le stdin/stdout? stdin et out serait plus
>  utilisé pour choisir qui on affronte, les stats de chaque IA, le temps
>  de prise de décision (temps moyen d'éxécution du ou des algos de 
> décision),... Le jeu ne doit avoir rien de graphique.

Je ne suis pas sur de voir le problème du stdin/stdout ? Au pire on dit
qu'il faut lancer le bot avec un flag de type --arena pour laisser la
possibilité d'avoir un shell interactif. L'approche stdin/stdout me plait
plus car elle me semble plus abordable pour des programmeurs novices.

Dans mon idée, les stats et les temps de décision seront mesurés par
l'arène, pas par les bots individuellement, même si rien ne les empêche de
le faire.

Rien de graphique, en effet.

Rien de problématique en soit, va pour stdin/stdout.

> Faut que la machine utilisée aie des outils de compilation et les
> machines virtuels des langages interprété: java, ruby, python, autre?

La personne fournissant la machine imposera ses contraintes. En particulier
précisera la version de python, ruby, gcc, cmake, pourquoi pas du mono
(aïe! tapez pas! mais c'est pas si mal le C# !) ou de java (j'imagine que
les implémentations open source seront préférées). Que pourrait-on vouloir
de plus exotique ? Du JS ? du Fortran ? du Camel ? du Forth? Du Pascal ?
Oui, finalement l'approche stdin/stdout semble meilleure qu'imposer du
python bêtement :)

Ceci dit, je me demande si on ne va pas commencer avec une arène que chacun
peut tester chez soi, ça me parait éminemment logique. À chacun de préciser
ses dépendances et de s'arranger pour qu'elles ne soient pas trop chiantes.
On pourrait s'organiser un run "officiel" hebdomadaire ou mensuel sur une
machine préparée pour l'occasion.

Dans l'idéal ce serait plus simple en effet. On est indépendant d'une

Comment vois tu se dérouler le run? Nombre de partie servant à déterminé le gagnant du run entre 2 IA? Quelle résultat doit on attendre d'un run, le maximum de gain? Je sais pas trop comment faire pour dérouler mes tests même sur une arène que je pourrai lancer chez moi, rien ne me prouvera que mon/mes algos sont bon. Bon après j'ai pas trop réfléchie au problème, bien que j'ai 2-3 idées qui me trotte dans la tête.
_______________________________________________
Lyon-hackerspace mailing list
Lyon-hackerspace at lists.hackerspaces.org
http://lists.hackerspaces.org/mailman/listinfo/lyon-hackerspace
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.hackerspaces.org/pipermail/lyon-hackerspace/attachments/20121009/787be314/attachment.html>


Plus d'informations sur la liste de diffusion Lyon-hackerspace