PHPにおけるグラフ描画とアルゴリズム (CodeZine)

グラフの描画にはImage_GraphVizを、アルゴリズムの実行にはStructures_Graphを使います。Image_GraphVizは、Graphvizを使うだけあってかなりのことができますが、Structures_Graphはまだまだ発展途上な感じです

本格的なアルゴリズムが必要な場合はMathematicaが便利です。それで性能が足りないときにはBoost Graph Libraryを使うといいでしょう

Brian Kernighan, Jon Bentleyほか著
オライリージャパン (2008/4/23)

「Beautiful Code」という刺激的なタイトルの本で使われているプログラミング言語の登場回数を数えてみました

• 1位：C言語（14回）
• 2位：Java（6回）
• 3位：C++, Python（3回）
• 5位：Fortran, Perl, Ruby（2回）
• 8位：C#, EmacsLisp, Haskell, JavaScript, Lisp, MATLAB, Scheme, VisualBasic（1回）

ここに挙げた以外にも、いろんな言語が登場しているので、贔屓のものがある人は、索引を見てください。ちなみに、PHPは索引にも載っていません

私の好きな言語でも、シェルスクリプトとMathematica、Prologは登場していませんね（Prologはともかく、Mathematicaはコア部分をオープンソースにするといいと思いますよ）

ちなみに、この本は「美しいコード」というよりは「すばらしいソフトウェア開発」を紹介したものだと思います（美しい「コード」も載っていますが）。広義の「美しいコード」という感じでしょうか

「美しいコード」で私がイメージするのは、『ハッカーのたのしみ』や『Short Coding ~職人達の技法~』です（『ハッカーのたのしみ』の著者ヘンリー・S・ウォーレン, Jr.は本書の第10章に登場しています。10章を楽しんだ人は『ハッカーのたのしみ』もきっと楽しめるでしょう）

第7章「ビューティフル・テスト」を楽しんだ人は、『珠玉のプログラミング』と『The Art of Computer Programming Volume 3 Sorting and Searching』も楽しめるでしょう（紹介するまでもないことですが）

再帰の問題例としての迷路問題。（中略）上記のプログラムを作成してください。（再帰を用いた迷路探索問題）

再帰のない言語やあっても深さの制限が厳しい言語があるので、手法は限定しないほうがいいでしょう（構造体とかリストとかも）。これはDouKaku?のすべてのトピックについて言えることですが、この問題が特に異常なのは、学校の宿題を人にやらせようとしているからでしょうか（参考：C/C++の宿題を片付けます 56代目）

私は宿題はどうでもいいので、なるべく楽な解決を目指します

例えばグラフアルゴリズムを標準サポートしている処理系（含Mathematica）なら、最短経路も特に難しいということはないでしょう（愚直なエージェントを実装したいということがあるかもしれませんが）

必要なパッケージをロードします

<<DiscreteMath`GraphPlot`;
<<DiscreteMath`Combinatorica`;

迷路を定義し、データ構造を整えます

• num: 座標を数字に変換する補助関数
• pos: 数字を座標に変換する補助関数

tmp={
      "******",
      "*8000*",
      "****0*",
      "**000*",
      "*90*0*",
      "******"};
maze=Characters/@tmp;
n=Length@First@maze;
num[i_,j_]:=n (i-1)+j
pos[x_]:={Quotient[x,n,1]+1,Mod[x,n,1]}

与えられたデータをグラフのエッジのリストに変換します

start=num@@First@Position[maze,"8"];
goal=num@@First@Position[maze,"9"];
arcs={};
Do[
    If[maze[[i,j]]!="*",
      If[maze[[i,j+1]]!="*",
        AppendTo[arcs,{num[i,j],num[i,j+1]}]];
      If[maze[[i+1,j]]!="*",
        AppendTo[arcs,{num[i,j],num[i+1,j]}]]],
    {i,1,Length@maze-1},{j,1,n-1}];

エッジのリストからグラフを生成し、最短経路アルゴリズムを適用します

sol=ShortestPath[FromUnorderedPairs@arcs,start,goal];
If[Head@sol===ShortestPath || Length@sol==1,False,
  pos/@sol]

{{2,2},{2,3},{2,4},{2,5},{3,5},{4,5},{4,4},{4,3},{5,3},{5,2}}

おまけ：変換した結果のグラフを描画すると下のようになります

GraphPlot[FromUnorderedPairs@arcs,VertexStyleFunction->>Automatic];

前エントリの続き

マルバツゲームで、賢いプレイヤーの思考ルーチンを実装してください。

賢いといってもいろいろありますが、

1. 負けない
2. できるだけ勝つ

という条件でいってみたいと思います。（マルバツゲーム：賢いプレイヤー）

手を決める関数だけ新たに用意すればいい

盤面と可能な場所のリストを与えると、新しい盤面のリストを作る補助関数を用意する

nextStates[{p1_,p2_},ops_]:=
  Map[If[Length@p1==Length@p2,
      {Append[p1,#],p2}&,{p1,Append[p2,#]}&],ops]

ミニマックス戦略に基づいて手を決める関数を作る。ミニマックス戦略とは、「両者が最善の結果を目指すと仮定した上で、最善の選択肢を選ぶ」というもの。未来のすべての可能性を木で表現したとき、マルの選択肢の評価値はその子ノード（バツの選択肢）の評価値の最大値（マックス）、バツの選択肢の評価値はその子ノード（マルの選択肢）の評価値の最小値（ミニマム）になる（マル勝ちを1、バツ勝ちを-1としていることに注意）。

Remove[minimaxDecision];
minimaxDecision[s_]:=
  Module[{ops=operators@s,vals,isMax=Length@s[[1]]==Length@s[[2]]},
    vals=minimaxValue[#,Not@isMax]&/@nextStates[s,ops];
    minimaxDecision[s]=ops[[Position[vals,If[isMax,Max,Min]@vals][[1,1]]]]]

minimaxValue[state_,isMax_]:=Module[{result=judge@state},
    If[result=!=Null,result,
      If[isMax,Max,Min][
        minimaxValue[#,Not@isMax]&/@nextStates[state,operators@state]]]]

この計算は10試合くらいだと遅いが、繰り返すうちに速くなる（一度計算したら結果をおぼえておくようにしている）。1万試合で1分くらい（Athlon X2 3800+）

マルがミニマックス戦略、バツがランダム・プレーヤーのとき、マルの9954勝0敗46分

Timing[
  result=Table[game[minimaxDecision,randomDecision],{10000}];
  Count[result,#]&/@{1,-1,0}
  ]

{65.656 Second, {9954, 0, 46}}

マルがランダム・プレーヤー、バツがミニマックス戦略のとき、バツの8024勝0敗1976分

Timing[
  result=Table[game[randomDecision,minimaxDecision],{10000}];
  Count[result,#]&/@{1,-1,0}
  ]

{68.484 Second, {0, 8024, 1976}}

マルバツともにミニマックス戦略のときは引き分け

game[minimaxDecision,minimaxDecision]

0

計算量が許すなら、ゲーム・プレーヤーを実装しようとして最初に試すのがミニマックス。詳しく知りたい人は、人工知能のバイブル『エージェントアプローチ人工知能』（原書は改訂されている）や、ハッカーのバイブル『Paradigms of Artificial Intelligence Programming』をどうぞ

さて、ミニマックスは「賢い」だろうか。お題の条件1「負けない」はいいとして、条件2「できるだけ勝つ」はどう考えたらいいのだろう

少なくともここでの実装は、「できるだけ」ということは考えていない。単に「勝ちを目指す」だけ。じゃあ、「できるだけ」というのが可能かというと、これはちょっと難しいんじゃないかと思う。素直に解釈すれば、すべての可能性な戦略が平等に起こると仮定することになるわけだが、これはかなり面倒。盤面で表現したときとプログラムで表現したときでは、戦略の密度分布も違うし

おまけ：勝ちになるケースが最も多い手を選ぶ戦略（相手も同じ戦略と仮定）は、ランダムと戦ったときの成績が、ミニマックスより若干悪い（マルで386分、バツで2012分）

Remove[cleverDecision];
cleverDecision[s_]:=
  Module[{ops=operators@s,vals,isMax=Length@s[[1]]==Length@s[[2]]},
    vals=cleverValue[#,Not@isMax]&/@nextStates[s,ops];
    cleverDecision[s]=ops[[Position[vals,If[isMax,Max,Min]@vals][[1,1]]]]]

cleverValue[state_,isMax_]:=Module[{result=judge@state,vals},
    If[result=!=Null,result,
      vals=minimaxValue[#,Not@isMax]&/@nextStates[state,operators@state];
      If[isMax,
          N@Length@Select[vals,Positive],-N@Length@Select[vals,Negative]]/
        Length@vals]]

「毎ターン乱数を使って手を決めるランダムプレイヤー同士を対戦させる」というのが今回のお題です。１万回対戦させ、勝ち・負け・引き分けの数を表示してください。そして先手が有利であることを確かめてください。（マルバツゲーム）

以下が勝ちのパターンになるようにマス目に番号を振っておく

wins={{1,2,3},{4,5,6},{7,8,9},{1,4,7},{2,5,8},{3,6,9},{1,5,9},{3,5,7}};

マルがある場所（あるいはバツがある場所）をリストで表現すると、次のように勝ちを判定できる

isWinner[player_]:=MemberQ[Length[Intersection[player,#]]&/@wins,3]

ゲームの結果は、マルの勝ちなら1、バツの勝ちなら-1、引き分けなら0とする

judge[{p1_,p2_}]:=
  If[isWinner@p1,1,
    If[isWinner@p2,-1,
      If[Length@p1==5,0,Null]]]

盤面の状態を{マルのリスト, バツのリスト}で表すことにする。状態を与えると、可能な場所のリストを返す関数は以下のとおり

operators[state_]:=Complement[Range@9,Flatten@state]

手を決める関数を2つ（マル用とバツ用）与えると、ゲームが行われる

game[decision1_,decision2_]:=Module[{state={{},{}},result=Null},
    While[result===Null,
      If[Length@state[[1]]==Length@state[[2]],
        AppendTo[state[[1]],decision1[Sort/@state]],
        AppendTo[state[[2]],decision2[Sort/@state]]];
      result=judge@state];
    result]

ランダム・プレーヤーが用いる関数は次のとおり

randomDecision[state_]:=With[{x=operators@state},
    x[[Random[Integer,{1,Length@x}]]]]

対戦させると、マルの5877勝2835敗1288分

Timing[
  result=Table[game[randomDecision,randomDecision],{10000}];
  Count[result,#]&/@{1,-1,0}
  ]

{7.688 Second, {5877, 2835, 1288}}

負けないマルバツに続く

矢吹太朗（著）, 山田祥寛（監修）『マイクロソフト公式解説書　プログラムを作ろう！Microsoft Visual Web Developer 2008 Express Edition入門』（日経BPソフトプレス, 2008）

「プログラミングについて学びたい」とか「プログラマになりたい」とかいう人だけでなく、「この先の人生でプログラムを書くことはたぶんないけど、プログラミングというのがどういうものなのか、素養として知っておきたい」という人にもお勧めです（「素養という割には大変じゃん」という印象を持たれる方もいるかもしれませんが、そもそも、そんなに簡単にわかる世界ではないのです）。

Microsoft Visual Web Developer 2008 Express Edition（以下VWD）を使ってウェブアプリを作る方法を解説しています。VWDはマイクロソフトの開発環境であるVisual Studioからウェブアプリに関する部分だけを抜き出したもので、無料で使うことができます（フリーソフトウェアではありません）。（「ウェブアプリって何？」という方は本書の第1章を立ち読みしてください。）

すぐに買ってもらってもいいのですが、その前に少し調べてみたいという場合には、マイクロソフトのサイトからVWDをダウンロードして、チュートリアル : 新しい ASP.NET Web サイトの作成などを試してみるといいかもしれません（「このウェブアプリを作りたいけどこのチュートリアルは難しい」という方は、本書を読んでください。画面キャプチャなどを使ってもう少し丁寧に解説しています）。

私には、本書（以下、VWD本）の他にもう1冊ウェブアプリに関する著作があります（『初級プログラマのためのWebアプリケーション構築入門』。以下、構築本）。どちらも入門書なのですが、目指すところはかなり違います。

VWD本は、VWDという便利な開発環境を利用して、かなり実用的なウェブアプリでも簡単に作れるようになっています。とりあえずウェブアプリ開発の雰囲気を知りたいという方や、具体的な成果物で達成感を得たいという方に向いています。

開発環境が便利なのは、技術的な詳細の多くがうまく隠されているからです。VWDを使っている限りにおいては、このことは問題ではありませんが、隠された技術的詳細の中には、ウェブ開発における常識（XHTMLやプログラミングの基礎、文字コード等）もあるので、そういうことも押さえたい場合には、VWD本の後に構築本を読まれるといいでしょう。VWD本でウェブアプリのイメージができていれば、構築本は簡単に読めるはずです。つまり、VWD本は構築本の導入として読むことができます。

構築本の後にVWD本を読むと、VWD本はまた違った味わいになるでしょう。構築本では、基本をしっかり固めようとしているため、作るウェブアプリはかなり単純（悪くいえば地味）なものになっています。VWD本では、より発展した技術を使っているため、作るウェブアプリはかなり複雑になっています。それにも拘わらず、作業はとても簡単です。しかも、構築本を読んでいるので、便利さの裏に隠された技術的詳細も理解でき、気持ち悪さが残りません。つまり、VWD本は構築本の発展として読むこともできます。

「初心者にお勧めのプログラミング言語は？」という話がよくありますが、重要なのは言語ではなく技術であり、本書はこの問いへの一つの答えになるかと思います。XHTMLとVisual Basic、SQL、JavaScriptが登場しますが、いずれも重要です（そしていずれも触りだけです。たとえばJavaScriptはうまく隠されているので、その機能をコードを書かずに利用しています）。

• 出版社（日経BP）のサポートページ：サンプルコードはここからダウンロードできます。
• WINGSプロジェクトのサポートページ：FAQと正誤表はここに掲載される予定です。
• Visual Studio 2008 Express 学習情報（マイクロソフト）：第3章「日記帳を作ろう」の前半が公開されています。
• Amazon.co.jp
• bk1

インセスト―アナイス・ニンの愛の日記無削除版 1932–1934
アナイス・ニン (著), 杉崎 和子 (翻訳)
彩流社 (2008/03)

アナイス・ニン(1903/2/21–1977/1/14)の愛の日記（無削除版）第2巻が出た。『小鳥たち』が話題になったり、地味に売れている感のあるアナイスだが、『ヘンリー＆ジューン』以降の日記無削除版がちゃんと翻訳されるとは思っていなかった。けっこううれしいかも。次も翻訳されますように

ニンの弟は、本書を姉の創作であると位置づけ、出版に最後まで強硬に反対したが、インセスト・タブーを乗り越えることにより、人間として、芸術家として成熟していったニンの克明な記録は、文学史上、比類ないものである。（立花隆）

「無削除版」というのは関係者がみんな死ぬまで出版できなかった赤裸々な告白のこと。全4巻

1. Henry and June (1931–1932、28歳くらい)（日本語訳）
2. Incest (1932–1934、29–31歳くらい)（日本語訳）
3. Fire (1934–1937、31–34歳くらい)
4. Nearer the Moon (1937–1939、34–36歳くらい)

ほかに、赤裸々な部分が削除された「アナイス・ニンの日記」（全7巻、1931–1974）と「アナイス・ニンの初期の日記」（全4巻、1914–1931）があり、「アナイス・ニンの日記」第1巻は翻訳がある

一つ残念だったのは、

翻訳の際に、(1)夢の一部、(2)ヘンリー・ミラーが書き込んだ部分、(3)家族やメイドについての日常的な記述、(4)同じような繰り返し、(5)ひと続きのテーマを中断するかたちで、突然割り込んでくる関係のない記述などを割愛した(p.7)

はじめにで書かれているように、編集に正当性はあるのかもしれないが、(2)はちょっと読みたかったなあ。アナイスの原稿にヘンリーが手を入れるシーンは、映画でも印象的だったし

ちなみに『ヘンリー＆ジューン』は、『存在の耐えられない軽さ』を映画化したフィリップ・カウフマンによって、マニアックに映画化されていて、これがかなりおすすめ。勉強になった（詳細は略）

はまった人はアナイス・ニン・コレクションを

1. 私のD.H.ロレンス論
2. 近親相姦の家
3. 人工の冬
4. ガラスの鐘の下で
5. コラージュ
6. 心やさしき男性を讃えて

ヘンリー・ミラー側からの回想も紹介しておくのがフェアってものかもしれない

彼女はたしかに、ぼくのためにさんざん犠牲的につくしてくれた｡ぼくが彼女に負っている借金は、大部分はもう支払われることはない｡しかし、彼女のことをきっぱりと明らかにさせておくれ｡彼女は自分のことを殉教者であると思わせていたけれど、それにしまいには、自分のことを本物の守護天使であると思わせていたけれど、アナイス・ニンは、ぼくの心のなかでは、決して聖者の域に達することはなかったよ。（『回想するヘンリー・ミラー』 p.181）

勘違いも相手にしなきゃいけないんだから裁判所も大変ですな。税金の無駄遣いとまでは言わないけれど

そう、名誉を傷つけられたと勘違いして訴えていた裁判の判決が出た。なんでも、

人間としてそれをつぐなうには、あまりにも巨きい罪の巨塊のまえで、かれはなんとか正気で生き伸びたいとねがう。（大江健三郎『沖縄ノート』 p.210）

の「巨塊」を「巨魁」と誤読して（この時点で日本語にならなくなっているにも拘わらず）、「罪の巨魁という人がいるのなら絶対見に行かなきゃいけない」と思ってしまった人がいたらしい（曽野綾子の「誤読」から始まった。大江健三郎の『沖縄ノート』裁判をめぐる悲喜劇。）

作家の曽野綾子さん。壊すほど使い込んでいる広辞苑に載っていない語を大江健三郎さんが使うわけがない、とか思ったのかしら（たとえば大野晋『日本語練習帳』のp.18）

そういう人の調査を結構重要視している社説が2本

• 沖縄集団自決訴訟　論点ぼかした問題判決だ（産経）
• 集団自決判決　「軍命令」は認定されなかった（読売）

過去の事実を改変しようとすることを快く思っていない人が産経や読売にいるのだろう。彼らはきっと、「改変派」を貶めるにはどうすればいいかと考えたに違いない。そして、勘違いでも裁判沙汰にする困った「改変派」というイメージを作り出すことを思いついたわけ（マスコミが騒いでくれれば、ふつうなら門前払いになるような話でも裁判に持ち込める）。漢字を誤読した結果の変な日本語を疑わなかった作家なんて、そっとしておいてあげればいいのに、わざわざ社説で取り上げて注目の的にしてしまう。大成功でしょう。大人のいじめは陰湿だ

ソフトウェア開発の名著を読む
柴田 芳樹
技術評論社 (2006/7/26)

「開発」というだけあって、カバーする範囲は『改訂新版 コンピュータの名著・古典100冊』より狭いが、そのぶん、じっくり紹介されている（かぶっているものも多い）。読むためのモチベーションを高めるには、『100冊』よりこっちがいいでしょう（モチベーションが必要なのは、最後の2冊だけかもしれないが）

1. ジェラルド・M. ワインバーグ『プログラミングの心理学―または、ハイテクノロジーの人間学』
2. Jr.,フレデリック・P. ブルックス『人月の神話―狼人間を撃つ銀の弾はない』
3. トム・デマルコ, ティモシー・リスター『ピープルウエア － ヤル気こそプロジェクト成功の鍵』
4. トム デマルコ『デッドライン―ソフト開発を成功に導く101の法則』
5. ピート マクブリーン『ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード』
6. アンドリュー ハント, デビッド トーマス『達人プログラマー―システム開発の職人から名匠への道』
7. スティーブ マコネル『Code Complete―完全なプログラミングを目指して』上・下
8. ブライアン カーニハン, ロブ パイク『プログラミング作法』

もとが雑誌の連載だから、編集の問題なんだろうけど、この小さい本で同じ部分（『プログラミング作法』のp.50）を2回も引用するのはどうなんだろう

大事なポイントは、良いスタイルは習慣の問題だということだ。自分でコードを書き起こす際にスタイルに配慮し、時間をとってスタイルを見直し改善していけば、良い習慣が身につくようになる。（p. 146, 179）