情報集合論(仮名) 無限の構造を考える
//無限
type Infinity( name, seed, next ) =
member this.Name with get() = name
member this.Seed with get() = seed
member this.Next with get() = next
override this.ToString() =
this.Name + "の" +
"開始値は" + this.Seed.ToString() +
"、次の数は" + this.Next( this.Seed ).ToString()
[<EntryPoint>]
let main argv =
//数
let seed = 0
let next x = x + 1
let number = Infinity( "数", seed, next )
printfn "%s" <| number.ToString()
//自然数
let seedN = next 0
let n = Infinity( "自然数", seedN, next )
printfn "%s" <| n.ToString()
//終了
0
無限構造には無限に要素を生成するための根源(種)と、要素を生成する関数が必要となります。無限構造はこの2つを分析すればその性質がわかります。さて、既存の濃度の定義「1対1で対応」は何がいけなかったのでしょうか?この点について考察しておかないと同じ罠にはまるおそれがあります。その結果に違和感がありますが、定義そのものは至極まっとうです。私が思うに、自然数目線だけで対応を考えていた点が不便さの元だと思います。自然数から整数を見ると1対1対応にできます。しかしながら、整数から自然数を見た場合、全射ですが単車ではありません。すなわち、負数と正数の2つが自然数の1つの要素に対応付けられてしまいます。これにより、情報の喪失が発生します。数学では問題がないのかもしれませんが、情報技術的には大問題です。
次に偶数と自然数の関係について考察します。数学の濃度の定義によると、これもまた同じ濃度となりますが、同種の問題が生じます。自然数から見た場合、半分の要素に対応がありません。無理やり対応付けすることができますが、そうすると全単射でなくなります。この件もまた情報の喪失が生じるのです。この件に関する教訓は、親集合からの対応も考えようだと思います。
これらの問題で厄介なのは、有限区間内では変換関数で誤魔化せることです。誤魔化せるならば同じ濃度で問題がないと考える人も居るでしょうが、変換関数を定義できるのと、その情報の性質そのものを同一視すると問題です。何故ならば、変換関数を通すという1プロセスが余分に付加されているからです。1プロセス余分に必要な情報と、余分なプロセスがない情報を同一視するのは危険です。また、変換された時点でその情報の変質が変わってしまいます。性質が変わってしまった情報を分析すると間違いが生じます。
変換関数はそれ単独で分析するのに値するものです。決して無限構造内に埋もれさせてはなりません。何故ならば、変換関数はいくらでも考えられるからです。その中から1つを、無限構造の一部として特別視するのは無理があります。変換関数を独立して考える方が有意義な理論体系となります。