[ruby-dev:5171] Re: a genericity

けいじゅ＠日本ラショナルソフトウェアです.

In [ruby-dev :5018 ] the message: "[ruby-dev:5018] Re: a genericity ",
on Feb/11 22:24(JST) GOTO Kentaro writes:

>ごとけんです

どうも. 復活しました. でも, 原稿書かないと怒られるので(きっと, 皆さん
にも(^^;;;), ちょっと押え目に...

>altavisita と goo でひいたらシコタマかかったんですが，
>早合点でした．どうも genericity は総称性とでもいうべき 
>feature のことらしいです．

ああ, generic functionがらみの話しですねきっと.

>石塚さんがほかでも言われている「汚れた Float をきれいな Integer
>にするのは良くない」というのはそういう意味なんですね．

です.

>>bignumは小数部がない固定小数点数ではなくて,
>>
>>Bignum(1) = 1.00000000000000000000000000....無限に続く
>>
>>ですので, floatよりも確実に精度は上です.
>
>そうはいっても，
>Bignum(0.1) == 0.000…
>Float(0.1) == 0.10000000000000000
>を考えると実軸上での距離は Float の方が近いので，
>どこの元かを考えると，場合によっては Float の方が
>精度が良いと考えられます．

えーと. これは強制的な型変換を行なっているので, これで比較するのはおか
しいと思います.

>一方 1e999 == Inf != 10**999
>だしやっぱり両者は比較不能と思うのです．

これも, Float側の問題ですよね. 

私は, Fixnum+Bignumで数の集合での整数を表していると考えています. ここ
が根本的な違いでしょう. Rationalなんかもこのモデルを前提としています.
そうでないなら, Rationalそのものも存在できないですし...

で, Floatは何かというと 同値関係

  f1 ≡ f2 <=> ε < f1 - f2 < ε

として R/≡ をFloatとしてみています. 結局, 豊福さんのいっている代表元
の考えと同じですが.

>>うーん. Complexの極座標表現とかは?
>
>それは，やっぱりパラメーター付のクラスを考えるのが妥当でしょう．
>
>思い入れの話になりますが，ある意味残念なことに，Ruby では，
>「A(初期値) ==> クラス A のオブジェクト」のようなメソッドを
>用意しますが，「A(パラメータ) ==> 制限されたクラス A」 のほうが
>便利だと思ってました．Matrix(2,3,Complex) は 2x3 複素行列クラスとか，
>Matrix(2,3,Integer).induced_from(4.5) 
>  ==> SizeMismatchError
>Matrix(n,n,Integer).induced_from(float) 
>  ==> Matrix.unit(n) * Integer.induced_from(float)

パラメタライズドクラスをRubyで実装するのはそれほど難しくないと思います
よ. Bigfloatのスレッドで出ていますが

  Bigfloat(有効桁数)

でクラスを指定しようという案が出ています.

ただ, それと

>とか，Complex(:polar) ==> 極座標表示の複素数クラスとか．

は問題が少し違うと思いますけどね. FixnumとBignumの関係と同じで実際の構
造が違うのだから違うクラスと考えた方が良いと思います. 

>>Polynomialって多項式環? それともただの多項式?
>
>まだちゃんと動かないけど多項式環です，といっても，環論的
>メソッドがあるわけでなく，加減乗で閉じてるという意味で．
>Numeric は単項定数式とみなします．

なるほど.

>>># ちなみに僕は Precision は Rational を上界とする有向集合だと
>>># 思ってます．
>>
>>頑張ればRealも実装できますよ(^^;;;; 実装できなくても上限はRealでしょう.
>
>Raal の実装はたぶん，指定された桁までを返す手続きか，
>URR みたいな任意精度浮動小数点数のいずれかですね．
># cf. URR <URL:http://urr3.cs.uec.ac.jp/note.html>

URRってどんなものか.dviファイルなんでみれませんでしたが...

私が考えていたのは, cauchy列を実数とみなすモデルです. 要求駆動型で実際
に必要となった段階で実際に計算します. 

>>>これなら coerce は，最小上界を求めてそれに両者を変換すれば
>>>良いわけで，たくさんの組合せに悩む必要はありませんし，
>>>Numeric と独立な場合の coerce も同じ方針で設計できます．
>>
>>今の仕様はめんどくさかったので一般的になっているのでしょう. 
>一般的な取り扱いを目指してみました．

うーん. 

>>これって, どっちかというと数学のモデルですよね. 実装上のモデルとしてこ
>>れで十分なのかどうか...
>それは動くものを作らないと分からないとしか言いようがないです(^^;;

えーと. ですね. 提案なんですが, どちらにしても新しい coerceはRuby-1.3
及びRuby-2.0に採用されることはないと思います. 

というのは, Ruby-2.0はRuby-1.2から大幅には変わらないことと,
私ことながら, この議論をしていると, 本が何時までたっても出ない. => 皆
さんに顰蹙をかう...

ということで, Ruby-1.3/Ruby-2.0では, coerceは今までの通り, precも今の
案からそれほど変えないものにしていただきたいのですが...

で, Ruby-2.0がでて, Ruby-2.1で本格的に再検討するということにしません??

__
................................石塚 圭樹＠日本ラショナルソフトェア...
----------------------------------->> e-mail: [e-mail] <<---