[Lyon-hackerspace] Un petit projet de plus

Yves Quemener quemener.yves at free.fr
Mar 9 Oct 11:34:46 CEST 2012


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.

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


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