アルゴリズム

確率の変な話

myugaru (myugaru@wankuma.com) — Sat, 05 Apr 2008 16:24:00 GMT

（※最新情報：れいさんからの情報により以下は冗談ページであることが判明しました。とりあえずモヤモヤが晴れて良かったです＾＾。れいさんありがとうございました）

ゲーム理論で色々検索していましたところ、とても興味深い怪しい話を見つけました。

絶対何かおかしいのですが、著者は妙に数学に詳しいとみえて説得力ある文になっていてどこに矛盾があるのか、理論に無理があるのか、が凡人な私には上手くそれを看破できないのであります。

ちなみに書かれた時期が不明なので今この人に連絡つけたりできるホットな話題なのかどうかが不明です。

●「その１．神はサイコロをもてあそぶか？」

ここでは全世界のサイコロが平均すると出目が平均値になる、という事を神がかり的に説明しています。

つまりある時点で６の目が出ると、次のサイコロを振ると６の目の出る確率が６分の１より若干減るのだ、と力説しています。

●「その２．運は実力のうちか？」

ここでは打率の話を持ってきて、ある人は確率を変動する能力を持っているのだ、ということを力説しています。

●「その３．カメはうさぎに勝ったのか？」

”その１”に”その２”を当てはめると６の目を５分の１で出せる能力の人間だって居るって事になるという話になります。

その矛盾点をも怪しい言葉のマジックでうまく丸め込もうとしています。

私が少なくとも興味をもったのは

１．この著者はここに書かれたことを本気で書いているのか？（ある意味変人？確信犯）

２．この著者はここに書かれたことをウソと知って書いているのか？（~~確信犯~~）

なのかです。

どっちにしても私の周りに現実に居たら私はきっと避けて通りたい種族ではあります。

避けて通れない場合には尋常じゃない被害を受けることも予想できます＞＜怖いです・・。

先に書きましたとおりこの人にすぐ連絡したり、あるいは説得して論破するとかできるとは思えないです。

ここでは出来れば私にこの人の書いた文章の正しい読み方？をお教えくださるコメントを希望しています＾＾；

（※確信犯の意味を私が間違って逆に理解していました。すみません凪瀬さんご指摘ありがとうございます）

委譲というのは２通りあります～私の理解した答っぽいもの

myugaru (myugaru@wankuma.com) — Mon, 24 Mar 2008 18:37:00 GMT

●前エントリー

多重継承をコンポーネント技術で考える

多重継承を前提に考えなければ・・・

●元ネタ

実装を委譲できる言語を作ればいいのかもしれない

●大元のネタ

http://d.hatena.ne.jp/m-hiyama/20080304/1204615775

（↑の檜山さんの方で何か動きがあるようです。明日以降にエントリーするとかしないとか・・・。楽しみですね）

●まず委譲というのは２通りあります

class A
{
    public event EventHandler MouseClick;
    public void OnMouseClick()
    {
        if (MouseClick != null) {
            MouseClick(this, new EventArgs());
        }
    }
}
    
class B
{
    A a = new A();
    
    public B()
    {
        a.MouseClick += new EventHandler(MouseClick);
    }
    
    public void MouseClick(object sender, EventArgs e)
    {
        Console.WriteLine("マウスが押されました");
    }
}
    
class C
{
    B b = new B();
    
    public void MouseClick()
    {
        b.MouseClick(this, new EventArgs());
    }
}

上のコードでクラスＡもクラスＣもクラスＢへ処理を委譲しています。
処理を自分ではなく相手にゆだねるというのが委譲の仕組みです。
インスタンスが必ず関与します。
ただし含まれる方が委譲しているのか委譲されているのかというのは
上記でわかるようにどちらも実現が可能です。

●凪瀬さんと私の会話での委譲

私は凪瀬さんはクラスＣを想定していると考えました。
私はこのクラスＡの形を私はコンポーネントであると言いました。
そして、よりＩＤＥにサポートされているクラスＡを推しました。
この時点で実はコンポーネントが委譲であると気付いていませんでした。
ついさっきふっと気が付きこのエントリーを書くに至りました。
どちらも委譲であったために技術的に交換が可能だったわけです。

●ダイアモンド継承

ここでダイアモンド継承を考えます。

class A { Aの部分 }

　　
class B1 : A { Aの部分+B1の追加部分 }
　　

class B2 : A { Aの部分+B2の追加部分 }
　　

class C : B1, B2 { Aの部分+B1の追加部分+B2の追加部分 }

ここで示したダイアモンド継承のクラスＣの中にＡの部分は１つしかありません。
私は前エントリーでこのクラスＣの中にAの部分が２つ含まれると勘違いしました。
それは委譲で表現するという事から考えたためでした。
委譲というのは先に言ったように２通り書けますが、どちらもかならずインスタンスを介する技術だからです。
この場合ですとＢ１とＢ２のインスタンスが必要になり、どちらのインスタンスにもＡの部分は含まれます。
本来のダイアモンド継承はインスタンスを介さない継承でしか作り得ない技術なのです。

●凪瀬さんの考える委譲とは

それでも凪瀬さんが委譲でなんとかできるという理由がなんとなくわかりました。
凪瀬さんはさらにこのダイアモンド継承の図の最後のクラスから外向けのインターフェースを
指して委譲で実現できるとおっしゃっているように思いました。
すなわち

class C : B1, B2
{
    B1 b1;
    B2 b2;
    
    public FuncA()
    {
        b1.FuncA();
    }
}

ここでFuncAはクラスAに含まれるメソッドです。
ここではb1とb2という２つのインスタンスがありメモリ上のＡの部分は両方に存在します。
しかしＣというクラスを外から見るとクラスＣのpublicなFuncAというメソッドは一つです。
そしてこのFuncAがb1かb2のどちらのFuncAを呼び出すかは自由だと言うことだと思いました。
メモリイメージが２つあるというのは論点ではなく、Ｃから外向きインターフェース上のAの部分が一つになるように委譲でも表現可能であるという意味だと捉えました。

凪瀬さんこれで正解でしょうか？

多重継承をコンポーネント技術で考える

myugaru (myugaru@wankuma.com) — Sun, 23 Mar 2008 09:43:00 GMT

最近モチベダウンのmyugaruです。おはようございます。

気分転換に凪瀬さんとかずきさんにトラックバックしてみようと思います。

凪瀬さんの実装を委譲できる言語を作ればいいのかもしれないより
「檜山正幸のキマイラ飼育記なんで多重継承はそんなに嫌われるのか？ちょっくら分析してみるかあたりからの着想
多重継承が～という話題は継承をインターフェースの継承だけにした上で、実装を委譲する機能を言語に持たせれば解決するかもしれない。」

引用されている「多重継承が～」という話を読んでみました。
多重継承を必要とするケースは世の中にあると私も思いました。
そして多重継承を使わずにどう解決しているか？に目を向けてみました。

まず現実問題として。
C#で考えるとインターフェースの多重実装は可能ですがクラスの多重継承はできません。
C#で委譲が優遇されていないことはかずきさんが確認されたとおりです。（[Ruby][Java][C#]丸投げ委譲）

では多重継承はC#では不要なのかというと話は違うと思います。
先に書きましたが、それを必要とするケースは世の中にあると思うのです。
少し考えてきて私はそれはコンポーネント技術で置き換えられないか？と発想してみました。

次のフォームを見ると、
２つのボタンは２つのタブに乗っています。
それら２つのタブがフォームへさらに乗っています。
これを~~ボタンのダイアモンド継承~~基底クラスが同じ場合の多重継承を表すと考えてみます。

（11:50：↑επιστημηさんの本を読んだはずなのに・・・シャノンさんの御指摘により修正しました。以降も同様の修正あり）

継承・委譲というとボタンだったら継承・委譲後もボタンになるべきでしょう。
上の図で言えばタブはタブのままでありボタンを継承や委譲してると言えません。
しかし機能の量に注目しますとタブはボタンを貼り付けたおかげでボタンの機能が増えました。
たとえばこれが継承・委譲だったら継承したボタンは元のボタンの機能に新しい機能を追加し~~ます。~~ているでしょう。

（11:19：シャノンさんのご指摘により上の赤字部分を修正しました。紛らわしくてすみません。御指摘ありがとうございました）

どちらも機能量は元のボタンの機能＋αとなります。
なので両者は機能面で同等の問題を解決できる手段になりうると考えても間違いじゃないと思います。

凪瀬さんが書いている~~ダイアモンド継承~~基底クラスが同じ場合の多重継承でのどちらの親の実装を使うべきか問題は、
ここに見えるどちらのボタンを押すべきか？という問題に置き換えられるかと思います。
両方見せておいてユーザーが必要な方のボタンを押します。
実際には両者の内容を識別できるようなラベルが書いてあるべきでしょう。

多重継承をコンポーネント技術の話に全て置き換えられるか？
と問い詰められるともう少し踏み込みが必要でしょう。
私がコンポーネント技術を推すのはIDEによって多くの恩恵が受けられるメリットや、
そもそもC#などの言語で多重継承がなくなった経緯に関係があるのでは？
など色々と考えての勝手な推論です。

継承・委譲・コンポーネント技術の違いを入力の流れで書きます。

継承・委譲の入力は子から親へ伝わります。
　ユーザーからの入力は子が受けます。
　親へはbase呼び出しなどで処理を中継して伝えていきます。
　追加機能は中継時に前処理や後処理で記述します。

コンポーネントの入力は親から子へ伝わります。
　ユーザーからの入力は親にあたるコンポーネントに入ります。
　子であるコンテナにはイベントによって処理を中継します。
　追加機能は後処理や前処理に該当するイベントハンドラーを作って記述します。

●具体的にコードを提示してみます

これはかずきさんが例とされていたものと同等です。
+=を書くとイベントハンドラーが自動実装されます。
先に書いたとおりイベントのサポートにはどの言語のIDEも多大に力が注がれているでしょう。
VSでもコード入力の手間はeclipseでの委譲実装並みだと思いますがどうでしょうか？
実際私はほとんど頭文字＋tabとかで入力ができました。
ここでは後処理のハンドラーを実装してみました。
PiyoからhogeへアクセスするHogeプロパティもあわせて実装しています。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
    
namespace Com.Wankuma.Kazuki.Deleg
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }
    
    class Hoge
    {
        public event Action AfterFoo;
        public event Action AfterBoo;
    
        public void Foo()
        {
            Console.WriteLine("Hoge#Foo");
            AfterFoo();
        }
        public void Boo()
        {
            Console.WriteLine("Hoge#Boo");
            AfterBoo();
        }
    }
    
    class Piyo
    {
        private Hoge hoge = new Hoge();
        public Hoge Hoge { get { return hoge; } }
    
        public Piyo()
        {
            hoge.AfterFoo += new Action(hoge_AfterFoo);
            hoge.AfterBoo += new Action(hoge_AfterBoo);
        }
    
        void hoge_AfterBoo()
        {
        }
    
        void hoge_AfterFoo()
        {
        }
    }
}

●問題点
たぶん継承・委譲よりもイベントによる処理は重いと考えられます。
でもC#に限って言えば多重継承は実質不可能ですので
可読性を落とすような裏技的なコーディングスタイルをとるよりは
素直にコンポーネントに頼った方がよさそうに思います。

Pixel-to-Pixel速度比較（観点が不明確だった）

myugaru (myugaru@wankuma.com) — Sat, 15 Mar 2008 19:55:00 GMT

今日は「Pixel-to-Pixel速度比較」のまとめをしたかったのですが、

うっかり大変なことを忘れておりました。

家族でちょっとしたイベントのある夜だったのです。

・・・ということであまり綺麗にまとめる時間がなくなってしまいました。

でもざっくり書いてみます。（あとで修正するかもしれません）

25:00追記

前回「ある条件」って書いてたのでそれに即して書き記します。

私が目的にしていることはDirectXで背景画をリアルタイムで書き換える手段の検討でした。

目的から考えれば手段としてはGDI+に頼ること自体が方向性として微妙だったなと途中で気付いたのです。

つまり「私がやりたいことはライブラリImageUtilsで処理を書く必要があるかどうか」という条件だったわけです。

流れる星などのエフェクト効果はピクセルで描画できたら実装できそうに思いました。そこからGDI+へ考えを進めるのではなくてDirectXのピクセルレンダリングのパスへそういうピクセル単位でのドットON/OFFを設定できるのかという方向へ話をもっていくべきでした。この話の方向はいづれ考えてみようと思います。

そういうわけですが。

たとえ微妙方向性だとしても乗りかかってしまった船なので、とりあえずこのエントリーは決着は付けようと思っています。

●ColorMatrixが速いのはおかしい

私は実は計測する前からLockBits/UnlockBitsの方が速いと予想していました。

（追記：前回納得できていない、と書いたのは、上の追記に書いたとおり話が微妙だってたことに気付いたのもありますが、予想が外れていて納得できないという意味もありました）

前回ColorMatrixが速くなったような結論が出たのは、

速度重視思想だけでは無いImageUtilsを使用したためだと考えれば納得できます。

●作者junkiさんの記事

Bitmap の内部色データにアクセスする (1)

「このコードは、前回の配列コピーの場合より、さらに４倍以上速い。この方法は unsafe{} ブロックを含むが、もっとも高速なので以後はこの方法を使うことにする。」

この時点ではライブラリでunsafeを使用する事を考えていらっしゃいました。

Bitmap の内部色データにアクセスする (3)

「図は、今回つくったクラスをつかって画像のすべてのピクセルの R 成分と G 成分を入れ換えたものである。ここでテストしたように、前回の unsafe コードに比べると３－４割時間がかかって遅くなるが、なによりポインタをあらわに使わないで済むことは重要である。」

しかしunsafeを使用するデメリットなどをjunkiさんなりに考慮された上で最終的には時間がかかってもunsafe未使用方式を採用に到っておられます。

●まとめ

ライブラリImageUtilsの思想は「GDI+の描画処理で加工できないBitmap（具体的には８ビットのカラーパレット式ビットマップなど）を加工できる」という事を可能とするライブラリでした。

私がそのImageUtilsを使って処理を書きたいのであればColorMatrixでは処理を書けないということになります。

私が扱う画像がGDI+で加工する事をしたい＆unsafeは使いたくないのであればColorMatrixを使えばよいということになります。

私が扱う画像がGDI+で加工する事をしたい＆unsafeを使っても速くしたいのであればLockbits/UnlockBitsを使えばよいということになります。

つまり何の速度差を知りたかったのかを明確にしなければ議論することができない話だったとわかりました。

●次回？

ということでもうちょっと観点を明確にしてちゃんと実測してみたいと思います。

Pixel-to-Pixel速度比較

myugaru (myugaru@wankuma.com) — Thu, 13 Mar 2008 22:19:00 GMT

リフレクション

[C#,VB.NET]Graphics.DrawImage(image,0,0)の落とし穴

VC#Express2008で.NET Frameworkのライブラリ・ソースへステップイン

これらのエントリーは実はちょっと確認したいことがあった流れで書いてました。
確認したかったのはGDI+の処理速度です。
具体的には「同じ結果を導く異なる描画方法の処理速度差」になると思います。
もちろん速い方を選びたいのが人情でしょう。
今日は上の流れで見つけたある２つの同じ結果を導く違う描画方法の比較をしようと思います。

●比較対象処理
Pixel-to-Pixel処理の一種であるグレースケール化です。
方式１：Bitmap.LockBits/Bitmap.UnlockBitsで画像の画素情報に直接アクセス
方式２：System.Drawing.Imaging.ColorMatrixによる色の行列変換

●テストプログラム詳細

ダウンロード：C# - GrayScaleSpeedTest.zip

共通部分
・画像はjpg画像に限定し24bitピクセルフォーマットでの比較を行う。
・まずファイルオープンダイアログでjpgを選択
・フォームクラスのローカル変数originalBmpに画像を保管
・各方式はメニューで選択
・選択された方式にoriginalBmpを引き渡しピクチャボックスへ結果を描画させる

方式１部分
・junki氏の画像処理ライブラリ「ImageUtils」（※１）のGrayScale24()を使用（このメソッドは内部でBitmap.LockBits/Bitmap.UnlockBitsを使用してグレースケール化を行う）
・引数にBitmapの参照を渡し返値は参照に上書きして返ってくるので、方式１開始部分で一旦originalBmpのクローンを作ってGrayScale24()で処理し返値をピクチャボックスへ設定する。

※１：Image Processing Utilities for C#2.0 (VC# 2005) Copyright junki, Jan, 2006 -
junki氏 HP：http://junki.lix.jp/　ImageUtils：http://junki.lix.jp/archives2/ImageUtils.lzh

方式２部分
・ColorMatrixに次の行列を設定

[ 0.299, 0.299, 0.299, 0.0, 0.0 ]
[ 0.587, 0.587, 0.587, 0.0, 0.0 ]
[ 0.114, 0.114, 0.114, 0.0, 0.0 ]
[   0.0,   0.0,   0.0, 1.0, 0.0 ]
[   0.0,   0.0,   0.0, 0.0, 1.0 ]

・ImageAttributesを作成し行列を設定
・変換用にoriginalBmpと同サイズ、24bitピクセルフォーマットのビットマップ作成
・Graphics.DrawImageにImageAttributesを渡し変換用ビットマップに対してグレースケールで描画を行う。
・変換用ビットマップをピクチャボックスへ設定する。

●結果
フリー写真素材（※２）をお借りして方式１と方式２でそれぞれ１００回ずつ変換を行った。
以下はそれぞれの方式のかかった時間を５回ずつ表示させています

ColorMatrixを用いた方が速いという結果になりました。

※２：ren氏HP：http://sk-d.a-thera.jp/
ダウンロード：http://www.photolibrary.jp/profile/artist_244_1.html

●実は納得していなかった
私はこのテストではColorMatrixの優位を証明できていないと思っています。
jpgが悪いとか誤字とか行列の値が違ってるとかループ回数が少ないとか多いとかではありません。
このテストでもある条件下では私も十分に納得すると思います。
でも今回はその条件ではないので納得していないわけです。

ではある条件とは一体何のことでしょう？
＃うーーん。実は引っ張るほど大した話じゃないかもですが・・・

この続きは明日か・・・明後日かもです。
色々と考えて楽しみにしててください。

＃聞くと本当に大した事じゃないので怒らないでくださいね。

コルーチンのyieldはDoEventsです

myugaru (myugaru@wankuma.com) — Tue, 11 Mar 2008 14:35:00 GMT

前エントリー：http://blogs.wankuma.com/myugaru/archive/2008/03/10/127092.aspx

siokoshouさんのコメントを拝見しまして私の説明力・説得力の無さを痛感しました。
ちょっと悔しいので今日は別の切り口で説明のリベンジをしたいと思います。

（また失敗に終わる予感もしますが・・・）

話はWindowsプログラミングです。

ボタン１をクリックすると画面の中央に
「ボタン１が押されました」
という文字が0.5秒間隔で点滅し、
ボタン２を押すとそれが消える

と仮定してください。

以下のようにプログラムを作ったとします。

ボタン１クリック()
{
　while (ボタン２フラグ == OFF) {
　　while (0.5秒間)
　　　「ボタン１が押されました」表示
　　while (0.5秒間)
　　　//何もしない
　}
}
　
ボタン２クリック()
{
　ボタン２フラグ = ON
}

一見仕様は満たされています。しかし上のプログラムは上手く動作しません。
ボタン１をクリックしてしまうと画面が真っ白になってしまうことでしょう。
誰でも一度くらいは経験があるフリーズという状態です。
タスクの切替が考慮されていないために起こる現象です。

改良したボタン１クリックが次のプログラムです。

ボタン１クリック()
{
　while (ボタン２フラグ == OFF) {
　　while (0.5秒間) {
　　　「ボタン１が押されました」表示
　　　DoEvents();
　　}
　　while (0.5秒間) {
　　　DoEvents();
　　}
　}
}

DoEventsはここではWindowsへ制御を渡す役割をする関数と思ってください。
・・・長く説明すると馬鹿にしてるとお叱りを受けますからここでやめます（苦笑

コルーチンで同じことを考えましょう。
ボタン１クリックは次のように書けます。

ボタン１クリック()
{
　while (ボタン２フラグ == OFF) {
　　while (0.5秒間) {
　　　「ボタン１が押されました」表示
　　　yield return 適当;
　　}
　　while (0.5秒間) {
　　　yield return 適当;
　　}
　}
}

コルーチンのyieldは状態をレジュームしメインループに制御を戻します。
次回の呼び出し時はyieldの次から再開されます。
DoEventsと全く同じですね。ここは大丈夫ですよね？

さてまたWindowsへ戻ります。
このボタン１クリックを呼び出しているのはWindowsならばWinProcに当ります。
そこにメインループが書かれています。

WinProc()
{
　while (true) {
　　switch (イベント) {
　　　case ボタン１:
　　　　ボタン１クリック();
　　　　break;
　　　case ボタン２：
　　　　ボタン２クリック();
　　　　break;
　　}
　}
}

上のコードには実は隠された処理が多く存在しています。
たとえばDoEventでの処理中断再開の機構が見えません。
しかしここで全て書くにはあまりに膨大です。
それにWindowsも一般的になってきたので省略します。

余談ですが。昔々~~Windows98がまだ健在だった時代。~~今も健在だとお叱り受けますね＾＾；；
自分の会社が初めて業務でWindowsを扱うことになった頃に上のような処理で、
「ボタン１の処理中にどうしてボタン２へ飛んでいけるのか」
を何日も何日も何日もかけて上司に説明した事を思い出しています（笑

話を戻します。私が実装を予定しているゲームメインはこうなります。
WinProcでは隠されていたと説明した部分もここでは露見します。

GameLoop()
{
　IEnumerator ボタン１タスク = ボタン１クリック();
　IEnumerator ボタン２タスク = ボタン２クリック();
　List タスクリスト
　タスクリスト.Add(ボタン１タスク)
　タスクリスト.Add(ボタン２タスク)
　while (true) {
　　　foreach (タスク in タスクリスト)（★１）
　　　　if (!タスク.MoveNext()) {
　　　　　//終了したタスクを除外
　　　　　タスクリスト.Remove(タスク)
　　　　}
　　}
　}
}

★１：（15:40追記）実際には私の独自実装をほどこしたLinkedListを用います。

説明の本質から外れるので便宜上foreachを用いましたが現実のC#言語のforeachはノードを削除することはできません。

削除を考慮した独自のLinkedList拡張→http://blogs.wankuma.com/myugaru/archive/2008/03/06/126581.aspx

Windowsでの実装とコルーチンでの実装をご覧いただきました。
両者は

「処理を一旦中断し別タスクへ処理のチャンスを渡す」

という全く同じ基本思想で成り立っています。

●では再度お尋ねします。コルーチンのyieldは何を返すのでしょうか？

コルーチンのyieldが返す値についてもう一度だけ考えてみてほしいと思います。
列挙のyieldではありません。コルーチンのyieldです。

WindowsのDoEventsととらえてこれを再考するといかがでしょうか？
例題を見てもらうと両者の位置付けは全く同一です。
果たしてDoEventsは何を返すべきでしょう？ボタン１クリックの返値ではありませんよ。
yield returnがCurrentを返すと考えると上記でのDoEventsにとってのCurrentに該当するものは一体なんなのでしょうか？
ボタン１の所属する・・この場合はFormになるのでしょうか？
そうでなければ何であれば適当ですか？

またコルーチンを列挙とどうしてもとらえたいという方にはボタン１クリック()というハンドラーを列挙と捕らえることにどういう意味があるかを再考いただければと思います。

前エントリーから私の意見は「コルーチンのyieldの返値は無意味であり不要である」です。
DoEventsだって返値は現実にありませんものね。

お時間ありましたら再度皆さんのご感想などいただけたらうれしく思います。

ここまで読んでお付き合いくださった方に感謝いたします。ありがとうございます。

C#のyieldに対する誤解と私の見解

myugaru (myugaru@wankuma.com) — Mon, 10 Mar 2008 20:26:00 GMT

コルーチンの話を進める上でどうしてもC#のyieldを理解してもらわなくてはいけません。

凪瀬さんも少し誤解されているように感じました。

ここで少し解説したいと思います。

●実は何も返してないyield return
ご存じなければ驚くかもしれませんがyield returnは正確には何も返していません。
まずMoveNextの返値ではありません。
MoveNextの返値はMoveNextの成功可否をboolで返します。
つまり列挙が継続可能かを返します。
ではyield returnは何を返しているかというと、
IEnumeratorインターフェースのCurrentプロパティの内容を更新しています。
言語構文上returnという単語を用いているだけなのです。
なので「何か返している」という誤解が生じているように思います。

using System;
using System.Collections;
namespace CoRoutine
{
    static class Program
    {
        [STAThread]
        static void Main(string[] args)
        {
            IEnumerator e = TaskA();
            for (int i = 0; i < 10; i++) {
                bool b = e.MoveNext();
                Console.WriteLine(e.Current);
            }
        }
        static IEnumerator TaskA()
        {
            while (true) {
                for (int i = 1; i <= 3; i++) {
                    yield return i;
                }
            }
        }
    }
}

●Currentで表現できる状態変化
具体的なゲームの話をしましょう。
「男の子がまばたきしている」
ことを考えます。
Boyには状態を変化させるUpdateメソッドと
現状を画面へ表示するRenderメソッドがあります。

Boy boy = new Boy();
while (boy.生きている間)
{
    boy.Update();
    boy.Render();
}

Updateメソッドの実装は次のようになるでしょう。
３項演算を使えばもっとシンプル化も可能です。

void Update()
{
    if (this.eye == CLOSE)
       this.eye = OPEN;
    else
       this.eye = CLOSE;
}

ここでは目というプロパティに値を代入することで
状態変化を表現しています。
これはyield構文を使うとこのように書けるでしょう。

class Boy
{
    IEnumerator enumerator;
    public Boy()
    {
        enumerator = GetEnumerator();
    }
    void Update()
    {
        enumerator.MoveNext();
        eye = enumerator.Current;
    }
    IEnumerator GetEnumerator()
    {
        while (true) {
            yield return OPEN;
            yield return CLOSE;
        }
    }
}

●Currentでは表現できないケース
さて別の実装を考えます。
「女の子が携帯メールを打ちながら笑いながら歩いている」
ことを考えます
GirlはBoyと同じく状態を変化させるUpdateメソッドと
現状を画面へ表示するRenderメソッドがあります。
メインループはBoyと同じなので省略します。
yieldを使わない場合、今回のUpdateメソッドはこのように
なっているとします。

void Update()
{
    // メール内容を追加する
    string s = GetNextMailSentence();
    this.phone.Add(s);
    // 歩く
    MoveStep();
}

状態変化はすべてメソッドによって実装されています。
この場合、反論はあるかも知れませんが私はyieldの実装はこのようにするのを理想と考えています。

class Girl
{
    IEnumerator enumerator;
    public Girl()
    {
        enumerator = GetEnumerator();
    }
    void Update()
    {
        enumerator.MoveNext();
    }
    IEnumerator GetEnumerator()
    {
        while (true) {
            // メール内容を追加する
            string s = GetNextMailSentence();
            this.phone.Add(s);
            // 歩く
            MoveStep();
            yield return 0;
        }
    }
}

●私の見解
状態変化が１つのプロパティの代入による場合、
yield returnの返値としてそれを表現することができます。
しかし現実には
・複数のプロパティによって表現された状態
・代入で表現できない状態変化
などは多くありますので一般論的にみるとyield returnによる一つの値の上書きには意味を持たせる必然性は全くないと私は考えます。

むしろyieldを思想として列挙を考えていない別言語のyieldになぞらえて使用しているのである、という意思表示のためにもコルーチンとしてのyieldは無意味な値を返すべきだと考えます。
それはコルーチン向けの言語で返値が存在していない理由の一つだとこじつけられそうにも思います。

コルーチンはマイクロスレッドでありファイバーである

myugaru (myugaru@wankuma.com) — Mon, 10 Mar 2008 17:09:00 GMT

（前エントリー：http://blogs.wankuma.com/myugaru/archive/2008/03/10/127005.aspx）

前エントリーのコルーチンという概念は様々な人が独立して発見しているようです。

（人間って素晴らしいですね！）

なので色々な単語で表現されているようです。

そのなかでもマイクロスレッドやファイバーが有名みたいです。

（あと今回は~~面倒なので~~言及してませんがtry～catch構文とか
C言語のlongjump()とか古いBASICのON ERRORからのRESUMEなんかでも
同一概念を表現する手段としてひょっとしたら使い道がありそうです。）

●まずマイクロスレッドの紹介です。全くコルーチンと同じ内容です。

前エントリーで凪瀬さんが返値を使っていないのがキショクワルイとの指摘でしたが、

このマイクロスレッドの参照ＵＲＬにかかれている例をみてもらうと返値を使っていないという

例にもなっています。そしてとても完成度が高いドキュメントです。（ゲームも完成度は相当高いです）

＃この仕様はさっそくそのまま模倣させてもらおうかとｗｗ

マイクロスレッド講座 - 弾幕風Wiki

東方弾幕風 - と～ほ～GC

●つぎにファイバーの紹介です。

と思ったのですがゲーム的な説明ページを見つけられませんでした。

ファイバーというのはRuby言語にそのものずばりのクラスが存在しています。

ここは、

Ruby言語にお詳しい方にエントリーを書いていただいてトラックバック

いただけるととても嬉しいです（タリキホンガンといいますｗｗ）

class Fiber - Rubyリファレンスマニュアル刷新計画

17:50追記

シャノンさんよりWIN32APIにCreateFiber()なるものがあるとのご指摘をいただきました。

なのでこちらについてもお詳しい方からのトラバを（ｒｙ

シャノンさん、ありがとうございました。

コルーチンと運命の出会い

myugaru (myugaru@wankuma.com) — Mon, 10 Mar 2008 11:34:00 GMT

ああ、とうとう出会ってしまいました。たぶんちょっとゲームに詳しい人ならば「myugaruはいつこれに気付くのだろう？」とか思っていたのではないでしょうか？

かれこれ３ヶ月くらいかかってやっと出会いました。

コ　ル　ー　チ　ン

今かなり笑われてる気がするけど気にせず感動に浸っておきます。

なんて素敵なコルーチン。

おかげで私が考えていた「ややこしいタスクシステム構想」はほとんど０に帰しましたｗ

じゃあこっから真面目にコルーチンについて語ります。

コルーチン - Wikipedia

この構造をゲーム関連の情報集めをしている際に見つけた。
なるほどこれは確かにすごい発想だと思う。
そしてC#のyieldは正にこの機能を実現するためにあると思った。
色々やってみると２つの利点が見えた。

第１の利点．ゲームでのタスクシステムに利用できる

もちろん一番はっきりとした利点はこれである。
簡単に説明すると例えば並列動作する２つのゲームタスクを考える。
タスクＡは３つの状態を繰り返しタスクＢは２つの状態を繰り返すと仮定する。
実際には足踏みをするキャラだったり煙突から上がる煙だったりするかも知れない。
コルーチンによる驚異的明瞭コードはこうなる。

using System;
using System.Collections;
    
namespace CoRoutine
{
    static class Program
    {
        static int stateA, stateB;
    
        [STAThread]
        static void Main(string[] args)
        {
            var a = TaskA();
            var b = TaskB();
            for (int i = 0; i < 10; i++) {
                a.MoveNext();
                b.MoveNext();
                Console.WriteLine("A{0} B{1}", stateA, stateB);
            }
            Console.ReadLine();
        }
    
        static IEnumerator TaskA()
        {
            while (true) {
                for (stateA = 1; stateA <= 3; stateA++) {
                    yield return 0;
                }
            }
        }
    
        static IEnumerator TaskB()
        {
            while (true) {
                for (stateB = 1; stateB <= 2; stateB++) {
                    yield return 0;
                }
            }
        }
    }
}

第２の利点．リバースエンジニアリングを阻止できる

先日リバースエンジニアリングの話題を出した。
http://blogs.wankuma.com/myugaru/archive/2008/03/06/126503.aspx
内容は私が他人のプログラムを解析する話になっていたが、
これが逆に私のプログラムを誰かに解析されるって事になると、
ずいぶんと勝手な言い分だけどあまり嬉しくはない。

だがここで朗報はyieldによるコルーチンは少なくとも現バージョンのReflectorでは元のソースに復元が出来ないのだ。

更に好都合なのはコルーチンにこそゲームの核となるビジネスロジックの大半が記述されるのである。

試しに上のソースをReflectorにかけてみた。結果は上のたったあれだけのソースがgotoの応酬でとんでもない事になっている。（応酬ってほど多くは無かったね＾＾；；）興味のある方はリンク先をご覧いただきたい。

上のソースのReflectorの出力結果→http://myugaru.wankuma.com/20080310CoRoutine.txt

?Ｐ．Ｓ．もしyield returnに対応したリバースエンジニアツールをご存知ならご一報くださいね＾＾；；；

[C#,VB.NET]Graphics.DrawImage(image,0,0)の落とし穴

myugaru (myugaru@wankuma.com) — Sun, 09 Mar 2008 10:20:00 GMT

[C#,VB.NET]Graphics.DrawImage(image,0,0)の落とし穴

サブタイトル：単に女の子の画像を張りたかっ(ry

12:00 すみません若干認識がずれていたようですので赤で修正しました

Graphics.DrawImage(image,0,0)は等倍表示を意味します。しかしこの等倍表示には２通りの意味があります。

●確認プログラム
確認のために以下のプログラムをダウンロードして実行してください。

これはDrawImage(image,0,0)で実装された単なる画像ビュアーです。

C#とVB.NETを用意してます。
http://myugaru.wankuma.com/DrawImageCheck_src.zip

実行形式も用意しました。実行には.Net Framework3.5が必要です。
http://myugaru.wankuma.com/DrawImageCheck_bin.zip

●確認手順
プログラムを実行すると単なるフォームが表示されます。↓の画像をドラッグ＆ドロップしてみてください。

(c)elouai.com - Candybar 4 Doll Maker http://elouai.com/candybar4/dollmakergirl.php

ブラウザで表示されているものより拡大されましたか？手持ちの画像でもこの確認プログラムとブラウザにドラッグ＆ドロップして確認してみてください。両者で見た目のサイズが違っているものはありませんか？

●原因
DrawImage(イメージ, 0, 0)は「物理サイズで等倍表示する」事を意味しています。
ですから「論理サイズでの等倍表示」を期待する人にとっては等倍と見えません。

すなわち
確認プログラムは「物理サイズ等倍表示」
ブラウザなどは「論理サイズ等倍表示」だという違いがこの現象を起こしています。

●解説
１．解像度
イメージには解像度と呼ばれるプロパティが存在しています。
水平方向の解像度＝イメージ.HorizontalResolution
垂直方向の解像度＝イメージ.VerticalResolution
ディスプレイにも解像度があります。例えば私の17インチディスプレイで~~1024×768表示時には~~解像度96dpiになっています。解像度は1024×768などを800×600に変えても変わるものではなくディスプレイそのものの能力値として機能しているようです。

２．画像に解像度が設定されるタイミング
画像の解像度の決まるタイミングはブラウザのような画像解像度を無視するアプリによって画像ストリームとしてファイルに保存される瞬間です。
ほとんどの場合は使っているディスプレイの解像度がその画像に設定されます。

以下のリンクを右クリックから「対象をファイルに保存」でPCへ保存してください。
http://myugaru.wankuma.com/image/20080309_50.bmp
この場合は画像ではなく単にファイルとして保存されるので本来の画像に設定された解像度が維持されます。
保存した画像ファイルをExplorer上で右クリックしてプロパティを確認してみてください。
この画像が解像度50dpiで作成されているのだというのが確認できます。

次に先ほどの女の子の画像上を右クリックして「名前を付けて画像を保存」でPCへ保存してみてください。
お使いのディスプレイに合わせてその解像度が設定されるかと思います。
先ほど同様に保存した画像ファイルのプロパティを確認してみてください。
（ブラウザによっては50dpiのままのものもあるかもしれません。IEはディスプレイ解像度に変わりました）

※ディスプレイ解像度はコントロールパネルの画面などから確認ができます。

２．物理サイズでの等倍
物理サイズというのは画像のインチ数でのサイズの事を指します。

上の確認プログラムの動作はこの物理サイズを等倍とするプログラムになっています。

先ほどの女の子の画像の論理サイズ（ピクセルサイズ）は横150×縦290です。

物理サイズ横＝150÷50＝3インチ
物理サイズ縦＝290÷50＝5.8インチ

の画像だといえます。

それを96dpiのディスプレイに物理サイズで等倍表示するとどういう事が起こるかというと、

横ピクセル＝3×96＝288
縦ピクセル＝5.8×96＝556.8

つまりディスプレイ上で288×556ピクセルで表示される事を意味します。
これは論理サイズでは拡大表示となります。

~~物理サイズでの等倍のシンプルな確認方法はディスプレイ~~解像度を変えてみる事です。
試しにディスプレイを1024×768や800×600などに変えてみてください。
物理サイズでの等倍を行うプログラムではその見た目のサイズは変わりません。

ディスプレイの能力によって96dpiが決まるので1024×768を800×600にする行為はこの能力の変更には直結していません。したがってこの場合見た目のサイズも変わってしまうという結果になります。確認が不足しておりました。すみません。

３．論理サイズでの等倍
論理サイズというのは画像のピクセル数でのサイズの事を指します。
ブラウザの動作は論理サイズを等倍とするプログラムになっています。
DrawImageのサイズ指定バージョンは画像の解像度を無視しディスプレイ解像度で表示することを意味しています。
DrawImage(image,0,0,image.Width,image.Height)は論理サイズでの等倍に利用できます。（可能な人は先ほどのプログラムを修正して確認してください）
論理サイズでの等倍の場合はディスプレイ解像度で表示されるわけですから、当然ディスプレイの解像度を1024×768や800×600に変えるとその物理サイズであるインチ数でのサイズは変わる事になります。これは前述の通り論理サイズ等倍だけの話ではありませんでした。すみません。
先の画像のように意図的に50dpiを設定している画像だったなら50dpiのディスプレイというのは見かけませんので、ほとんどの場合は製作者の意図したサイズで表示されていないという事を意味しています。この意味は多少あっていると思われます。

●対策
１．画像の解像度を変更する方法
残念ながら通常のWindows付属ペイントだとこれは出来ません。
画像解像度を簡単に変えることが出来るフリーのペイントツールがあります。
http://www.getpaint.net/
以下のように解像度のみ修正できます。
・[イメージ]→[キャンバスサイズ]の解像度の数値をかえる

２．とりあえず論理サイズの方が一般的？
一般に普及しているブラウザやペイントツールの動作を見てもディスプレイへの表示時はほとんどが画像の解像度を無視しているようです。
なので画像を単純にブラウジングするような場合にはDrawImage(image,0,0,image.Width,image.Height)とサイズ指定して論理サイズ等倍を意識したつくりにする方が良いように思います。

あまり需要は無いのかもですが、何かのプログラムでディスプレイ解像度に依存しない（つまり物理サイズが必要な）局面が出てきた場合にはこのエントリーの事を思い出して欲しいと思います。

物理サイズ等倍というのは見た目での等倍実現に寄与していないようです。現在のディスプレイの能力に見合ったサイズとしてそのサイズを表現するという意味合いで使われているように思います。不確かな記述をしてしまい申し訳ありませんでした。

最後に・・・ここまで書いてからふっと見ると・・・ほとんどここに書いてました。ヘルプも空気も嫁てません。。→http://msdn2.microsoft.com/ja-jp/library/558kfzex(VS.80).aspx
・・・開き直って私なりにまとめたのはこれで良しとしときます。