【Javaで】人工痴脳作成委員会【遊ぼう】

ちょっと人間っぽい（だけどお馬鹿な）プログラムの開発を通じて、
Java のプログラミングや非数値処理やシステム設計、
制御工学やゲーム理論やミクロ経済学や人工知能について
面白半分に考えてみよう（あるいは勉強しよう）というスレです。
まず、元になるプログラムを提示し、寄ってたかって
コードを改修したり仕様を変更したり機能を追加したりして、
何が起きるか見てみようという形で話を進めたいと思います。
なお、単純にシステム開発に興味がある人の飛び入りも歓迎します。

最初のお題は「アクセルロッドの『囚人のジレンマ』ゲーム」です。
オリジナルの点数表は
　協調同士 3点
　裏切り同士 1 点
　協調/裏切り 5/0 点。
ですが、このスレでは
　協調同士 2.0 点
　裏切り同士 0.0 点
　協調/裏切り 4.0/-1.0 点。
とします。
一回のセッションは 200 回の取引からなり、
各プレイヤーは、プレイヤー全員のコピーからなる仮想チームの
自分のコピーを含めた全員と一回づつセッションを行ないます。

戦術部分はこんな感じで書きます。
public class 竹箆返し extends Strategy implements Hands {
　　boolean 最初;
　　int 相手の手;
　　String name() {
　　　　return "竹箆返し";
　　}
　　void reset() {
　　　　最初 = true;
　　}
　　int nextHand() {
　　　　if (最初) {
　　　　　　最初 = false;
　　　　　　return 協調;
　　　　}
　　　　return 相手の手;
　　}
　　void study( int hand ) {
　　　　相手の手 = hand;
　　}
}

Strategy.java と Hands.java の中身はこうなってます。
public abstract class Strategy {
　　abstract String name();
　　abstract void reset();
　　abstract int nextHand();　　　　　// 協調 or 裏切り
　　abstract void study( int hand );　// 協調 or 裏切り
}

public interface Hands {
　　public static final int 協調　 = 0;
　　public static final int 裏切り = 1;
}

現在の戦績はこんな感じです。最強と云われた
「竹箆（しっぺ）返し」戦術が、意外に振るいません。

デューク東郷（ゴルゴ１３）: 平均 388.9 点
人間不信裏切り君（裏切者）: 平均 332.6 点
ヒッキー君（引きこもり）: 平均 303 点
竹箆返し様（竹箆返し）: 平均 262.6 点
ひねくれ天邪鬼君（天邪鬼）: 平均 179.1 点
イワンの馬鹿（正直者）: 平均 130 点
でたらめ君（ランダム）: 平均 98.9 点

※トーナメント参加者募集中です。参加希望者はプレイヤー名と
戦術名、および戦術部分のソースをうpしてください。
（その他のソースはおいおい晒します。）

各プレイヤーの概略(Players.java)です。
import java.util.ArrayList;
public class Players {
　　static ArrayList getPlayers() {
　　　　ArrayList players = new ArrayList();
　　　　// ランダム：五回に一回の割合で「裏切り」。
　　　　players.add(new Player("でたらめ君", new ランダム()));
　　　　// 正直者：常に「協調」。
　　　　players.add(new Player("イワンの馬鹿", new 正直者()));
　　　　// 裏切者：常に「裏切り」。
　　　　players.add(new Player("人間不信裏切り君", new 裏切者()));
　　　　// 竹箆返し：最初は「協調」、あとは相手の前回の手をそのまま返す。
　　　　players.add(new Player("竹箆返し様", new 竹箆返し()));
　　　　// ゴルゴ１３：最初は「協調」、裏切られたら以後すべて「裏切り」。
　　　　players.add(new Player("デューク東郷", new ゴルゴ１３()));
　　　　/* 引きこもり：最初は「裏切り」、十回裏切ったら一回「協調」。
　　　　　 自分が協調したとき相手も「協調」なら、次は「協調」。 */
　　　　players.add(new Player("ヒッキー君", new 引きこもり()));
　　　　/* 天邪鬼：最初は「協調」、あとは相手の前回の手が「協調」なら「裏切り」、
　　　　　 「裏切り」なら「協調」。 */
　　　　players.add(new Player("ひねくれ天邪鬼君", new 天邪鬼()));
　　　　return players;
　　}
}

しかし、「戦術」なんだからStrategy じゃなくて Tactics だよなぁ(-_-;)

>>7
とはいえデザパタ的にはStrategyパターン。

「戦略」と称すれば、OKでは？

日本語クラス名とかみただけで何か怖いな
ちゃんと呼び出せてます？

最適な戦術の選択は、点数表の配分に依存するんでしょうね。
与えられた点数表に対して最適な戦術を特定するアルゴリズムはあるのかなあ。

>>１さんのこの企画、おもしろいです。

またM.B.のスレか。

おまいは何で、面白いネタ振れて最初の誘導も上手いのに飽きっぽいんだ？

加点方式の囚人のジレンマだと混乱する。
点数表はこれであってるの？俺証言・相手沈黙が一番高得点じゃなかった？

なんだ減点方式でいいんじゃん

>>5　紛らわしいランキングにすんな

裏切り/協調＞協調/協調＞裏切り/裏切り＞協調/裏切りの筈・・・
協調/協調と裏切り/裏切りって配点逆じゃないの？

> 日本語クラス名とかみただけで何か怖いな
> ちゃんと呼び出せてます？
漏れもヤバそうな気がしてたんで避けてたんだが、
一応Windows（Shift-JIS）では動いてる。Mac（同じくShift-JIS）や
UNIX（EUC）ではどうなるか保証の限りではないが。

>>13 >>14 >>15
済まぬm(_ _)m。三年くらい前に立ってた
『【開催】囚人のジレンマ大会』っつースレがあって、
その＞＞１にあった
> C言語で「囚人」は関数として作ってください。
> 1000回取引をし、その合計点数が高い囚人が勝ちとなります。
>
> 点数表は以下の通りです。
>
> 協調同士 3点
> 裏切り同士 1 点
> 協調裏切り 5/0点。
>
> 最低得点は1000点。最高得点は5000点になります。
>
> 関数は戻り値で 0:協調 か 1:裏切り を返します。
つーのをうっかりそのままパクったのだ
（プレイヤーの名前と戦術名もそこからのパクり）。
元が“囚人”のジレンマだから、「点数」にあたる刑期が
長いほうがペケだし、本当はマイナスの値が出てくるのも
おかしいのである。

>>11
> 与えられた点数表に対して最適な戦術を特定する
> アルゴリズムはあるのかなあ。
点数表より、トーナメントに参加するプレイヤーの
「性格（＝戦略）」に依存する部分が大きいらしい。
今回は、通常の商取引みたいなものを考えているので、
こんなエキセントリックな顔ぶればっかり集まってると、
現実性に欠ける気がするので、点数表も含めて
リアリティのある設定がどんなもんで、その結果が
どうなるかを見てみたいと思うのである。

public class 記録魔一手読み extends Strategy implements Hands {
　　ArrayList<Integer> 相手のリスト = new ArrayList<Integer>();
　　ArrayList<Integer> 自分のリスト = new ArrayList<Integer>();
　　String name() {
　　　　return "記録魔一手読み";
　　}
　　void reset() {
　　　　相手のリスト.removeAll();
　　　　自分のリスト.removeAll();
　　}
　　int researchNext(){
　　　　int size = 自分のリスト.size()-1;
　　　　int o_o = 0;
　　　　int o_x = 0;
　　　　int x_o = 0;
　　　　int x_x = 0;
　　　　for(int i=0; i<size; i++){
　　　　　　int 自分の手 = Integer.parseInt(自分のリスト.get(i));
　　　　　　int 相手の手 = Integer.parseInt(相手のリスト.get(i+1));
　　　　　　if(自分の手 == 協調){
　　　　　　　　if(相手の手 == 協調) o_o++;
　　　　　　　　else o_x++;
　　　　　　}
　　　　　　else if(相手の手 == 協調) x_o++;
　　　　　　else x_x++;
　　　　}
　　　　if(o_o + x_o==size || o_x + x_x==size) return 裏切り;
　　　　if(o_o + x_x==size) return 協調;
　　　　if(o_x + x_o==size) return 裏切り;

　　　　double 協調の期待値;
　　　　double 裏切りの期待値;
　　　　if(Integer.parseInt(自分のリスト.get(size))==協調){
　　　　　　協調の期待値 = o_o/(o_o+o_x)*2.0 + o_x/(o_o+o_x)*-1.0;
　　　　　　裏切りの期待値 = o_o/(o_o+o_x)*4.0;
　　　　}
　　　　else{
　　　　　　協調の期待値 = x_o/(x_o+x_x)*2.0 + x_x/(x_o+x_x)*-1.0;
　　　　　　裏切りの期待値 = x_o/(x_o+x_x)*4.0;
　　　　}
　　　　if(協調の期待値 > 裏切りの期待値) return 協調;
　　　　else return 裏切り;
　　}
　　int nextHand(){
　　　　int 自分の手;
　　　　switch(自分のリスト.size()){
　　　　　　case 0:
　　　　　　case 1: 自分の手 = 協調; break;
　　　　　　case 2:
　　　　　　case 3: 自分の手 = 裏切り; break;
　　　　　　case 4:
　　　　　　case 5: 自分の手 = 協調; break;
　　　　　　case 6:
　　　　　　case 7: 自分の手 = 裏切り; break;
　　　　　　default: 自分の手 = researchNext();
　　　　}
　　　　自分のリスト.add(自分の手);
　　　　return 自分の手;
　　}
　　void study(int hand) {
　　　　相手のリスト.add(hand);
　　}}

記録魔一手読み(記録魔)です。
協調 = o
裏切り = x
とりあえずooxxooxxと試した後、全ての手を記録しながら、
自分の手-次の相手の手の記録だけを利用し、1手先の期待値を求めて出していきます。
未コンパイル。

（>>18のつづき）
具体的なイメージとしてはこんな感じ。
「遠隔地にある二つの商店が、お互いの商品を使って
物々交換で交易をする。それぞれの相手の商品は、
自分のところでは三倍の値で売れるものとする
（輸送コストはタダとする）。同時に同額の商品を発送するが、
商品を発送しなければ、そのぶん利益はプラスになる。」
……ただ、こういうシチュエーションが現実的なケースというと、
「日本のどこぞの非合法組織と、北のほうの某国政府が、
下部組織を通じて外貨（日本円）と薬物を交換するのだが、
取引相手に偽物を摑まされた場合でも、その分は上に
（自腹を切って）納めねばならず、その場合でもその後の取引は
続けなければならない」とかいった例しか思いつかん(-_-!)。
利益率とか流通＆取引のコストとか、取引の停止とかいった
要素を考慮にいれると、アクセルロッドの例とはまた違った
結果になるかもしれないと思うのである。

>>21
> 未コンパイル。
じゃあ、さくさくソースうp。以下はソース一覧。

囚人のジレンマ.java
　　メインルーチン。
SkeltonPlayer.java。
　　プレイヤーの基本メソッドの骨格部分。
Play.java
　　戦術部分を宣言したインターフェース。
AbstractPlayer.java
　　プレイヤーの骨格に、戦術部分をつけ加えた形の抽象クラス。
Hands.java（>>4 に既出）
　　「協調」「裏切り」の宣言。
Players.java（>>6 に既出）
　　各プレイヤーの登録部分。
Strategy.java（>>4 に既出）
　　戦術部分を受け持つクラスの抽象クラス。

import java.util.*;
import java.text.DecimalFormat;
public class 囚人のジレンマ implements Hands {
　　public static void main( String [] args ) throws Exception {
　　 // 初期化
　　　　ArrayList players = Players.getPlayers();
　　　　ArrayList players_y = Players.getPlayers();
　　 // 取引
　　　　ListIterator liter = players.listIterator();
　　　　while (liter.hasNext()) {
　　　　　　Player player = (Player)liter.next();
　　　　　　System.out.println("【" + player.toString() + "】" );
　　　　　　ListIterator liter_y = players_y.listIterator();
　　　　　　while (liter_y.hasNext()) {
　　　　　　　　取引(player, (Player)liter_y.next());
　　　　　　}
　　　　}

（つづき）
　　 // 取引の結果
　　　　System.out.println("++++++++++++++++++++++++++++++++++++++++++++++++");
　　　　DecimalFormat form = new DecimalFormat("##0.#");
　　　　liter = players.listIterator();
　　　　while (liter.hasNext()) {
　　　　　　Player player = (Player)liter.next();
　　　　　　System.out.println(player.toString() + ": 平均 " + form.format(player.総得点() / players_y.size()) + " 点" );
　　　　}
　　}

（つづき2）
　　static void 取引( Player x, Player y ) {
　　　　double point_x = 0.0;
　　　　double point_y = 0.0;
　　　　x.open();
　　　　y.open();
　　　　for (int cnt = 0;cnt < 200;cnt += 1) {
　　　　　　int x_の出方 = x.action();
　　　　　　int y_の出方 = y.action();
/*
　　　　　　if (x_の出方 == 協調) {
　　　　　　　　System.out.print("x:協調／");
　　　　　　} else {
　　　　　　　　System.out.print("x:裏切り／");
　　　　　　}
　　　　　　if (y_の出方 == 協調) {
　　　　　　　　System.out.println("y:協調");
　　　　　　} else {
　　　　　　　　System.out.println("y:裏切り");
　　　　　　}
*/

（つづき3）
　　　　　　 // 協調同士　　2.0 点 : 2.0 点
　　　　　　if ((x_の出方 == 協調) && (y_の出方 == 協調)) {
　　　　　　　　point_x += 2.0;
　　　　　　　　point_y += 2.0;
　　　　　　　　x.result(y_の出方, 2.0);
　　　　　　　　y.result(x_の出方, 2.0);
　　　　　　}
　　　　　　 // 裏切り同士　0.0 点 : 0.0 点
　　　　　　if ((x_の出方 != 協調) && (y_の出方 != 協調)) {
　　　　　　　　point_x += 0.0;
　　　　　　　　point_y += 0.0;
　　　　　　　　x.result(y_の出方, 0.0);
　　　　　　　　y.result(x_の出方, 0.0);
　　　　　　}
　　　　　　 // 協調/裏切り 4.0 点 : -1.0 点。
　　　　　　if ((x_の出方 != 協調) && (y_の出方 == 協調)) {
　　　　　　　　point_x +=　4.0;
　　　　　　　　point_y += -1.0;
　　　　　　　　x.result(y_の出方,　4.0);
　　　　　　　　y.result(x_の出方, -1.0);
　　　　　　}
　　　　　　if ((x_の出方 == 協調) && (y_の出方 != 協調)) {
　　　　　　　　point_x += -1.0;
　　　　　　　　point_y +=　4.0;
　　　　　　　　x.result(y_の出方, -1.0);
　　　　　　　　y.result(x_の出方,　4.0);
　　　　　　}
　　　　}
　　　　x.close();
　　　　y.close();

（つづき4）
　　　　DecimalFormat form = new DecimalFormat("##0.#");
　　　　System.out.println(
　　　　　　　　"　　対 " + y.toString() + " : " +
　　　　　　　　form.format(point_x) + " / " + form.format(point_y));
　　}
}

#SkeltonPlayer.java
import java.util.*;
/* プレイヤーの骨格 */
public class SkeltonPlayer {
　　String name;
　　Strategy strategy;
　　double 総得点;
　　boolean open;
　　SkeltonPlayer() {
　　　　this.name = "名無しさん";
　　　　this.総得点 = 0.0;
　　　　this.open = false;
　　}
　　SkeltonPlayer( String name ) {
　　　　this.name = name;
　　　　this.総得点 = 0.0;
　　　　this.open = false;
　　}

（つづき）
　　void names( String name ) {
　　　　this.name = name;
　　}
　　public String toString() {
　　　　return this.name + "（" + this.strategy.name() + "）";
　　}
　　String name() {
　　　　return this.name;
　　}
　　public String strategyName() {
　　　　return this.strategy.name();
　　}
　　void open() {
　　　　this.strategy.reset();
　　　　this.open = true;
　　}
　　void close() {
　　　　this.open = false;
　　}
　　double 総得点() {
　　　　return this.総得点;
　　}
}

#Play.java
public interface Play {
　　public abstract String strategyName();
　　public abstract int action();　// 協調 or 裏切り
　　public abstract void result( int hand, double point );
}

#AbstractPlayer.java
public abstract class AbstractPlayer
　　　　 extends SkeltonPlayer implements Play {
}

すまぬ。一個忘れてた。以上、全角スペースを半角スペース二個に
置換してから「囚人のジレンマ.java」をコンパイル。
#Player.java
public class Player extends AbstractPlayer implements Play {
　　public Player() {
　　　　this.strategy = new ランダム();
　　　　this.names("デフォルトの名無しさん");
　　}
　　public Player(String name, Strategy strategy) {
　　　　this.strategy = strategy;
　　　　this.names(name);
　　}
　　public int action() {
　　　　return this.strategy.nextHand();
　　}
　　public void result( int hand, double point ) {
　　　　this.総得点 += point;
　　　　this.strategy.study(hand);
　　}
}

>>19
> int 自分の手 = Integer.parseInt(自分のリスト.get(i));
> int 相手の手 = Integer.parseInt(相手のリスト.get(i+1));
じゃなくて、
> int 自分の手 = Integer.intValue(自分のリスト.get(i));
> int 相手の手 = Integer.intValue(相手のリスト.get(i+1));
な。(^_^)b

>>34
そうでした..orz
全部消しちゃってください..
あとremoveAllも変更お願いします..

対戦結果：
デューク東郷（ゴルゴ１３）: 平均 337.6 点
記録魔一手読み（記録魔）: 平均 334.9 点
人間不信裏切り君（裏切者）: 平均 293 点
竹箆返し様（竹箆返し）: 平均 280.6 点
ヒッキー君（引きこもり）: 平均 269 点
ひねくれ天邪鬼君（天邪鬼）: 平均 137.9 点
でたらめ君（ランダム）: 平均 75.9 点
イワンの馬鹿（正直者）: 平均 91 点

記録魔一手読み君、「イワンの馬鹿」からの搾取に成功するも、
性格の悪さが災いして、「デューク東郷」との協調に失敗、
さらに自分自身との潰し合いを演じて、「デューク東郷」に
一歩及ばず。
C 版Downing からの移植とみたが如何？

相手が裏切るまでは協調が必要なのかな
自分も識別しなければ…
コードはさっき書いたばかりですだ

>>37
他のプレイヤーの性格が悪すぎるのも災いしているような気がする。
でたらめ君の挙動によってはデューク東郷との順位が入れ替わる場合も
あるようだし。
てなワケで修正版をうpしますだ。

import java.util.*;
public class 記録魔 extends Strategy implements Hands {
　　ArrayList 相手のリスト;
　　ArrayList 自分のリスト;
　　String name() {
　　　　return "記録魔";
　　}
　　void reset() {
　　　　相手のリスト = new ArrayList();
　　　　自分のリスト = new ArrayList();
　　}
　　int nextHand(){
　　　　int 自分の手;
　　　　switch(自分のリスト.size()) {
　　　　case 0: case 1:
　　　　　　自分の手 = 協調;
　　　　　　break;
　　　　case 2: case 3:
　　　　　　自分の手 = 裏切り;
　　　　　　break;
　　　　case 4: case 5:
　　　　　　自分の手 = 協調;
　　　　　　break;
　　　　case 6: case 7:
　　　　　　自分の手 = 裏切り;
　　　　　　break;
　　　　default:
　　　　　　自分の手 = researchNext();
　　　　}
　　　　自分のリスト.add(new Integer(自分の手));
　　　　return 自分の手;
　　}

　　int researchNext(){
　　　　int size = 自分のリスト.size() - 1;
　　　　int o_o = 0;
　　　　int o_x = 0;
　　　　int x_o = 0;
　　　　int x_x = 0;
　　　　for (int i = 0;i < size; i += 1){
　　　　　　int 自分の手 = ((Integer)自分のリスト.get(i)).intValue();
　　　　　　int 相手の手 = ((Integer)相手のリスト.get(i+1)).intValue();
　　　　　　if (自分の手 == 協調){
　　　　　　　　if (相手の手 == 協調) {
　　　　　　　　　　o_o += 1;
　　　　　　　　} else {
　　　　　　　　　　o_x += 1;
　　　　　　　　}
　　　　　　} else {
　　　　　　　　if (相手の手 == 協調) {
　　　　　　　　　　x_o += 1;
　　　　　　　　} else {
　　　　　　　　　　x_x += 1;
　　　　　　　　}
　　　　　　}
　　　　}

　　　　if ((o_o + x_o) == size || (o_x + x_x) == size) return 裏切り;
　　　　if ((o_o + x_x) == size) return 協調;
　　　　if ((o_x + x_o) == size) return 裏切り;
　　　　double 協調の期待値;
　　　　double 裏切りの期待値;
　　　　Integer tmp = (Integer)自分のリスト.get(size);
　　　　if (tmp.intValue() == 協調){
　　　　　　協調の期待値　 = o_o/(o_o + o_x) * 2.0 - o_x/(o_o + o_x);
　　　　　　裏切りの期待値 = o_o/(o_o + o_x) * 4.0;
　　　　} else {
　　　　　　協調の期待値　 = x_o/(x_o + x_x) * 2.0 - x_x/(x_o + x_x);
　　　　　　裏切りの期待値 = x_o/(x_o + x_x) * 4.0;
　　　　}
　　　　if (協調の期待値 > 裏切りの期待値) {
　　　　　　return 協調;
　　　　} else {
　　　　　　return 裏切り;
　　　　}
　　}
　　void study(int hand) {
　　　　相手のリスト.add(new Integer(hand));
　　}
}

import java.util.Random;
public class ランダム extends Strategy implements Hands {
　　String name() {
　　　　return "ランダム";
　　}
　　void reset() {
　　}
　　int nextHand() {
　　　　if ( Math.random() < 0.8 ) {
　　　　　　return 協調;
　　　　}
　　　　return 裏切り;
　　}
　　void study( int hand ) {
　　}
}

>>37
うーむ、記録魔一手読み君は協調性に欠けていて、
実社会では通用せんようですな。
「でたらめ君」「イワンの馬鹿」「ヒッキー君」
「ひねくれ天邪鬼君」といった、社会性に欠ける
プレイヤーを除くと、

> 竹箆返し様（竹箆返し）: 平均 298.2 点
> デューク東郷（ゴルゴ１３）: 平均 202.5 点
> 記録魔一手読み君（記録魔）: 平均 101 点
> 人間不信裏切り君（裏切者）: 平均 6 点

といったことになってしまいます。

その他のプレイヤーも晒しておきます。
#正直者.java
public class 正直者 extends Strategy implements Hands {
　　String name() {
　　　　return "正直者";
　　}
　　void reset() {
　　}
　　int nextHand() {
　　　　return 協調;
　　}
　　void study( int hand ) {
　　}
}

#引きこもり
public class 引きこもり extends Strategy implements Hands {
　　boolean 最初;
　　int 相手の手, 自分の手;
　　int cnt;
　　String name() {
　　　　return "引きこもり";
　　}
　　void reset() {
　　　　最初 = true;
　　　　cnt = 0;
　　}
　　int nextHand() {
　　　　if (最初) {
　　　　　　最初 = false;
　　　　　　自分の手 = 裏切り;
　　　　　　return 自分の手;
　　　　}
　　　　if (cnt >= 10) { /* 10回に1度協調する */
　　　　　　cnt = 0;
　　　　　　return 協調;
　　　　}

　　　　if ((相手の手 == 協調) && (自分の手 == 協調)) {
　　　　　　/* 前回協調したとき相手も協調だったら協調 */
　　　　　　自分の手 = 協調;
　　　　　　return 自分の手;
　　　　} else {
　　　　　　cnt += 1;
　　　　　　自分の手 = 裏切り;
　　　　　　return 自分の手;
　　　　}
　　}
　　void study( int hand ) {
　　　　相手の手 = hand;
　　}
}

>>22

モデルの詳細は異なっていても、大局的な性質は同一なモデル群は存在する、という
考えを数理モデルを扱う人たちはユニヴァーサリティクラスが同じ、と表現するそうですね。
とりあえず、シンプルなモデルで知見を深めるという１さんの方向性は正しいのでは、
と素人には感じられます。見てて、おもしろいスレです。

クラス名が日本語で書かれてるのでスレをぱっと見、コメントなしで戦略の意図が伝わりやすくて
いいです。実装をJavaでされてますが、日本語インタプリタの「なでしこ」でされたら
さらに読みやすくて楽しそうにおもいました。

比較するっていう観点から見ると記録魔の特定のプレーヤー狙いは止めた方がよかったかも。
それから調査期間を設けるともっと複雑なパターンが考えられるかも。

・協調的戦略は仲間が多いほど有利 (裏切り的戦略は仲間が少ないほど有利)
・パターンが存在する場合最適な戦略が存在する。ただし、それは知り得ない。

相手が裏切るまで協調か自分から裏切るか
裏切られた後裏切るか
裏切られた後協調するか

わからない・・・

裏切り同士・協調同士は点数逆だろ？
裏切り続けたら刑期0以下ってなんじゃそりゃ

>>50
設定が違うのじゃ。>>17 見てくれ。

加点方式にしたって協調にまったくデメリットがないだろ・・・
是正しないでそのまま使うのはどうかと思うが。
少なくともこれは囚人のジレンマに陥ることはない。

>>49
こちらから裏切る戦術には、
・「正直者」「でたらめ君」のような、こちらの手を
見ていない（しかも「裏切者」と違って協調的な）ような
カモがいないと得点が伸びない。
・「ゴルゴ１３」のような報復的な相手と協調できない。
という２つの欠点がある。
「相手が裏切らなければこちらも裏切らない」というロジック
（つまり、今の「記録魔」とは逆）のロジックを入れても
相変わらず強いので、「記録魔」の基本的な発想は
悪くないと思われ。

>>52
> 少なくともこれは囚人のジレンマに陥ることはない。
・減点方式を加点方式にして、点数が高いほうを良とする
・得点表の（どちらかのプレイヤーの）点数を一定点下げる。
・得点表の（どちらかのプレイヤーの）点数を定数倍する。
といったことをしても、ゲームの構造はまったく変わらない。
このゲームは、数学的にいうと、アクセルロッドのゲームと
等価なのである。

協調/ANYの手に適う裏切り/ANYが丸でないように見えるけど？

協調的確率論者、連勝中。参加者求む。

誠実記録魔君（協調的確率論者）: 平均 344.1 点
デューク東郷（ゴルゴ１３）: 平均 343.7 点
記録魔一手読み君（確率論者）: 平均 297 点
竹箆返し様（竹箆返し）: 平均 293 点
人間不信裏切り君（裏切者）: 平均 255.6 点
ヒッキー君（引きこもり）: 平均 237.4 点
イワンの馬鹿（正直者）: 平均 129.7 点
ひねくれ天邪鬼君（天邪鬼）: 平均 99.1 点
でたらめ君（ランダム）: 平均 54.6 点

>>2のオリジナル配点で>>5の結果は変じゃないの？
イワンの馬鹿の平均130って、配点表的にありえない・・・
なんで600〜1000の間で推移してないの？

元スレでぐぐると>>2の配点表が出てくるけど
直後のサンプルソースは正しく裏切り/協調で5/0になってる。

>>55
> 協調/ANYの手に適う裏切り/ANYが丸でないように見えるけど？
「『すべて協調』に敵う『すべて裏切り』が一例もない」ってこと？
そんなことはないんだが。↓
【イワンの馬鹿（正直者）】
対 でたらめ君（ランダム） : 298 / 468
対 イワンの馬鹿（正直者） : 400 / 400
対 人間不信裏切り君（裏切者） : -200 / 800
対 竹箆返し様（竹箆返し） : 400 / 400
対 デューク東郷（ゴルゴ１３） : 400 / 400
対 ヒッキー君（引きこもり） : -146 / 764
対 ひねくれ天邪鬼君（天邪鬼） : -197 / 798
対 記録魔一手読み君（確率論者） : -188 / 792
対 誠実記録魔君（協調的確率論者） : 400 / 400
【人間不信裏切り君（裏切者）】
対 でたらめ君（ランダム） : 596 / -149
対 イワンの馬鹿（正直者） : 800 / -200
対 人間不信裏切り君（裏切者） : 0 / 0
対 竹箆返し様（竹箆返し） : 4 / -1
対 デューク東郷（ゴルゴ１３） : 4 / -1
対 ヒッキー君（引きこもり） : 72 / -18
対 ひねくれ天邪鬼君（天邪鬼） : 800 / -200
対 記録魔一手読み君（確率論者） : 16 / -4
対 誠実記録魔君（協調的確率論者） : 8 / -2

点数表は以下の通りです。
協調同士 3点
裏切り同士 1 点
協調裏切り 5/0点。

//↑と↓で配点違ってるだろ？↓が正しい「囚人のジレンマ」

if ( ( a == 0 ) && ( b ==0 ) ) { pa+=3;pb+=3; } /* 協調：協調 */
if ( ( a == 1 ) && ( b ==0 ) ) { pa+=5;pb+=0; } /* 裏切り：協調 */
if ( ( a == 0 ) && ( b ==1 ) ) { pa+=0;pb+=5; } /* 協調：裏切り */
if ( ( a == 1 ) && ( b ==1 ) ) { pa+=1;pb+=1; } /* 裏切り：裏切り */

【ルール再掲】
１）オリジナルの『囚人のジレンマ』と違い、
加点方式です（ただ、各プレイヤーは、必ずしも
「点数に対して功利的に」振舞うわけではありません）。
２）点数表（交渉マトリックス）
　協調/協調 2.0 / 2.0 点
　裏切り/裏切り 0.0 / 0.0 点
　協調/裏切り -1.0 / 4.0 点
３）一回のセッションは 200 回の取引からなり、
各プレイヤーは、プレイヤー全員のコピーからなる
仮想チームの、「自分のコピーを含めた全員」と
一回づつセッションを行ないます。

OK、やっと伝わった

補足）
・オリジナルの『囚人のジレンマ』ゲームは、
一度きりの交渉が前提です。この場合、双方が
「裏切り」を選択してドツボに嵌る、という結果に
終わるのが普通です。
・トーナメント形式で行なわれる「『囚人のジレンマ』ゲーム」は、
前項の「一回こっきり」のゲームを「繰り返し型」に拡張した
ものですが、五年もぶち込まれた香具師が、刑期を終えて出てきてから
自分を裏切った香具師とまた交渉しなければならないというのは
不自然ですし、「合計が少ないほうがよい」というのも妙なので、
ゲームの数学的構造をそのままにして、より不自然でない形で
ルール化しました。

resetは競技後？それとも前？

>>63
競技前に、Player に対するopen()の中で行なわれます。
でないと相手が変わったときに行なわれる処理を、
コンストラクタの中にも書かなきゃいけなくなるので。

ソースはこのスレじゃなくてどこかにうｐしる

どうせJavaでやるなら動的に参加できるようにしたら？

//res66は参加表明時のレス番。
package entry.res66;
public class MyStrategy extends Strategy implements Hand {}

んでXMLに<p vender="res66" strategy="MyStrategy">を追加していく

>>65
おりゃさ。
ttp://homepage.mac.com/jane_doe/prisoner/index.html

今後の改造予定
・前のセッションで得た情報を利用するタイプのプレイヤーも
いるかもしれないので、順番をシャッフルして何度かプレイを
行なってから、本番を行なう。
・200回固定になっているが、その情報を利用するプレイヤーも
いるだろうから（最後っ屁戦術とか）、それに対する対抗策として、
平均百回・二百回・五百回・千回のポアソン分布とかいった回数で
プレイを行なって比較する。
・プレイの履歴管理などを含め、設計を見直す。

>>66みたくTerrarium風に遊べるようになったら参加する。
あと>>67のは開発用のjarにまとめて配布して欲しい。

同じプレーヤーに対する複数回の試行が認められるなら
ランダムに1.0〜0.0の割合で協調を行うテストを出来るだけ細かく繰り返して
最適だった割合でランダムに手を決めれば一番強くなりそう

相手の手を見ないプレーヤーのパターン識別は
変わらないものと繰り返し程度なら識別できるかもしれないけど
素数番目だけ協調とか2^n番目だけ協調とか言われるとデータベースを持つか確率的な戦略を取るしかないか

相手の手を見るプレーヤーに対しても同じか
複雑なパターンだと識別できても確率的な戦略とほとんど変わらなそうだな

問題は、「裏切り」をかますと相手に報復される
おそれがあるということだ。
むしろ、「他のプレイヤーとのやりとりを見て
相手の行動パターンを分析する」というのを
許すのが面白そうに思うが、その場合相手も
こっちの行動パターンを見ているということでもある。
この関係が非対称（相手はこっちを知っているが、
こっちは相手を知らないとか）の場合まで含めて
シミュレートすると、かなり複雑な社会モデルが
組めそうに思う。

このスレまだあったのか

忙しそうだな

最初は「協調」、
協調成功回数が裏切られ回数以上なら「協調」、
でなければ「裏切り」というDOWNING。
「竹箆返し」より強いという下馬評ながら、
でたらめ君に翻弄され、期待値を計算した
記録魔一手読み君にカモられて低迷。
以下は戦績。

デューク東郷（ゴルゴ１３）: 平均 353.5 点
誠実記録魔君（協調的確率論者）: 平均 347.1 点
竹箆返し様（竹箆返し）: 平均 304.4 点
記録魔一手読み君（確率論者）: 平均 268.1 点
DOWNING（DOWNING）: 平均 262.1 点
人間不信裏切り君（裏切者）: 平均 233.2 点
ヒッキー君（引きこもり）: 平均 210.5 点
イワンの馬鹿（正直者）: 平均 154.6 点
ひねくれ天邪鬼君（天邪鬼）: 平均 123 点
でたらめ君（ランダム）: 平均 95.4 点

協調的確率論者が鬼強いので、
若干の手直しをします。
Hands.java を
public interface Hands {
　　public static final int 協調　 = 0;
　　public static final int 裏切り = 1;
　　public static final double 交換比 = 3.0;
}
に変更。確率論者の期待値を交換非から計算するように改修。
※“Hands”じゃなくなっちまったな(-_-;)

ついでながら、交換比を1.25 （利益率20％）に変更したところ、
以下のような結果になりました。

記録魔一手読み君（確率論者）: 平均 123.6 点
人間不信裏切り君（裏切者）: 平均 119 点
ヒッキー君（引きこもり）: 平均 103.7 点
誠実記録魔君（協調的確率論者）: 平均 100.8 点
デューク東郷（ゴルゴ１３）: 平均 100.1 点
竹箆返し様（竹箆返し）: 平均 47.2 点
DOWNING（DOWNING）: 平均 40.3 点
佛の顔も二度まで（寛容）: 平均 31.2 点
ひねくれ天邪鬼君（天邪鬼）: 平均 13.4 点
でたらめ君（ランダム）: 平均 -26 点
イワンの馬鹿（正直者）: 平均 -42.4 点

競争が激しくなって利幅が減ると、
性格の悪い奴が儲けるということか……

破産したでたらめ君とイワンの馬鹿を除いて再プレイ。結果は
デューク東郷（ゴルゴ１３）: 平均 81.7 点
誠実記録魔君（協調的確率論者）: 平均 81.4 点
記録魔一手読み君（確率論者）: 平均 59.8 点
人間不信裏切り君（裏切者）: 平均 57.2 点
竹箆返し様（竹箆返し）: 平均 44.1 点
ヒッキー君（引きこもり）: 平均 44 点
DOWNING（DOWNING）: 平均 41.9 点
佛の顔も二度まで（寛容）: 平均 30.1 点
ひねくれ天邪鬼君（天邪鬼）: 平均 -66 点
さらにひねくれ天邪鬼君を除いて再プレイを行なうと、
竹箆返し様（竹箆返し）: 平均 40.2 点
デューク東郷（ゴルゴ１３）: 平均 36.6 点
誠実記録魔君（協調的確率論者）: 平均 36.3 点
DOWNING（DOWNING）: 平均 35.9 点
佛の顔も二度まで（寛容）: 平均 31.3 点
記録魔一手読み君（確率論者）: 平均 12.9 点
人間不信裏切り君（裏切者）: 平均 8.2 点
ヒッキー君（引きこもり）: 平均 2.8 点
竹箆返しが強いというのはこういうことかと思った瞬間。

どうでもいいが誰か最後の順位計算を
書いてくれないか

>>76
確率論者だけを勝ちにくくするのではなくて、ルールを少々複雑にすればいいのでは
例えば、交渉を複数人で行うとか。勝敗は多数決。ところで今は１対１だよね？

>>80
> 確率論者だけを勝ちにくくするのではなくて、
いや、そういう意図ではなくて、確率論者が無視できないほど
強力なので、「交渉マトリクスを個別に持つ」という形で
実装すると、のちのちの機能拡張に対応するのが
厄介になるという配慮なのである。
現在、「最初」というフラグを個別に持つのを止めて、
「回数」という引数を戦略に渡す（戦略から参照できるように
すると、書き換える奴が出てきそうな気がする）ように、
仕様を変更しようかと思っている。

> ところで今は１対１だよね？
まあ、基本なので。三者モデル（あるいは社会モデル）で
面白そうな数理モデルがあれば、そっち方面に拡張する
方向で考えてはいるのだが、一対一モデルでも
けっこう分かっていない部分があるので。

確率論者はベイズつこてるん？

つこてへんならベイジアンも入れてーな。

リスクマネージするなら確率に走るのは当然だろ
それを制限しようとしてる時点でこの企画は失敗な気がする

>>84
だから「してない」つーとるがね。
交渉マトリックスっつー変数を環境側に持つよう
一元化しただけだっつーに。

>>69
> あと>>67のは開発用のjarにまとめて配布して欲しい。
↓最新版のソース（zip形式で圧縮したものも附属）
ttp://homepage.mac.com/jane_doe/prisoner/index.html
※ファイル名が漢字を含んでいるので、zip の方は
UNIX 環境等ではちゃんと読めるかどうか保証の限りではない。

以前の「囚人のジレンマ」スレだと、各プレイヤーが
自分の状態によって台詞を吐くという機能があって
なかなか面白かった。
現在、仕様と実装方法を検討中。全部プレイヤー同時にON/OFFすると
うざいので、「プレイヤーをPlayer をnew するときに指定して、
指定したプレイヤーの対戦だけモニタモードをONする」とかいった
仕様を考えている。あとは表示のタイミングと形式だな。

>>86
Javaはユニコードだからそんな心配要らんのじゃねーの？

変数ならそうだかクラスはOSのファイル名に依存するんじゃね？

正直者・ランダム・裏切り者は、裏切り確率が
正直者＜ランダム＜裏切り者となっているだけで本質的に同じ。
竹箆返しと寛容と「佛の顔も三度まで」は許容回数だけの差。
１セッションあたりの取引回数やら利益率やらメンバー構成やらに
依存した、適正な値とかってあるんだろうか？

なんにせよ寛容戦術はうまくないみたいだ。

1位：平均 390.4 点：デューク東郷（ゴルゴ１３）
2位：平均 388.6 点：誠実記録魔君（協調的確率論者）
3位：平均 323.7 点：竹箆返し様（竹箆返し）
4位：平均 293 点：DOWNING（DOWNING）
5位：平均 284.1 点：一度は許す（寛容）
6位：平均 276.7 点：佛の顔も二度まで（二回許容）
7位：平均 270.6 点：佛の顔も三度まで（三回許容）
8位：平均 266.7 点：佛の顔も四度まで（四回許容）
9位：平均 253.3 点：ヒッキー君（引きこもり）
10位：平均 235.8 点：記録魔一手読み君（確率論者）
11位：平均 211.2 点：人間不信裏切り君（裏切者）
12位：平均 209.5 点：Aska（ヤマアラシのジレンマ）
13位：平均 197.8 点：イワンの馬鹿（正直者）
14位：平均 189.2 点：ひねくれ天邪鬼君（天邪鬼）
15位：平均 173.9 点：でたらめ君（ランダム）

強豪と云われたJ.Joss のアルゴリズム
（基本は竹箆返し。協調のうち十回に一回は裏切り）、
ゴルゴ１３との協調に失敗、
竹箆返し・確率論者とは叩き合い、
自分自身とは潰し合いで、結果低迷。

1位：平均 348.3 点：誠実記録魔君（協調的確率論者）
2位：平均 347.9 点：デューク東郷（ゴルゴ１３）
3位：平均 283.4 点：竹箆返し様（竹箆返し）
4位：平均 280.2 点：Downing（L.Downing のアルゴリズム）
5位：平均 263.9 点：一度は許す（寛容）
6位：平均 248.1 点：佛の顔も三度まで（三回許容）
7位：平均 232.4 点：記録魔一手読み君（確率論者）
8位：平均 214.4 点：ヒッキー君（引きこもり）
9位：平均 207.4 点：人間不信裏切り君（裏切者）
10位：平均 177.6 点：Aska（ヤマアラシのジレンマ）
11位：平均 173.9 点：Joss（J.Joss のアルゴリズム）
12位：平均 164.7 点：イワンの馬鹿（正直者）
13位：平均 139.6 点：でたらめ君（ランダム）
14位：平均 124.8 点：ひねくれ天邪鬼君（天邪鬼）

アクセルロッドのトーナメント（第一回）では、
「各プレイヤーと、二百回の取引からなるセッションを五回行なう」
となっていましたので、そのように改めました。
なお、各セッションごとに相手側メンバーをシャッフルするように
しました（ソースの修正はまだ行なっていません。あしからず）。
なお、「ランダム」は裏切り率20％になっていましたが、
裏切り率50％のほうが強いので、差し替えました。また、
「ｎ回許容」タイプは、一回と三回を残して、他を削除しました。

※引き続き、参加者募集中。

交渉マトリクスをStrategyに告知するメソッド用意してよ

>>94
Hand.java の中に「交換比」という値が定義してあって、
Storategyの中ではその値から交渉マトリクスを得ることができる。
こっちが協調・相手が協調のときの値は、
　交換比 - 1.0 （これが原価に相当する）
以下、
協調・裏切り
　-1.0 （丸損）
裏切り・協調
　交換比＋1.0（丸儲け）
裏切り・裏切り
　1.0 （儲けなし）
つまり、交換比 3.0 のときに、
　（ 2.0, 2,0） （-1.0, 4.0）
　（-1.0, 4.0）（ 0.0, 0.0）
という交渉マトリクスになる。これに1.0 を加えて
自分と相手の値を入れ換えると、
　（3.0, 3,0）（5.0, 0.0）
　（0.0, 5.0）（1.0, 1.0）
という、おなじみのAxelrod の交渉マトリクスになる。

>>94
zip ファイル更新した。
Prayers.java は不要になったが残っている。無視してくれ。

>>94
>>95 のマトリクスの参照方法は、
確率論者.java または 協調的確率論者.java を
参照のこと。

……やばい。
プレイを行なっては最下位になったプレイヤーを
一人一人除去してゆくと、「全員が毎回協調」に
あっけなく収束してしまう。
なんかの形で問題を拡張しないと、このスレが終わってしまう……

M.B.がひとりで勝手に試技しまくってるなら終わってもいいじゃん
ある程度closedにして俺戦術楽しめる状況を作らなかったのが悪い

>>99
> ある程度closedにして俺戦術楽しめる状況を作らなかったのが悪い

○戦術を変えたメンバーを参加させて結果を見る
　→Strategy.java を実装したクラスを作り、囚人のジレンマ.javaに
名前をつけて登録
○プレイの回数・セッション当たりの取引数を変更する
　→囚人のジレンマ.java の中のtimes と session を変更する
○交渉マトリクスを変える
　→Hands.java の中の交換比を変える。もっと根本的に変えたかったら、
Session.java の中身を書き換える。

……となっていますが何か？

おはようさん

1〜8までの数字を重複しないで
8桁でランダム表示するものが必要なのですが
できればjavaスクリプトでどなたか作ってやっていただけないでしょうか

板違い市ね

>>102
> 1〜8までの数字を重複しないで
> 8桁でランダム表示するものが必要なのですが
ttp://homepage.mac.com/jane_doe/prisoner/index.htmlを見る。
ページの一番下にあるprisoner.zip をダウンロードし、解凍する
（「囚人のジレンマ」というフォルダができる）。
その中の、「囚人のジレンマ.java」というファイルを開く。
57〜71行目にあるshuffle を改造しる。
> できればjavaスクリプトでどなたか作ってやって
> いただけないでしょうか
上記のshuffle のソース持って Web 板へ行け

ついでだ。Javaだが。
import java.util.*;
public class Shuffle {
　　public static void main( String [] args ) throws Exception {
　　　　final int n = 8;
　　　　String xx[] = {
　　　　　　"1", "2", "3", "4", "5", "6", "7", "8"
　　　　};
　　　　for (int cnt = 0;cnt < (n - 1);cnt += 1) {
　　　　　　int pos = cnt + (int)(Math.random() * (n - cnt));
　　　　　　String tmp = xx[cnt];
　　　　　　xx[cnt] = xx[pos];
　　　　　　xx[pos] = tmp;
　　　　}
　　　　StringBuffer buf = new StringBuffer();
　　　　for (int cnt = 0;cnt < n;cnt += 1) {
　　　　　 buf.append(xx[cnt]);
　　　　}
　　　　System.out.println(buf.toString());
　　}
}

>>98
ttp://www.prisoners-dilemma.com/で勝てるコードを作るスレ
にしとけば続く可能性があったのにねぇ〜

ちょっと独りよがりすぎない？

>>106
> ちょっと独りよがりすぎない？
Java なら無料で利用できて、「戦術」の部分だけ
分離して記述できるので、トーナメント向きだと思うが。
C やら C++ やらだと、開発環境を用意するだけでも
けっこう面倒臭い（Mac ユーザとかだと、Java 環境を
構築するのも結構面倒だが）。「言語を問わずに
Web 環境で対戦」とかいったら、今度は条件を整えるのに
苦労するし。

ttp://www.prisoners-dilemma.com/
は、javaでの投稿を受け付けているのだが…。
もしかして、あの程度の英語がわかりませんか？

>>108
俺はそっちに参加する。
俺でもわかるよう詳細を紹介してくれ。
ipdlxパッケージってのを使うらしいが落とせるの？

>>108
左フレームのHow to Enterで表示されるページの中ほどに
download the IPDLX source as zip file
があるから、それで落とせる。
試してないけど、サンプルのstrategyやTournament.javaとか
あるからローカルで遊べるんでないかい？

>>108
ソース見たら、結局やってることはほとんど同じやん
（名前がStrategy.java なのはGoF と同じなんだろうが、
インターフェースではなく抽象クラスで実装してるところまで
同じときたもんだ）。
方向性も違うし、まあ、ええんちゃう？

嗚呼、春だね〜

>>107
知ったかぶりイタい

質問してもいいですか。鶏は卵から産まれますよね。
その卵は鶏が産みますよね。どちらが先なのですか？

>>114
卵です。

>>114
鶏以外のある生き物が生んだ卵から、突然変異で鶏が出てきました。

>>116
それは違う。
鶏以外のある生き物が鶏の卵を産んだんです。

>>113
>>>107
>知ったかぶりイタい
いや、突っ込むなら>>111 だろ。
結城浩さんの『デザインパターン入門』見ただけで
いいかげんに書いてるし。駆動部のソースなんか、
突っ込みどころ満載だぞ。

ちなみにIPDL のStrategy とこっちのStrategy の対応を示しておくと、
以下の通り。
ALLC（"Always Cooperate"）
　→正直者（常に協調）
ALLD（"Always Defect"）
　→裏切者（常に拒否）
GRIM（GRIM Trigger）
　→ゴルゴ１３（一度裏切られたら、常に裏切り）
Historical
　→よくわからん(-_-!)。少なくともこっちに対応する戦術はないらしいので、
　誰か移植してくれ。
MRAND（Multi-choice Random）
　→よくわからん(-_-!)。IPDL では「協調」と「裏切り」の間に中間の値が
　あるモデルになっているらしい。
NEG（Negation）
　→天邪鬼。
Pavlov
　→よくわからん(-_-!)。
RAND（Random）
　→ランダム。
STFT（Suspicious TFT）
　→竹箆返しだが、初期値が「裏切り」。
TFT（Suspicious TFT）
　→竹箆返し。
TFTT（Tit-for-Two-Tats）
　→寛容。

111に突っ込まないと107に突っ込んではいけないというルールはありませんが？

>>120
規約12条9項の4です。
以下発言は慎むように。

>>120
「知ったかぶり」と言うなら、Win で動く、タダで使える
（あるいは一万円未満で買える）マトモなC/C++ の処理系が
あるなら教えてくれ。漏れはVC++を買う金がなくて、
Cygwin をインストールしてGCC で開発しとる。

>>119
よくわからんのがそれなりにあるってことは、
あんたの浅知恵では世界を相手にできないってこった

>>122
まともかどうかはわからないがボーランドが無償でコンパイラを配布してた気はする。

>>124
ボーランドならとりあえず安心という気がする。
チェックしてみる。ありがとうございますだm(_ _)m。

>>125
でもJavaで遊ぶのに賛成。

Strategy の中でメッセージを吐こうとしたが、
うまくいかない。で、じっくり考えてみたら、
Player の中で、Strategy から返ってくる値を見て
メッセージを出すのが正しいような気がしてきた。
……人間っつーのは自分の行動の理由を知らない
（たとえば、意識の上では「欠点がある→嫌い→攻撃」
であっても、無意識のレベルでは「攻撃性→対象→欠点が
目につく」というふうに、因果関係が逆であるとか）
というのが、最近の心理学の常識みたいだし（←「オブザーバー
仮説」とかいうらしいが、ググっても出てこなかった）。
「裏切者」も、「人間不信」ではなく、単純にMin-Max 戦略を
取っている（裏切られたときの被害が少ない）だけかもしれないし。

世界地図探してもボーランドって見つからないんですがどこにありますか？

>>128
こっちで質問してみては？
http://pc8.2ch.net/test/read.cgi/tech/1108989422/

>>127
> ……人間っつーのは自分の行動の理由を知らない

従業員に主体性を持たせるようなセミナーでは、
自分の行動に対し理由付けを求められる。
今の企業人で、そのように行動の理由を知らない奴は
単に無責任な奴。

本題に戻って、メッセージを吐けないのは、
囚人が協調/裏切りしか言えないから。と考えるのが普通じゃね？

>>130
> メッセージを吐けないのは、囚人が協調/裏切りしか
> 言えないから。と考えるのが普通じゃね？
いや、単純に、プレイヤー名を抱えているところの
呼び出し元のPlayer に通知する方法がないのだ(^_^;)

>>130
> 従業員に主体性を持たせるようなセミナーでは、
> 自分の行動に対し理由付けを求められる。
フェスティンガー的防衛機構つーのがあって、
「命令に従っている」と思うと自己愛が傷つくので、
そこに意義を見出して、「自発的にやっている」
と認知してしまったりするのである。
理由づけについては、分割脳に関する実験などを
通じて、いろいろなことが分っている。
詳しくは山岸俊男『社会的ジレンマ』（PHP新書）
４章−２など参照のこと。

>>132 は漏れです。
>>125
よく考えたらTurbo C か。そういや DOS 時代にずいぶん
お世話になったな。

で？そこらへんの心理学がどういう関係あんの？
メンヘルにでも逝ってこい

>>134
> で？そこらへんの心理学がどういう関係あんの？
そうか、わからんか。やっぱりな(w

ポイントを「損失」ではなく「得点」と捉えた時点で、
協調／協調 2.0/2.0
裏切り／裏切り 0.0/0.0
協調／裏切り -1.0/4.0
つー配点自体が嘘臭くなってこないか？
「協調／協調」だと合計点が4.0だが
「協調／裏切り」だと合計点が3.0なんだから、
「協調したほうが期待値が上がってお徳ですよ」
みたいな作為が感じられてしまう。これが
協調／協調 2.0/2.0
裏切り／裏切り [そこでゲームが終わってしまう]
協調／裏切り -1.0/6.0
みたいな形だと、「どうやってサドンデスルールに
引っかからずに交互に裏切るようなプレイに持ち込めるか」
みたいな話になって、けっこう面白そうな気がするが。

>>122
http://msdn.microsoft.com/visualc/vctoolkit2003/

>>137
サンキュ。漏れも『日経ソフトウェア』の四月号を人に
教えてもらって見た。

>>136
IPDLのソースにも、「中断」っていうオプションが予約されてた
（ただし未使用）ので、「ゲームを中断する」というのは
面白いかもしれない。
ついでながら「サドンデスルール」っつーのは結構いいな
（「Ｇ大佐」こと鈴木銀一郎氏を思い出すが）。

仕様とルールが安定したら参加したい。
ソースはクローズドで主体的にトーナメントを楽しめる方がいいんじゃないだろうか。
終わった後で公開して比較するとか。
それから試行は行えるようにした方が面白いと思う。
期日と参加の方法も規定して欲しい。

>>135
おまえもわかんないだろ？
わかるんだったら説明してみ。

>>140
M.B.が主催だからやめとけ。
「オブザーバー仮説」でしか検索できない脳味噌だし。
英語で"observer hypothesis"で検索することもできねぇし。
どっかからぱくった文章を、さも自分が考えたように書くし。

>>140
OK。言語はJava でええか？　「引数とファイルで渡して、
標準入出力で結果をやりとりする」とかいった
インタフェースで多言語混在トーナメントを行なう手も
あるのだが、いささか面倒臭いので。
基本的な形態としては、
・基本的なプレイヤーを含むJava の試行環境を委員会側が提供して、
そこで動作確認をしたコードをメールで委員会宛に送る。
・トーナメント結果をこのスレに発表する。各プレイヤー毎の
対戦成績と、各プレイヤーのStrategy のソースは、現在ソースを
晒しているサイトに貼る。
という形を考えているが、各セッション毎のプレイヤーの挙動
（星取表っつーのかな）を見やすく表示する方法を指定してほしい。
○××○××……とかでいいんならそれでいいんだけどさ。

>>141
> 英語で"observer hypothesis"で検索することもできねぇし。
はっはっはー、案の定引っかかってやんの。
「オブザーバー仮説」ってのは漏れの造語だよ〜ん。

Javaなんていやだ！スクリプト言語でいいじゃん！
Ruby, Python, Tclのどれかがいい！

>>144
選ぶならPython だな（とか言っといてほとんど何も知らない）。
局所変数をちゃんと扱える（つーかカプセル化がちゃんとできる）、
Web 関係で一般的な言語っつーと、Python くらいしか
思いあたらないので（「それは違うぞ」っつーツッコミが入ると
漏れはかなり嬉しい。来い。いや、ぜひ来てくれ）。

>>142
自分はJavaでいい。
試行って言ったのは通常モードと試行モードみたいなものを作って、
逆のモードでセッションを1回ずつ行って、
互いに学習する機会をつくったらどうかということ。
複雑になって面白くないかもしれないが。
○×でもいいし、平均ポイントをグラフにすればそれもいいと思う。色で表してもいいし。
それから、細かく見たい人向けに、
1回ごとの全ての手(と得失)を色分けしたピクセルで表して、
それぞれのプレーヤーの全ての対戦結果を画像にするとかどうだろ。

GUIでやってるわけじゃないんだし
アイデアあるなら自分でアップすりゃいいじゃん

GUIだと何か問題があるのか？

日本語名はどうにかならんかね。Linuxなんで

LinuxってUnicode使えないほどウンコなの？

>>149
IPDLのソースのおかげで英語で何というかだいたい分かったので、
ファイル名（とclass名）に関しては英語名に変更しようと思ふ。
>>150
そうじゃなくて、ファイル名をShift-JIS からEUC に変更せんと
あかんのじゃ。

そうなんか。ごめんよLinus

書き直すなら、フレームワークとインタフェースをパッケージわけして欲しい。
インタフェース（interface や abstract なクラス）を使って作るプレイヤークラスは、
さらにその外で。

っていうか、そんな感じで最初から実装してみたんだけど、どっかにUpできる場所ある？
（それともいらねーか。）

セッションごと、取引ごとに、プレイヤーがコメントを言えるようにもしてみたよ。

153
> っていうか、そんな感じで最初から実装してみたんだけど、
> どっかにUpできる場所ある？
zipしてメールに添付しる。まんまUpしとく。

もうすぐウンマンコが帰ってくる

あぷろだにあげておきます。
http://49uper.com:8080/html/img-s/50143.zip

なんかいいじゃん。

済まぬ。トーナメントは
・>>156を参考にして、ファイル中の文字列からclass ファイルを
取ってくる。
・非対称な交渉（交渉マトリクスが不公平な場合）も扱えるように、
構成を変更する。
・現在Strategy という名前になっている「戦術」部分をTactics と
改名し、戦略にあたる部分（Min-Max とか Max-Max）を別に用意する。
また、サドンデス・ルールや初期設定など、シミュレーション的な
要素を取り入れやすいように配慮する。
とかいった書き換えを行なってから、ソース類をうpしたうえで、
改めて告知する。しばし待て。

とりあえず保守age

1ヶ月経過age

再開の目処がついたのでAge。
JavaBeans は使える。

す

か

あげ。

だれも見てないよ。
誰がただでやるかい！お断わりだ

保守

時給１０００円でＪａｖａ教えてくださるかたを募集します
場所　所沢（池袋・高田馬場から直通）

ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
よろしくおねがいします

保守