[ruby-dev:5397] Re: Bigfloat [compare to NaN]

ごとけんです

In message "[ruby-dev:5389] Re: Bigfloat [compare to NaN]"
    on 99/02/20, 石塚圭樹 <[e-mail]> writes:

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

>>ちなみに現行では Integer.induced_from() は Integer() と同じく
>>変換にしてますが，これと必ずインスタンスを生成するのとくらべると，
>>どっちがよいですか??
>
>ん? いっている意味がよく分かりません. もうちょっと詳しくお願いします
>(__;;;

つまり，Integer.induced_from(a).id == Integer(a).id
がなりたつかどうかです．現行では，Integer.induced_from(a)
は a.kind_of?(Integer) のとき a をそのまま返し，
そうでなければ新しくインスタンスを生成して返します．
これは Integer() の挙動を採用しているためです．

例:

  a = 1000000000000000000000000000
  p a.id == Integer(a).id #=> true
  p a.id == Integer.induced_from(a).id #=> true

これと，必ずインスタンスを生成するのとくらべると，
どっちがよいですか??

>ちょっとだけ言わしてもらえば, 数関係クラスのインスタンスにはnewはふさ
>わしくないって気がしています. 数っていうものは(仮想的に)既に存在してい
>てそれを使えるように引っ張ってくるというイメージです.

なるほど．それなら，Bigfloat がデフォルトの精度を持たないとして
Bigfloat.new をユーザーから隠蔽できるような仕組みが必要かも
知れませんね．

>>::class は文法的に無理でしょう．::CLASS かな．
>
>いや. できるみたいですよ. 
># irbではできませんでしたが(^^;;;

下の案に基本的に賛成してもらえたので，後学のために
お聞きしたいのですが，どうやるんですか??

>>逆に Bigfloat(prec) でクラス，Bigfloat(prec)[x] は出来るけど，
>>趣旨に合わない… んが，これはわりとよいような気がします．
>
>げげ. そういうところまでは考えが回りませんでした. たぶん. 素晴らしい
>案だと(^^;;;  

(^^;;;;

>>現状のインターフェースとある意味矛盾しない考え方は，
>>Integer のように自明な場合は Integer[] も Integer() と同じ意味にし，
>>Rational と Complex はそれぞれ原さんの指摘に従い izatinon をつけた
>>ものでクラスをあらわし，現行のものは保存するというものです．
>>つまり，Integer() などは変換であることが自明なので
>>現状のまま残すが，Integer[] をこれから推奨するわけです．
>
>ふむふむ.
>
>># [x] は (x) とちがってシフトキーを押さずに済むのでお買い得!!
>
>まあね(^^;;;
>
>>凡例: 
>>
>>  Klass(*param)
>>  # param.size == 0 なら同名のクラス Klass を返す
>>  # さもなくば Klass がパラメータを持たないことが自明なら現行の変換
>>  #   さもなくば param をパラメーターとするクラス
>>
>>  Klass(*param)[*x]
>>  #  num.size == 1 なら Klass(*param).induced_from(x[0]) 相当
訂正#  x.size == 1 ならば Klass(*param).induced_from(x[0]) 相当
>>  #          さもなくば Klass(*param).new(*x) 相当
>
>なかなか複雑ですが...

まぁ凡例ですから．

>>例: 
>>
>>  互換性:
>>
>>    Integer(num) # Integer はパラメータ持たないので変換なのは自明．
>>    Integer[num] # インターフェイスをそろえるため．意味は同上．
>>
>>    Float(num) # 現行では変換なのは自明．現行の仕様(double相当)も予約．
>>    Float[num] # インターフェイスをそろえるため．意味は同上．
>>
>>    Rational(n,d) # 現行通り．
>>    Rational[n,d] # インターフェイスをそろえるため．意味は同上．
>>
>>    Complex(r,i) # 現行通り．
>>    Complex[r,i] # インターフェイスをそろえるため．意味は同上．
>>
>>    Matrix[*rows] # 現行通り．
>>
>>  予定: 
>>
>>    Bigfloat
>>    Bigfloat() # 精度が不定のクラス Bigfloat !< Precision
>
>ここと.
>
>>    Bigfloat(prec) # クラス．
>>    Bigfloat[num]
>>    Bigfloat()[num]  # 精度が不定というエラーにすべきか?
>
>ここ.
>デフォルト精度があっても良いかも知れませんね. 大体の人は1つの精度で使
>うと思うし.
>
># 精度不定のクラスが意味があるなら別ですが.

たぶん，インターフェイスの実装は前に僕が Anumber として
示したデレーゲーションに既存のクラス生成を抑止したような
ものになると思いますので， x.kind_of?(Bigfloat) を
チェックするために不定も意味があると思います．

>>    Bigfloat(prec)[num] # num を Bigfloat(prec) に変換．
>
>>    Rationalization(klass) # (整域) klass の有理化．
>>    Rationalization(klass)[num] # num を Rationalization(klass) に変換．
>>    Rationalization(klass)[n, d] # 分子分母でインスタンス生成
>>    Complexization(klass) # (単位的環) klass の複素化．
>>    Complexization(klass)[num] # num を Complexization(klass) に変換．
>>    Complexization(klass)[r,i] # 実部虚部を指定してインスタンス生成．
>>    Matrix(klass, n, m) # 体 klass 上の n-m 行列．
>>    Matrix(klass, n, m)[*rows] # 体 klass 上の行列のインスタンス生成．
>>    Matrix(klass, n, m)[mat] # 可能なら mat をMatrix(klass, n, m)に変換．
>
>よくわかりませんが, Matrixizationじゃないんですね? あと, 忘れていまし
>たが, Vectorというのもありますです. でも, 同じですね.
>
>私はこの案に基本的に賛成です. 
>
>1つあるとしたら, パラメータ付きはみな -zationをつけるとなっていると, 
>区別がつきやすくていいなと思うぐらいですが.
>
>  Bigfloat                    デフォルト精度のBigfloat
>  Bigfloatization(perc)       精度付きのBigfloat
>  Matrixization(klass, n, m)  パラメトライズドMatrix

Matrixization という言葉がいいのかどうかは英語人の
数学者じゃないので分かりませんが，有理化や複素化が
整域や単位的環に対して自然に定義できるのにくらべ
# 複素化は初耳でしたが単位的環なら出来るみたいですね．
行列というのはは線形作用素の表現ですから行列化と
聞くとなんか違うもの(例えばリー環の表現とか)を想起します．

>あと, グローバルなインターフェイスの変更(追加)も含んでいるので, 松本氏
>の意見なんかも聞きたいなと思ったりして.

同感です．そんな分けで長く引用してみました．

-- gotoken