数理概念のソフトウェアモデル化

投稿者

投稿内容

Gio: ぬし; 会議室デビュー日: 2003/11/28; 投稿数: 350; お住まい・勤務地: 都内から横浜の間に少量発生中

投稿日時: 2005-03-18 20:10

equals さんの問題意識がどこにあるのかはっきりわからないのは私も同じですが、有限集合の延長として無限集合を考えると破綻します。

まず一般の集合 Set は以下のようになると思います。
ここで Ordinal は順序数型（らぶまさんが書かれた最後の段落を反映しています）、要素の型を Element としています。
（実装可能性は無視しています）

コード:

public interface Set {
Ordinal order(); // 集合の大きさを返す。実数全体の集合ならばアレフ1、Hilbert 空間ならばアレフ2?）
boolean equals(Set s); // 集合の一致を表す。
Set union(Set s); // 和集合を返す。
Set conjunction(Set s); // 共通部分を返す。
boolean contains(Element e); // 要素の包含を表す。
boolean contains(Set s); // 集合の包含を表す。
// separated 等は union, conjunction, contains の組み合わせで書けるので略。
}

これを基にして有限集合を表したものを次に挙げます。

コード:
public interface FiniteSet extends Set { Enumeration elements(); }

素朴集合論を用いても Zermelo-Fraenkel(-Cantor) 集合論であっても、何を表現すべきかが明確であればモデル化は可能でしょう。

equals: 会議室デビュー日: 2005/02/23; 投稿数: 13

投稿日時: 2005-03-22 06:35

らぶまさん

ご指摘の通り、集合の概念を無限集合まで広げると濃度の概念の定義が必要になりますね。Gioさんが示されたOrdinal order()メソッドのように、int size()の形ではなく、アレフ型を定義するのがより明確だと思います。
集合の濃度の定義、すっかり忘れ去っていて、いまさらながらネットで調べなおしました(^^

コモンセンスさん、Gioさん

問題意識を事前に示しておらず、なぞかけみたいになったところがあり、申し訳ありません。大上段に問題意識から入ってレスなしになるのも怖かったので。

私の問題意識は、以下のようなものです。

・集合をはじめ、数理概念の「コモンセンス」としてのインターフェース実装は解決済みでない。
→私の問いかけに対して、「ここにこのような一般的な実装がありますよ、よく調べてから発言されてはいかがでしょうか」的なレスがあるような状態を私は「解決済み」と解釈しています。

・java.util.*やorg.apache.commons.collection.*のようなライブラリは、実用を重視したが故に、粒度が荒く、抽象度の高いレイヤーが未定義である。特に数学上の概念については未整備。といっても、では一体誰がどのように整備するのか？されていくのか？
されることにメリットがあるのか？（これはまあ「いらん」といわれてしまえば一言で終わるので、「意味がある」という前提で以降を進めます。）

・抽象度の高い（かなり）厳密で一意な数理モデルの実装がなされたとして、それを実用的なレイヤーで生かすためには、種々の応用法が整備される必要がある。（例えば集合の「濃度」を定義したものの、どう使うと有用なのか、ということです）
机上の研究ではなく、実メリットを出すために、優先度の高い部分はどこか？何から着手すべきか？

集合の例は、上記問題意識につなげる例として提示しました。

GioさんのSetとFinitesetの定義は、この場の議論におけるSet定義の最新バージョンですね。
この定義についての各論の議論は時間不足なので次レスをお待ちください。

引用:

コモンセンスさんの書き込み (2005-03-18 17:53) より:
コモンセンスです。

equalsさんの書き込みについて
> テーマ
> A)有限集合のインターフェース表現はどうあるべきか？ありうるか？
→ 一般プログラムの問題としてもオブジェクト指向言語のインターフェース表現
の問題としても、すでに解決済ではないでしょうか。

> B)無限集合のインターフェース表現にはどのような表現がありうるか？
→ 有限集合の場合とまったく同じ(これは自明ではないでしょうか?)。
濃度が有限でなくオメガや非可算にさえなるとか、booleanは3値に要拡張とかは
当然ですが、それもオブジェクト指向以前の(とは独立の)ことでしょう。

> C)無限集合のインターフェース表現が有用な場合とは、どんな場合か？
→ (省略。Bとほぼ同じ)

と単純に思うのですが、equalsさんの問題意識がいまひとつ理解できません。

MMX: ぬし; 会議室デビュー日: 2001/10/26; 投稿数: 861

投稿日時: 2005-03-22 09:31

新しいオブジェクト型の Lisper (リスパー)の出現ですか?

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2005-03-22 13:20

objectです。

もし、
「数理概念」を「ソフトウエア(言語含)」で記述するのであれば、
「ソフトウエア(言語含)」が、最低限「数理概念」、最終的には「数学」と同等以上の基礎を持つ必要がある
と思います。

私は、それを
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
で問題にした積もりです。

このスレッドは、それに対してはどう考えておられるのでしょうか？
「ソフトウエア(言語)」が、「数学」以上のベースを既に持っていると考えておられる訳でしょうか？

Gio: ぬし; 会議室デビュー日: 2003/11/28; 投稿数: 350; お住まい・勤務地: 都内から横浜の間に少量発生中

投稿日時: 2005-03-22 19:22

ソフトウェアは数学に基づくけれども、数学そのものを実装および実行可能な形で表現する能力はないと私は考えています。
以下、私の誤解を含むかもしれませんが、お気付きの方はご遠慮なく指摘してください。

ソフトウェアの基礎に Turing マシンがありますが、まずここで実行ステップという概念が導入されます。ステップ数が高々可算濃度であるため、この基礎を脱却しない限り、ソフトウェアは可算以上の濃度を持つ対象を正確には扱えません。
言い換えると、0 以上 1 未満の実数すべてを単純に列挙するだけでも、現状のソフトウェアの範囲では実現不可能です。

先の投稿で仮のインタフェースを書きましたが、あれは集合に対する操作を列挙したに過ぎません。
非可算濃度を持つ集合に対する演算は、要素を逐一計算する方法では実装不可能です。
（ただし、実数上の区間 [0,1) と [1,2] の和集合は [0,2] であるというように、対象を要素自身以外（この場合は要素を定義する述語）にすれば実装可能な場合もあります。）

ここで話題を実装されている集合に移し、例を java.util.* にとります。
java.util.Set の API には、this interface models the mathematical set abstraction とありますが、数学的な厳密性を求めるとやや説明不足ですね。
単に集合ではなく、理論的には可算濃度集合、ハードウェアリソース制約も込みで考えると有限集合でしょう。
このように絞って考えると、可算濃度集合を表す Set、要素の重複を認める場合のベースとなる Collection、整列順序を定義するための Comparator 等、実用的実装に繋がる抽象化という点では比較的整理されていると私は感じました。

もし非可算濃度集合を正確に扱えるようにソフトウェアが進化したとして、利点は...
う～ん、わかりません。
y=x（x が超越数、かつ Liouville 性を満たさない場合）、-x（それ以外）といった関数の Lebesgue 積分が簡単に計算できるようになる?

equals: 会議室デビュー日: 2005/02/23; 投稿数: 13

投稿日時: 2005-03-23 06:12

Objectさん

ソフトウェアが数学と同等以上の基礎をもつかどうかは私はわかりません。
直感的には、数学の数百年の歴史と蓄積と、高々１００年未満の歴史のソフトウェアを比較すると、同等などおこがましいでしょうね。

ただし、ソフトウェアの「実行可能性（Executable）」な特性は、数学に対しても新しい展開をもたらす可能性がありますし、静的な「数式」ではできなかった用途がありうるだろうと考えています。

また、「同等以上の基礎をもつ必要性」ですが、目的次第と思います。
この場での私の問題意識と目的は「有用な、コモンセンスとしての数理概念のソフトウェア表現を、定義ないしは実装すること」なので、特に必要条件とは考えていません。

ソフトウェア環境、UMLなどが種々の問題、限界を持っていることは直感的には合意します。この場では、それらを具体的なソフトウェア表現例の中で考えたいと思っています。

equals: 会議室デビュー日: 2005/02/23; 投稿数: 13

投稿日時: 2005-03-23 06:35

Gioさん

>ステップ数が高々可算濃度であるため、この基礎を脱却しない限り、
>ソフトウェアは可算以上の濃度を持つ対象を正確には扱えません

ちょっと感銘です。思いもつかなかった視点でした。
Executableなソフトウェアで厳密に扱えるものは、高々可算無限までということですね。

非可算無限については、ちょっと行き過ぎましたね。Gioさん同様、用途が思いつきません。でも、ソフトウェア表現の地平線がちょっと見えたという意味では、とても勉強になりました。

>実用的実装に繋がる抽象化という点では比較的整理されていると私は感じました。

初めてjava.util.Comparatorを使ったとき、かなり感激したことを記憶しています。
JDKのコレクション実装は、実用性においてはいいバランスと割り切りをしていると個人的には評価しています。

しかし、私の問題意識としては、「ユーティリティとしては使いやすいが、概念定義の道具としては未整理で冗長」と考えています。
例えば、「社員」クラスと「社員名簿」クラスを定義するとき、社員名簿クラスにjava.util.Collectionなりjava.util.Listインターフェースをimplementsするのか、ということです。（普通はしないですよね・・・？）

ビジネス上多数存在する「ものの集まり」の概念を表現する際に、javaコレクションフレームワークで使えることは、public List toList()やpublic void sort(Comparator)のようなメソッドを定義するくらいにしか使えません。

なので、もっと抽象度の高いレイヤーを数学的基礎に準拠して実装できないか、という思いが問題意識の中にあります。

やや未整理レスですみません。

引用:

Gioさんの書き込み (2005-03-22 19:22) より:
ソフトウェアは数学に基づくけれども、数学そのものを実装および実行可能な形で表現する能力はないと私は考えています。
以下、私の誤解を含むかもしれませんが、お気付きの方はご遠慮なく指摘してください。

ソフトウェアの基礎に Turing マシンがありますが、まずここで実行ステップという概念が導入されます。ステップ数が高々可算濃度であるため、この基礎を脱却しない限り、ソフトウェアは可算以上の濃度を持つ対象を正確には扱えません。
言い換えると、0 以上 1 未満の実数すべてを単純に列挙するだけでも、現状のソフトウェアの範囲では実現不可能です。

先の投稿で仮のインタフェースを書きましたが、あれは集合に対する操作を列挙したに過ぎません。
非可算濃度を持つ集合に対する演算は、要素を逐一計算する方法では実装不可能です。
（ただし、実数上の区間 [0,1) と [1,2] の和集合は [0,2] であるというように、対象を要素自身以外（この場合は要素を定義する述語）にすれば実装可能な場合もあります。）

ここで話題を実装されている集合に移し、例を java.util.* にとります。
java.util.Set の API には、this interface models the mathematical set abstraction とありますが、数学的な厳密性を求めるとやや説明不足ですね。
単に集合ではなく、理論的には可算濃度集合、ハードウェアリソース制約も込みで考えると有限集合でしょう。
このように絞って考えると、可算濃度集合を表す Set、要素の重複を認める場合のベースとなる Collection、整列順序を定義するための Comparator 等、実用的実装に繋がる抽象化という点では比較的整理されていると私は感じました。

もし非可算濃度集合を正確に扱えるようにソフトウェアが進化したとして、利点は...
う～ん、わかりません。
y=x（x が超越数、かつ Liouville 性を満たさない場合）、-x（それ以外）といった関数の Lebesgue 積分が簡単に計算できるようになる?

coasm: 大ベテラン; 会議室デビュー日: 2001/11/26; 投稿数: 237

投稿日時: 2005-03-24 02:29

敢えて突っ込んで置きます。
集合の濃度は「Ordinal」ではなくて「Cardinal」です。

«前のページへ 1|2|3 次のページへ»

数理概念のソフトウェアモデル化

スキルアップ／キャリアアップ（JOB@IT）