2014-04

2014-04-05 

第3回電王戦第4局はかなりの熱戦だったが、ちょっと素人目に見ても「?」な攻め筋から徐々に差が開いて行った感じだったな。相矢倉でがっぷり四つに組んでのねじり合いは見応えあったし、途中までは森下九段が相当指せそうに思ったのだが。どうも仕掛けるタイミングが早かったか、あるいは仕掛けが遅かったか。これは第2局でも感じたけど、ソフト側がなんか人間が仕掛けるタイミングを見誤るように指しているようにもちょっと感じたりする。まあ、それって結局はソフトが強いって事なんだが。

あと事前にそれほどガッツリ練習していなくていい勝負、でも本業の方は成績が上向いているという事、事前に200局も練習した菅井五段が五分五分だったと語っている事を考えると、それこそ豊島七段クラスの棋士があんだけソフトの指し筋を研究するのでない限りは事前練習のアドバンテージって全然ないんじゃないのかなと思う。(渡辺明二冠も「ソフトの事前提供アリのルールなら棋士側有利、という前評判が誤りだったことがはっきりしてきました。」と書いてるね)

多分ドワンゴ的には興業を続けるためにも棋士に勝ってほしかったんだろうけど、ぶっちゃけ棋士には本業があるわけで、じゃあそっち疎かにして電王戦に注力できるかっていうと無理なわけで。そういう意味じゃ事前貸出アリでバージョンアップ禁止はあんまり良いレギュレーションではなかったのか。第2局ぐらいの時はまあ丁度いいレギュレーションだったんじゃないのと思ったりもしたけど。むしろ統一ハードウェアが効いていたりすんのかな。結構、マシンパワーでソフトの強さって変わったりするから。

一方でソフト側がプロに普通に勝てるレベルにあって尚且つプロ同士の対局のような研究が有効であれば、プロの技術向上にコンピュータが使えるということでもあるわけで、それがコンピュータと人間の共存共栄というところに繋がるのかなと。

2014-04-06 

最近は何故か仕事で動画プレイヤーのフロントエンドをCで作るなどしているが、一つ残念なのはその動画ファイルがベンダーの独自形式のためにそこで得られた技術にはポータビリティがあまりないというところ。GUIライブラリはFLOSSを選ぶつもりなのでそちらの方はまあいいのだが……。まあ、どちらにせよそんなに大層なものではないのだが。

それでまあ一応今のところはwxWidgetsを使って開発しているのだが、なんつーかいきなりVisual StudioでWin32コンソールアプリケーションでプロジェクトを作ると動かないという罠に嵌ったり、ベンダーから提供されているライブラリが諸事情によりリリースビルドしか使えない状態なのでデバッグがクソ大変だったり、そもそも本来はLinuxでの開発のはずだが先方の手違いがあったりなど、悪戦苦闘しつつもベンダーが正しいライブラリを送ってくる前に俺がなんか一通りの検証を終えそうというわけの分からないことになっている。

いやまあ俺はプログラマーとしての腕の見せ所なので別にいいが、俺って確かコアメンバーじゃなくてあくまで期限付きの支援だよなあ。ここまでタフな仕事になるならもうちょいギャラを吹っ掛けておけば良かったか。

2014-04-12 

第3回電王戦第5局はすげえ熱戦だったな。本当に最後の方まで決定的な差はなかったようで、あの一つの見落としがなければまだわからなかったらしい。というかまたしても異次元の将棋というか、先の森下vsツツカナ戦も俺がどうかと思った手に実はしっかりした読みの根拠があったりと凄まじい対局だったのだが、今回も一見筋悪っぽい手が後々生きてくる上に展開次第ではそっぽに打った金も生きてくるようで、あれはもう人ならざるものの戦いとしか言いようがない。いや相手は人じゃねえんだけど。

こうして5局を振り返って見ると、どれもそれぞれに見どころの多い対局だった。いろんな意味で、人対人やCPU対CPUではああいう対局は見られなかったんじゃないかと思う。というわけでどれも甲乙つけがたいのだが、俺がMVPを選ぶなら棋士側は豊島さんかなあ。1000局近い猛練習、早々に研究から外れてもやるしかない手なので腹を決めてノータイム、しかもそれがワンミスで即死のある横歩取りでのやり合いというのは痺れた。ソフト側はツツカナの重厚な差し回しがむしろ森下さんっぽかったりというのが面白かった。でもベストバウトは第5局かなあと思ったりする。本当に終盤まで決定的な有利不利がわからなかったし。

しかしなんかここ最近電王戦の事しか書いてないなあ。まあ、仕事が割と多忙で他にネタがないせいであるのだが。

2014-04-16 

なんでも高校数学のカリキュラムから行列が削除されて複素平面が復活という話らしいのだが、いやこれどうなんだろう。複素平面が悪いとか言いたいわけではなく、行列を落とす理由がわからない。行列の方は高校数学の中でもかなり実用的というか、面白い応用例が見つかるところだ。その面白い応用例というのはグラフィックスプログラミングで、三角関数と行列で基礎的な座標変換は比較的簡単に行える。これは案外バカにできたものではなく、今の仕事では高校レベルの数学の知識があったおかげで(ってか数学C取ってた&大学でゲームプログラミングしてたおかげで)楽をできた部分が結構ある。もちろん複素平面の知識でできないわけでないのだが、どうせ同じ事やるなら行列の方がわかりやすいんじゃないか。少なくとも俺はそう思う。というか複素平面やるなら行列もやった方がわかりやすい気が。

ちなみに例に出したグラフィックスプログラミングは俺の大学時代よりも身近になっていると感じるし、それこそ最近のプログラミング言語ならグラフィックスの扱いはかなり簡単になっているので、生きた知識として数学を教える絶好の機会なんじゃないかと思うのだが。まあ、より高度な3Dグラフィックスプログラミングになると四元数の知識とか必要になってくるんだが、まあそれは明らかに高校の授業のレベルを越える話な上に単にグラフィックを表示するのに必要なのと数学的な探究のとでギャップがより大きくなるところだったと記憶しているので……(俺もそこまで突き詰めてやってたわけじゃないが)。それに比べると行列は2×2の行列の演算だけで2Dゲームが作れるぐらい実りがあるので、知識の探求と実用性のバランスがちょうどいいところだと思われる。

2014-04-18 

割と俺は人月見積りが嫌いな人に見られることがあり、まあ実際好きではないのだが、そもそも俺は見積り作業自体が嫌いなのでまあ。それはそれとして、人月見積り自体はぶっちゃけエンタープライズ分野だと仕方がないというか、何か前にも書いた気がするがソフトウェアの価格をどう決定するかという問題がまずあり、エンタープライズだとワンオフもの+保守作業なのでより一層価格の決定が難しく、だったら規模と工数と頭数で計算するのは理に適っている事ではある。なので支持する支持しないという話ではなく、他に良いやり方がないという話。

あとこれにはプログラマの生産性の話も関わってくるのだが、最近多忙で疲れているので今日はここまで。ひとまずキーポイントだけ一個挙げとくと、多分プログラマの生産性の話をしても様々な意味であまり収穫はなく、恐らくプロジェクトのボトルネックの観点から考えていった方が筋が良い。