@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

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

投稿者投稿内容
equals
会議室デビュー日: 2005/02/23
投稿数: 13
投稿日時: 2005-03-11 07:27
自然言語で語るのはやめて実装レベルで数理概念のモデル化について語りましょう。

テーマをいくつかあげてみます。
 ・集合の概念をソフトウェアで表現するにはどんな方法があるか?
 ・演算子の概念をソフトウェアで表現するにはどうすればいいか?
 ・java.util.*コレクションフレームワークの評価
 ・線形演算可能なオブジェクト(数、ベクトル、など)とその応用について

しばらく経ってレスなければ、私からいくつか具体テーマを提起します。
equals
会議室デビュー日: 2005/02/23
投稿数: 13
投稿日時: 2005-03-15 08:47
集合を表現するにはどうすればいいかを考えてみます。
とりえあず集合はSetという名前にします(java.util.Setとは異なる)

1)要素に対してアクセスできる(java.util.Setに一番近い)

public interface Set1{
 public Enumeration elements();
 public int size();
}

2)包含関係を相互に定義できるものを集合ととらえる。

public Interface Set2{
 public static final int RELATION_IMPLECATE=3;//包含する
 public static final int RELATION_IMPLECATED=2;//包含される
public static final int RELATION_JOINED2=1;//共通部分を持つ
public static final int RELATION_EQULAS=0;//全ての要素が等しい
 public static final int RELATION_SEPARATED=-1;//共通部分がない

public int relation(Set2 set);
}

3)オブジェクトが集合に含まれるかどうかを判別できる機能だけを持つ

public interface Set3{
 public boolean belongTo(Object obj);
}

超単純な定義を3つ挙げてみました。
数学上の集合の概念にそってインターフェースを定義した
ものの、どれも「集合」の概念の一意な表現ではなく、
ひとつの側面を表せているにすぎません。

----
今回の結論

A)数学上の高度な抽象概念をソフトウェアで厳密に表現することは
 あきらめたほうがよい。
B)数学上の高度な抽象概念であっても、限定された側面に着目すれば
 モデル化は可能である。
----
今回の予測
C)数学上の概念をソフトウェアに応用することは有益。少なくとも設計を
 洗練する上での助けになる。
----
テーマ
D)順序付けられた集合や線形空間のモデル化
 ⇒どなたかいかがですか?
コモンセンス
会議室デビュー日: 2005/01/05
投稿数: 15
投稿日時: 2005-03-15 12:38
引用:

equalsさんの書き込み (2005-03-15 08:47) より:
今回の結論

A)数学上の高度な抽象概念をソフトウェアで厳密に表現することは
 あきらめたほうがよい。



これってどういうことですか?
「高度な」というのがどういう意味なのか分かりませんが、
集合概念をはじめとしてどんな数学概念も(まあ)プログラム可能であるのは
むしろ常識だと思うのですが(高階の概念等については要注意だとしても)。
equals
会議室デビュー日: 2005/02/23
投稿数: 13
投稿日時: 2005-03-15 19:45
引用:

コモンセンスさんの書き込み (2005-03-15 12:38) より:
引用:

equalsさんの書き込み (2005-03-15 08:47) より:
今回の結論

A)数学上の高度な抽象概念をソフトウェアで厳密に表現することは
 あきらめたほうがよい。



これってどういうことですか?
「高度な」というのがどういう意味なのか分かりませんが、
集合概念をはじめとしてどんな数学概念も(まあ)プログラム可能であるのは
むしろ常識だと思うのですが(高階の概念等については要注意だとしても)。



ちょっと言葉足らず&予断と個人的詠嘆に満ちた表現でした。訂正します。
旧)A)数学上の高度な抽象概念をソフトウェアで厳密に表現することは
  あきらめたほうがよい。
新)A)数学上の抽象度の高い概念の中にはJava等のプログラム言語仕様では
   定義しにくいものがあるので、そのような概念を無理矢理一つのクラスで
   定義しようとしない方がよい。
   (マーカーインターフェースを使えば何でも一つにできはするのですが)

課題設定としては、数学上の概念をクラス(インターフェース)で、できるだけ
単純かつ正確に表現することが、実際どこまでできるか、という趣旨です。
100人100様の実装なら、「どんな数学概念も(まあ)プログラム可能」であるのは
仰せの通りです。
コモンセンス
会議室デビュー日: 2005/01/05
投稿数: 15
投稿日時: 2005-03-17 15:18
コモンセンスです。
引用:

equalsさんの書き込み (2005-03-15 19:45) より:
ちょっと言葉足らず&予断と個人的詠嘆に満ちた表現でした。訂正します。
旧)A)数学上の高度な抽象概念をソフトウェアで厳密に表現することは
  あきらめたほうがよい。
新)A)数学上の抽象度の高い概念の中にはJava等のプログラム言語仕様では
   定義しにくいものがあるので、そのような概念を無理矢理一つのクラスで
   定義しようとしない方がよい。
   (マーカーインターフェースを使えば何でも一つにできはするのですが)

課題設定としては、数学上の概念をクラス(インターフェース)で、できるだけ
単純かつ正確に表現することが、実際どこまでできるか、という趣旨です。
100人100様の実装なら、「どんな数学概念も(まあ)プログラム可能」であるのは
仰せの通りです。



数学概念を「クラスを用いて単純に」定義するのは難しいという趣旨だったのですね。わかりました。

さてしかしそれは本当にそうなのでしょうか?

先に挙げられた集合(Set)クラスの例でいえば、

クラス:Set
インタフェース:
int Size()
bool Implicate(Set)
bool Implicated(Set)
bool Joined(Set)
bool Equals(Set)
bool Separated(Set)
bool BelongTo(Obj or Set)
#()内はパラメータのつもり

とでもすれば、比較的単純に、Setが一つのクラスで定義されると
思うのですが、これはequalsさんの意図とは違ったものなのでしょうか?
equals
会議室デビュー日: 2005/02/23
投稿数: 13
投稿日時: 2005-03-18 08:32
コモンセンスさんのクラスSetの定義は、「有限個の集合」については、一貫性のある表現です。
さらに無限要素の集合にまで広げるとどうでしょうか。

いくつか例を挙げて比較してみます。

 集合{x} xは全ての実数
 集合{y} yは部分文字列sを含む全ての文字列
 集合{z} zは有限個の文字列
 集合{w} wはa<w<bを満たす全ての実数(a,bは実数)

これらの4つの集合を、私の挙げた集合の実装例

 1)要素に対してアクセスできる
 2)包含関係を相互に定義できるものを集合ととらえる。
 3)要素が集合に含まれるかどうかを判別できる機能だけを持つ

で表現可能かどうかを考えてみると、あんまりfitしないケースがあります。
下の表の×のところです。

    集合{x}  集合{y}  集合{z}  集合{w}
1)   ×    ×     ○    ×
2)   ○    ○     ○    ○
3)   ○    ○     ○    ○

実数の集合においてsize()は何を返すべきか?
無限大でしょうが、int値では表現できない。
実数の集合において、要素の列挙を返すメソッドに意味があるかどうか、実用的かどうか、実装可能か、どれも疑問です。

2),3)はいずれも4つの例を表現できますが、これが集合の実装表現としてどの程度一般性をもつのか、私の数学知識レベルではちょっと自信がありません。どっちもいい線いっているような気もしますが。

---------
今回の結論

A)有限集合はオブジェクト指向言語の単純なインターフェース(インターフェース表現と略します)で
 一意性の高い表現ができそう。(すでにあるっちゃあります。java.util.Setとか)
B)有限集合に対するインターフェース表現では、無限集合を表現するのに無理がある。

---------
テーマ
A)有限集合のインターフェース表現はどうあるべきか?ありうるか?
B)無限集合のインターフェース表現にはどのような表現がありうるか?
C)無限集合のインターフェース表現が有用な場合とは、どんな場合か?


引用:

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

数学概念を「クラスを用いて単純に」定義するのは難しいという趣旨だったのですね。わかりました。

さてしかしそれは本当にそうなのでしょうか?

先に挙げられた集合(Set)クラスの例でいえば、

クラス:Set
インタフェース:
int Size()
bool Implicate(Set)
bool Implicated(Set)
bool Joined(Set)
bool Equals(Set)
bool Separated(Set)
bool BelongTo(Obj or Set)
#()内はパラメータのつもり

とでもすれば、比較的単純に、Setが一つのクラスで定義されると
思うのですが、これはequalsさんの意図とは違ったものなのでしょうか?

らぶま
常連さん
会議室デビュー日: 2004/10/21
投稿数: 32
投稿日時: 2005-03-18 09:33
らぶまです。
興味深く拝見しています。

解決策ではないですが、ふとした疑問です。

無限集合まで考えるなら、
集合の要素数、つまり濃度を求めるSize()メソッドが何を返すにせよ、
無限集合同士の濃度の大小関係が比較できないと困ります。

例えば、
A. 0から1までの全ての実数の集合
B. 全ての自然集合
ではどちらのSize()が大きいかといえば、
数学的にはAのほうですね。

濃度自体はAもBも無限大なので、
集合間の濃度の大小を判定するインタフェースが
新たに必要かもしれませんね(Size()でうまくカバーできるか?)。
コモンセンス
会議室デビュー日: 2005/01/05
投稿数: 15
投稿日時: 2005-03-18 17:53
コモンセンスです。

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

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

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

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

スキルアップ/キャリアアップ(JOB@IT)