初心者のためのC#プログラミング本格入門105 - 関係オブジェクトの変更を検知しよう

　この記事は、初心者のためのC#プログラミング本格入門104の続きです。前回は、複数のオブジェクトの関係を意識したプログラミングを解説しました。今回は、関係を持つオブジェクトが変更されたことを知る手段について解説します。
　前回解説した問題は、関係を持つオブジェクトが変更された時に発生します。2つのオブジェクトが関係している場合、どちらか一方が変更されてしまうと整合性が取れなくなります。この問題を解決する方法は、変更されたことを知る仕組みを仕込む所から始まります。
　変更されたことを知る方法は様々ですが、一番簡単な方法は変更回数の記録です。管理する要素が追加された時と削除された時に、用意した変数をインクリメントすれば変更回数を記録できます。記録できれば後はエラーを知らせるだけです。エラーの通知方法はまだ解説していないので、更新回数を記録するプログラムをサンプルに追加します。

partial class SimpleList 
{
    //関係のないプログラムは省略
    private int updateCount; //更新回数
    
    public SimpleList()
    {
        this.updateCount = 0;
    }
    
    public void Add( int value )
    {
        ++this.updateCount;
    }
    
    public void Remove()
    {
        ++this.updateCount;
    }
}

private class Enumerator :
    System.Collections.Generic.IEnumerable<int>,
    System.Collections.Generic.IEnumerator<int>
{
    private SimpleList owner;
    private int initCount;

    public Enumerator( SimpleList owner )
    {
        this.owner = owner;
        this.initCount = owner.updateCount;
    }

    public System.Collections.Generic.IEnumerator GetEnumerator()
    {
        return ( System.Collections.Generic.IEnumerator<int> ) this;
    }

    System.Collections.IEnumerator
        System.Collections.IEnumerable.GetEnumerator()
    {
        return ( System.Collections.IEnumerator ) this;
    }

    public int Current
    {
        get { return this.data[ this.readIndex ]; }
    }

    public bool MoveNext()
    {
        if ( this.initCount != this.owner.updateCount ) {
            //問題あり！
            System.Console.WriteLine( "取得後に変更されました。" );
        }
        ++this.readIndex;
        return this.data.Length > this.readIndex;
    }
}

やっていることは簡単です。変更された回数の記録を取って、要素を取得するメソッドでエラーチェックをしているだけです。
　ここまでは問題ないと思います。問題なのはプログラマーにエラーを通知する方法です。コンソール画面に出力すると決めてしまうと、CUIでないアプリケーションでこのオブジェクトを使用した際に、問題が発生した事が伝わりません。例えば、WPFアプリケーションを作っている時に、コンソールにエラーを表示されても、普通はコンソール画面を見ていません。アプリケーションの種類に関係なく、エラーを通知する方法が必要です。続く...

情報集合論（仮名） 研究の目的は小さくまとまらない

　情報集合論の目的や動機をメモっておくと便利だと思い、メモを取ることにしました。きっかけは、カントールの理論が面白いという事でした。カントールが考える事は最高にいかしています。ただ問題なのは、集合論のパラドックスをどうやって解決するかという点です。カントールがもう少し長生きしていれば、もしくは精神にダメージを受けなければ、パラドックスは解決し、集合論は完成したでしょう。カントールは自身の理論を信じていましたし、私も直観的に正しいと考えています。その超天才の遺産をどのようにして生かすのかが課題になります。
　パラドックスの解決といえば、公理的集合論というものがあるのですが、ちょっと調べたら私の性に合いませんでした。なんだか逃げている気がします。集合全体の集合を考えず、ラッセルの集合にも向き合わず、小さな集合だけを考えていこう、そのための基準をひいてしまおうという「既存数学内で小さくまとまるための理論」に思えてなりません。要するに肌が合わないのです。
　私の仕事は矛盾がデフォルトです。数学的に完結できる事なんて範囲が狭いです。お客様が向き合っている矛盾を、真っ向から解決することが私の仕事なので、小さく現状維持は本当の解決方法になりません。遊びとはいえ、そういった負け癖のようなもの（小さな範囲に思考する）は身についたら困ります。公理的集合論は、数学的に意味があるとは思いますが、私の仕事は情報なのであって、数学の範囲内で収まるというのは無理なのです。
　集合論のパラドックスに真っ向から向き合うということは、「集合とは何か」という本質を考える行為に他なりません。それは集合だけを見つめていては解決しないというのが直観で感じ取りました。集合外から集合を見ることにより、初めて集合の芯の性質がわかります。内から見ていても何もわかりません。外から分析しないと物事は本当の意味で解決しません。
　集合全体の集合を考えたとき、集合でない集合とそれらを包含する超集合が見えてきます。集合全体の集合のべき集合とは、超集合と集合全体の集合の間に位置するものだといえます。さらに言えば、べき集合が算出できない集合があると思います。何故ならば、べき演算も満たすべき性質があると考えるからです。物事は何事も満たすべき仕様があります。その仕様を考えていないと、そこから矛盾が生じます。仕様のバグのようなものでしょうか。
　仕様のバグを直すには、柔軟かつ変化に対処できる理論が必要です。その術を編み出すのが情報集合論の目的です。何事も小さくまとまらず、より巨視的な観点から物事を解決しなければなりません。死んでもその信念を曲げるつもりはありません。信念を曲げるということは、精神的な死を迎えたのと同じだからです。

オブジェクト指向の本質

　オブジェクト指向といえば、情報の隠蔽、継承、多態性が有名です。この言葉を知っている人は多いと思います。しかしながら、この3つの言葉の意味を本当の意味で理解している人が少ないと思います。そこで今回はオブジェクト指向の本質について書くことにしました。
　初めに言っておかねばならないことは、オブジェクト指向とは分析（OOA）・設計（OOD）・実装（OOP）の3つの事を考えねばならないという点です。オブジェクト指向はソフトウェア工学のあらゆる領域にまで発展しており、この3つのOOXがあることを念頭に置かねば足りません。さらに、OOA/OOD/OOP（OOX）はいくつも亜流があります。
　提唱者は同時に定義することが多いので、OOAとOODは大概手法が重なっています。それら方法論の中で有名なのは、リカーシブ開発、Booch手法、Coad/Yourdon手法、Texel手法、OMT、SOMA手法、OOSD、OOSE、MERODE手法、SSADMです。私は一応、これら手法に目を通しました。これら方法論の違いは、開発で起こる現象をどのようにしてとらえるのかという点にあります。共通点は分析・設計・実装の流れをスムーズにすることです。オブジェクト指向よりも前に使われていた構造化設計法は、この視点が不足していました。誤解されやすいのですが、オブジェクト指向方法論は、構造化設計技法の知識を前提としています。構造化設計技法を知らないと真に理解できません。また、実際にシステム開発をするときはアジャイル開発の手法とセットで使います。オブジェクト指向方法論は閉じたものではないのです。
　OOPにおいても、特定の言語だけのものではありません。よく見られる間違いは、C++などの特定言語のOOPに思考が縛られる事です。OOPを真に理解するには、少なくとも命令型、関数型、論理型、集合型、宣言型、の各種言語に触れる必要がありますし、さらに静的な型と動的な型によるOOPを経験せねばなりません。これらのOOPを経験して分かったことは、状態と抽象化と制御がOOPの核だといえるということです。
　オブジェクト指向を言語モデルとして考えたとき、キーとなるのは状態の変化です。OOPをする時点で、状態の変化が伴います。何故ならばOOPは、状態ありの計算モデルだからです。
　状態をどのようにして扱うのかという点で、OOPは役立ちます。モジュール性はOOPでなくともありますが、OOPはそれをさらに進めて、ある程度統一した方法でデータの抽象化とプロセスの抽象化を統一化します。さらに、情報の隠蔽の考えを適用し、スコープの範囲を制御します。これにより、変化に強いプログラミングが可能となります。
　もうお分かりになったと思いますが、情報の隠蔽・継承・多態性の3原則は、変化に対処するための概念です。すなわち、あらゆる変化をいかにして扱うのかというのがテーマであり、オブジェクト指向の本質なのです。情報の隠蔽により変化がもたらす影響範囲を狭め、継承により拡張性をもたらし、多態性によりバリエーションと統一性を実現します。
　オブジェクト指向の本質は変化への対処です。オブジェクト指向にある多種多様な概念に触れ、変化に対処する術を学びましょう。そうすれば、きっと優れた開発者になれるでしょう。

情報集合論（仮名） 基本定義

　この記事は自分用のメモです。情報集合論において、最も基本となるのは情報です。この理論における情報の定義とは、人間の脳が処理できるもの全てです。人間脳が処理できるとは、感じる、考える、書ける、といった全ての脳を使う行為を指しています。従って、幽霊のような存在すら不明なものであっても、幽霊という情報がある以上、情報としては存在しているとみなします。情報として人間が認識できないものについては、残念ながら情報集合論で扱えません。というよりも、人間が認識すらできない時点で、対象として扱いたくてもできません。
　ということは、情報以外という定義もあり得ることになります。この点については、人間の能力は有限であり、常に人間が理解できないものは存在すると考えたほうが自然なので、解釈の余地を残しています。ただ人間が認識できないということは、記号すら考えられず、考えるという行為すら思いつかない対象なので、どう扱っていいのかについては範囲外です。
　ではどうやって、情報以外という定義を有効利用するのかといいますと、新しい情報が見いだされたときに使用します。以前は情報ではなかった（人間が知らなかった）が、今は認識できたのでこれからは情報とみなすというふうに、情報の履歴を表現するために使用します。
　情報の基本原理は、判定（フィルター）と変換です。情報として認識したということは、その情報だと区別する何らかの判断材料があるはずです。なければそもそも認識できていないので考える行為すらできません。判定もしくは区別できる情報は、その情報だとみなしてもよいので、自然と変換も伴います。従って、判定と変換はセットだとみなせます。もちろんこの定義には実用的な観点もあります。プログラミングを例にとると、数値オブジェクトだとわかっているのにもかかわらず、常にobject型のオブジェクトとして処理するのは無駄です。また、人間の思考能力は有限なので、すでに分かっている部分については省略して考える必要があります。すなわち、情報を細切れにして人間が考えられる粒度に落とし込むための取決めなのです。
　情報は常に流動的である点にも注意が必要です。日々新しい情報が生み出されていることを考慮すると、静的な公理などを作る時点で間違いだといえます。従って、全ての情報には親（前提）が必要です。親（前提）がない情報は、最小粒度の情報もしくは、前提を考慮しない情報です。
　情報集合論プログラミングをするときは、ある程度性質がわかった情報は型としてみなし、処理を短縮化することを検討します。この時の型とは、群・環・体のような抽象型や、幾何学的なもの、位相空間、などといったものとイメージが近いです。型とは人間のパターン認識処理そのものなのです。
　最後に忘れてならないのは、情報は必ず名前を持つことです。情報を特定できない状態では分析できません。命名できるまで情報の粒度を操作しながら分析する必要があります。命名の大切さはよく知られています。名前は忘れてはならない重要な定義です。

情報集合論（仮名） ラッセルのパラドックスについての考察と情報集合プログラミングの原理

　私が新しく考えた情報集合論（仮名）は、ラッセルのパラドックスの扱い方が重要になると思ったので、ラッセルのパラドックスについてメモを取ることにしました。
　書くのが面倒なのでさらりと書いていましたが、ラッセルのパラドックスは深い意味を含んでいます。何かを否定する（x以外）の集合は、何の要素をむのかという問題です。具体的に考えるために、1から10の範囲を考察します。１～10の数値集合に対して1でない場合、要素は2～10です。2でない場合の要素は１と3～10です。以下のようにして全ての否定演算を集めた集合は何を要素とするのでしょうか？1以外の数値集合、2以外の数値集合・・・をすべて集めた場合1～10の数値がすべてそろうこととなり仮定と矛盾しています。ラッセルのパラドックスが我々になげかけているのは「属する」とは何かという深遠な謎です。
　解決不可能なように見えますが、情報集合論においてはパラドックスになりません。何故ならば、素朴集合論では当たり前のように備えていた非等価演算（属さない）も一つの集合とみなすからです。すなわち、１～10の数値といった要素に注目するのではなく、1以外、2以外、という非等価演算の集合とみなすからです。こうすれば、{ x ∉ x }という集合も非等価演算の要素となります。従ってパラドックスになりません。
　素朴集合論の問題は、いきなり論理演算を備えていると仮定している点にあります。この仮定を取り払い、薄皮を重ね合わせるように定義していけば、何ら矛盾は生じません。また、言葉に頼っている点にも問題がありました。人間の言葉は曖昧なので、集合の集合といった言葉に惑わされますが、情報集合論では情報のフィルターと変換をもとにしているので、言葉に頼らず集合の集合のべき集合も普通に定義できます。何故ならば、べき演算も定義されていない集合も視野に入れるからです。そうしていけば、最終的にべき演算を持たない集合に突き当たるので無限再帰になりません。集合の集合の集合は・・・などといった言葉遊びに悩まされずに済むのです。
　情報集合論において何かの集合の部分集合とは、「対応が矛盾しないように並べた結果」なのであって、ただフィルターと変換の規則を並べていくだけで出来上がります。なおかつ、静的な公理群ではなく、動的な関係の構築作業なのでパラドックスが生じにくいです。パラドックスが生じたときは、並び方が間違っているだけなのです。

中の人の徒然草440

もうすっかり寒くなったので、炬燵に入って本を読む時間が増えました。実はその際に妹に気味悪がられます。
私は心の底から情報技術を愛しています。そして、学問も面白いと感じています。それ故か専門書を読んでいると、自然と笑みがこぼれます。時には声に出して笑うこともあります。その光景が妹にとっては理解できないそうです。ここ最近では・・・

私「くっくっくっ。」
妹「何？何が面白いの？」
私「この本なんだけど、くっくっ・・・」
妹「そんなに面白い本読んでいるの？...げぇなにこれ？数学の本じゃないの。」
私「いやぁ、集合論のパラドックスが面白すぎる。カントールはいかしているよ。」
妹「パラドック？なにそれ。」
私「パラドックスというのは矛盾の事なんだ。」
妹「矛盾の何が面白いの？」
私「矛盾の出し方が最高にいかしているんだ。
　全ての集合の集合を定義した時、べき集合の濃度が集合の集合を超えるという矛盾を、
　発明者のカントール自身が言っているんだ。」
妹「集合の集合？集合ってなに？」
私「物事の集まりの事なんだ。例えば..そうだな。
　クリスマスに人が集まっているだろ？あれも集合だ。」
妹「クリスマスってなんでカップルが多いんだろう！
　あれを見るとなんか腹立ってくるなー。」
私「恋人がほしかったら、まずは炬燵から出ようよ。
　それはさておき、そういった集合という概念自体の集合を考えたらどうなるだろう？」
妹「ええっと、腹が立つカップルの集まり、
　ケーキの集まり、女子会の集まり、職場の集まりとか？」
私「そう。それらの集まりそのものの性質を考えたら面白いと思わない？」
妹「うーん、面白いかな・・・そうだ、お菓子の集合を調べたら、
　もっと美味しい食べ方ができるかも！」
私「それいいな。まず全てのお菓子を考えてみよう。」
妹「ポテチ、ポッキー、カール、チョコレート、ケーキ、ドーナッツ、それから・・・」
私「きりがないからストップ！
　そうしたおかし集合の個数を考えたとき、難しいことが起こるんだ。」
妹「そうだね。どれを食べていいかわからないし、数えるだけで大変。」
私「でも、苦労して誰かがお菓子の数を調査したとしよう。」
妹「私そんな仕事したいなー。そんな仕事ないかな？」
私「ここで問題です。例えば、調査後に誰かが、
　チョコレートを加工して、チョコカールを作ったとしよう。」
妹「それ、おいしそう！」
私「そうすると、先ほど発表したお菓子の数と一致しない。さぁ大変だ。」
妹「それって、モンスタークレーマーだよね！そんなの無理じゃん。」
私「そう、集合論のパラドックスはそういう事なんだ。
　集合の一部の組み合わせを考えたりしたとき、
　元の集合の数を超えてしまうこともあるんだ。」
妹「それの何が問題なの？お菓子たくさんあった方がいいじゃん。」
私「調査した人にとっては問題だろ？上司から怒られるよ。」
妹「う～ん、やっぱりおいしいだけの仕事はないみたいだね。
　上司から「先日100個って言ったけど、
　　お客様から足りないとクレームが来たぞ。」ってな感じ？
　私ならお兄ちゃんに愚痴いうよ。」
私「そう。いつも職場の愚痴を聞いているよ。
　そんな具合で、不変の真理を考える数学では、数すら決まらないことが問題になるんだ。
　だって、いい加減だと困るだろ？」
妹「何も信じられないなんて不便かも。でも気にしない方が楽しく生きられるよっ♪」
私「確かに○○はいつも楽しそうだ。どう？面白いだろ？」
妹「う～～～ん、そんなこと考えているよりも、
　おコタでTVを見ながらお菓子を食べたほうが楽しいよ♪」
私「そうか。。。」

大体こんな感じです。専門書も漫画も情報に変わりないから、面白いと思いますが、誰にも理解されません。
専門書もちゃんと読めば面白いと思うんだけどな・・・

書籍をつつく150 - 集合・位相入門。集合論を堪能しよう。

　私が集合論にはまるきっかけを与えてくれたのがこの本です。



数学というと、酷い教育のせいで面白くないものだと思われています。しかし本当の数学は面白いです。私は休日にこの本を読んで、有意義な時間を過ごしました。しかもただ面白いだけではなくて、私はこの本を読んで新しいプログラミングスタイルまで思いつきました。集合論は知的な刺激を与えてくれます。
　集合論で遊んで技術力をアップさせよう♪集合理論は人生に潤いをもたらしてくると思います。技術者をやっている人は、この手のものも好きだと思います。ご堪能あれ。

VBオブジェクト指向プログラミング講座 第16回 継承の背景を知ろう

　この記事は、第15回　継承の原理を覚えようの続きです。前回は、継承の原理について解説しました。今回は、継承を使いこなすためにおぼえておくべき事柄を解説します。
　継承を使いこなすには、継承が生まれた背景や目的を知らねばなりません。継承はそもそも何をするものなのでしょうか？それは、前回に述べたように、「同じことを何度も書かない」を実現するためのものです。しかしながら、実現はかなり難しいです。何故ならば、機械を相手に察しろというのは土台無理な話だからです。
　機械はバイナリ（0と1）を解釈しながら動いています。ですから、Methodという名前のメソッドが何度も定義されていてもわかりません。機械よりも上位層であるVBコンパイラのレベルで考えても、ただの文字の羅列にすぎません。それを同じだと伝える方法のうちの1つが継承です。
　継承について知る前に、継承の対象であるメソッドとは何かを知らねばなりません。メソッドを一言でいうと、データを暗黙で渡す手続きもしくは関数です。サンプルを見ればよくわかると思います。

Class Foo
    Public Property Name As String
    Public Sub Print()
        Console.WriteLine(Me.Name)
    End Sub
End Class

Module MethodSample

    'FooのPrintメソッドと同様の手続き
    Public Sub Print(ByVal obj As Foo)
        Console.WriteLine(obj.Name)
    End Sub

    Sub Main()
        Dim obj As New Foo
        obj.Name = "ピヨ"

        'どちらも結果は同じ
        Print(obj)
        obj.Print()

    End Sub

End Module

Meキーワードの部分に注目してください。これが暗黙的に渡されているデータです。これで、先ほど言ったことが実感できたと思います。
　手続き・関数・データを、メソッドという一つの概念にまとめました。これで人が管理をしやすくなりました。次にするべきことは、定義したメソッドの再利用です。

Class Foo
    Public Property Name As String
    Public Sub Print()
        Console.WriteLine(Me.Name)
    End Sub
End Class

'同じメソッドを使う
Class FooFoo
    Inherits Foo
    '他のメソッドも定義している・・・
End Class

Module MethodSample

    'FooのPrintメソッドと同様の手続き
    Public Sub Print(ByVal obj As Foo)
        Console.WriteLine(obj.Name)
    End Sub

    'FooFooのPrintメソッドと同様の手続き
    Public Sub Print(ByVal obj As FooFoo)
        Console.WriteLine(obj.Name)
    End Sub

    Sub Main()
        Dim obj As New FooFoo
        obj.Name = "ピヨ"

        'どちらも結果は同じ
        Print(obj)
        obj.Print()

    End Sub

End Module

このサンプルが示したように、継承という概念を定めておくとメソッドの再利用ができます。ちなみに、モジュール内のFooFoo用の手続きは定義する必要がありません。しかしながら、これが動くのもVBがオブジェクト指向プログラミング言語であるからであって、非オブジェクト指向言語では、名前を変えて改めて定義する必要があるのであえて示しています。
　今回の記事を読んで、「なんだ継承って簡単じゃないか」と思われた方もいるかと思います。しかし、ここからが恐怖の始まりです。お楽しみに。

情報集合論（仮名） 基本イメージ

　素朴集合論を拡張し、情報技術に生かすためにメモを取ることにしました。情報集合プログラミングは、大体こんな風になります。

type Set<'a, 'b, 'c>
  (
    name,
    f : 'a -> bool, 
    m : 'a -> 'b,
    parentGetDataFunc : ( List<'c> -> List<'a> ) option 
  ) =
  //フィールド
  let _name = name
  let _filter = f
  let _map = m
  let mutable parentFunc = parentGetDataFunc
  //プロパティ
  member this.Name with get() = _name
  member private this.Filter with get() = _filter
  member private this.Map with get() = _map
  member private this.PrentFunc with get() = parentFunc
  //親を考慮してデータを取得する
  member this.GetData( data : List<'c> ) : List<'b> =
    let newData = this.PrentFunc.Value( data )
    this.GetData( newData )
  //親を考慮しないでデータを取得する
  member this.GetData( data : List<'a> ) : List<'b> =
    data
    |> List.filter this.Filter
    |> List.map this.Map

[<EntryPoint>]
let main argv = 

    //テストデータを準備
    let source =
     [ 
      yield "実験データ" 
      for i in 0..10 -> i.ToString()
      for i in -10..-1 -> i.ToString()
      yield "終了"
     ]
    printfn "元のデータ"
    List.iter <| printf "%A " <| source
    printfn "\n"

    //数値
    let numberFilter = 
        fun x -> 
          let a = ref 0
          System.Int32.TryParse( x, a )
    let numberMap = fun x -> System.Int32.Parse( x )
    let numberSet = 
      new Set<string, int, obj>( 
        "数値", numberFilter, numberMap, None )
    let numberFunc = 
      ( fun ( x : List<string> ) -> numberSet.GetData( x ) ) 
    let data = numberFunc source
    printfn "%s" numberSet.Name
    List.iter <| printf "%A " <| data
    printfn "\n"
    
    //自然数
    let naturalSet = 
      new Set<int, int, string>( 
        "自然数", ( fun x -> x > 0 ), 
        ( fun x -> x ), Some( numberFunc ) )
    let naturalFunc =
      fun ( x : List<string> ) -> naturalSet.GetData( x )
    printfn "%s" naturalSet.Name 
    List.iter <| printf "%A " <| naturalSet.GetData( source )
    printfn "\n"

    //偶数を取得
    let evensSet = 
      new Set<int, int, string>( 
        "偶数", 
        ( fun x -> x % 2 = 0 ), 
        ( fun x -> x ), Some( naturalFunc ) )
    let evensFunc = 
      ( fun ( x : List<string> ) -> evensSet.GetData( x ) )
    printfn "%s" evensSet.Name
    List.iter <| printf "%A " <| evensSet.GetData( source )
    printfn "\n"

    //終了
    0

勿論これは基本中の基本であり、論理プログラミングのように規則や事実を記述していく形をとります。ただし、論理プログラミングと同じではないので、型や関数プログラミングの機能をフル活用して、より簡潔に公理や定理を記述していく形になります。
　私が持つ集合の基本イメージは性質と対応です。無限の要素をすべて分析することは人間には不可能ですが、要素をある視点で集め性質をとらえると分析できます。素朴集合論のパラドックスは、いきなり言葉の全体像をとらえようとしたのが原因だと思います。私がサンプルで示したように、薄皮一枚を重ねるように、ルールを動的に重ねていけば矛盾が生じません。
　例えば、ラッセルのパラドックスは、R ∊ { x | x ∉ x } の集合における要素の所属を問題としています。しかしこのパラドックスは、集合に要素があると要素の視点で見るから真偽どちらをとっても矛盾が生じるのです。集合＝規則だと考えると、全てにおいて偽を返す対応に他なりません。要素云々ではなく、何も通さないフィルターだと考えれば合点がいきます。
　つまり、私が考える集合とは、何かの物質や概念を直接含むものではなく、規則そのものであり、フィルターのような存在なのです。ただし、ただのフィルターではなく、一定規則で対象を変換するものでもあります。何故ならば、集合を性質の境界線ともいえるからです。境界線を越えた要素（性質を満たす要素）は、その性質を持つオブジェクトだと考えると分析しやすいです。
　ちなみに、「所属する」云々も一つの集合だと考えています。一般でいうところの所属は、元となる集合の量と、ある集合を通した後の量が同一（割合が100％）ならばtrueという空集合を返すとみなします。こうしておけば、ファジイ集合論にも対応できます。あと、私の考えでは濃度も集合に他なりません。濃度集合は、集合と範囲を表わす集合を渡すと、ある区間における個数が返される集合です。全てを集合とみなすのです。
　今回紹介したサンプルは、素朴集合論における集合ではありません。素朴集合論ではいきなり集合が登場していますが、情報技術としてとらえたとき定義が不足しています。素朴集合論の集合といえるオブジェクトを定義するには、段階を踏まなければなりません。何故ならば、集合演算や「属する」などといった概念がいきなり登場しているからです。飛躍するとパラドックスが生じます。
　プログラミングでたとえると、関数をひとつずつ追加していく感じです。関数の集合が型なので、この考え方のほうが情報技術的には都合がよいのです。

中の人の徒然草439

うぅ寒い。手がかじかむ日々を送っているインドリです。そこで、寒さ対策として、指の部分がない手袋をしてキーボードを打っています。これで少しはましになりました。
ここ最近思ったことといえば選挙です。どの党に投票したらいいのかと思い調べたのですが、どの政党もマニフェストが不十分です。というのも、民主党はマニフェストと正反対の政治をしたからです。その件がきっかけで、マニフェストというもの自体に何ら信頼性がない状態になっています。それにもかかわらず、マニフェストに違反したら罰則になるなどといった、信頼に関する立法をする気がある政党が見当たりません。もしかしたら私が見落としているだけかもしれませんが、国民としては信頼できる根拠がほしいところです。信頼する根拠もなく信じてほしいといわれて、信じられるほど私はお人よしではありません。そうした、自らを律する政党が見当たらないため、日本の国家システムはMS-DOSレベルのままになるだろうと予想しています。国家システムをバージョンアップする気がある政党が見当たりません。まことに残念なことです。国家システムさえバージョンアップすれば、日本は自然と世界一になるのに残念です。システム思考ができる政治家が現れるまでに日本が存続することを祈るばかりです。・・・う～ん、無理っぽい。そんな猶予があるとは思えませんが、この件に関しても「想定外でした」になるのでしょう。嘆かわしいことです。
それはさておき、やはり私が日頃考える事といえば情報技術です。最近は数学にもはまっており、化学と科学もちょっとだけしています。科学と化学は情報技術と関係がないと思われがちですが、そうでもありません。情報は全てにおいて存在するものであり、科学者や化学者の考えは参考になります。偉人の考えを分析すると、きれいな情報の流れが見えます。その思考法は大変参考になります。ましてや、数学に関してはかなり参考になります。
実は数学と情報技術はお隣さんぐらいの関係です。集合論を拡張すれば、情報技術にもすぐに応用できます。素朴集合論をそのまま使うのは無理ですが、情報技術用に拡張すればかなり使えそうです。公理的集合論についてはあまりよく知らない（興味がない）のですが、ぱっと見、制限が多すぎて情報技術に使いにくいです。私としては、プログラミングはもちろんの事、全行程で使える思考ツールがほしいので、数学用に限定されたものは除外して考えています。
素朴集合論のすごいところは、制約がほとんどない点です。それゆえにパラドックスが生じるといわれていますが、私としてはパラドックスはないと思います。その点については既に日記で書いたので省略します。仕事の合間に、集合論を拡張したものでプログラミングして遊んでいます。実に面白いです。もっと遊びたいのですが、なにぶん年末なので忙しいです。ごちゃごちゃしているのでお見せできませんが、整理したらブログに掲載しようと思っています。
この情報集合プログラミング（仮名）は、論理プログラミングとちょっと似ており、制約を記述しながらプログラミングします。でも数学が母体なので、やはり主となるのは関数型プログラミングです。F#と相性がよさそうです。といっても、既存のプログラミングパラダイムに当てはまらないものになると思います。集合指向のSQLとも近いですが、でもちょっと違うし、何のパラダイムに該当するかわかりません。今のところ、論理型＋集合型＋関数型＋手続き型＋オブジェクト指向型です。さらに既存の方法論にも適用できます。分析と設計にもこの考えを適用すれば、新しい開発スタイルが開けると思います。
もっと時間があればこの情報集合理論を構築するのに。遊ぶ時間がほしいなー。