[ruby-dev:5399] induced_from vs coerce_of_Lisp [Re: a genericity]

ごとけんです

In message "[ruby-dev:5388] Re: a genericity"
    on 99/02/20, 石塚圭樹 <[e-mail]> writes:

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

>># 実はリテラルと to_s の近さを気にしているのではないかと
>># 疑っています．Float(0.1).prec(Rational) を表示したとき，
>># 見た目にすごい分母が出て来るのがイヤなんではないかとか :-)
>
># 数学の問題を解いたりしていて, すごい分母がでてくると直観的に間違って
># いるなって感じちゃいますよね. そういう過去の体験が... 
># ってことはないですよきっと(^^;;;

(^^;;;;

>>In[1]:= ?N
>>N[expr] gives the numerical value of expr. N[expr, n] attempts to give a
>>   result with ndigit precision.
>>In[2]:= N[Pi,30]
>>Out[2]= 3.14159265358979323846264338328
>>
>>というようなものです．
>
>N桁の精度で返す関数?

のようですね．どうやってるか知りたいです．

In[2]:= N[Sqrt[1/3],50]
Out[2]= 0.5773502691896257645091487805019574556476017512701
In[3]:= N[1/Sqrt[3], 50]
Out[3]= 0.5773502691896257645091487805019574556476017512701
In[4]:= N[Sqrt[0.3],50]
Out[4]= 0.547722557505166
In[6]:= N[Sqrt[3/10],50]
Out[6]= 0.5477225575051661134569697828008021339527446949980
In[7]:= N[Sqrt[3]/Sqrt[10],50]
Out[7]= 0.5477225575051661134569697828008021339527446949980

あ! あああ!

In[10]:= 1/2 - 0.5
Out[10]= 0.
In[11]:= 1/2 - 1/2
Out[11]= 0
In[12]:= 1 + 1. 
Out[12]= 2.
In[13]:= 1. + 1
Out[12]= 2.

うーむ，Mathematica もそう思うのか…実装例からも解決「され」そう(汗;

ちなみに

In[21]:= N[2.3^100000, 1000]
                       36172
Out[21]= 6.075776073 10
In[22]:=  N[2^100000, 1000]
                                             30102
Out[22]= 9.99002…(ほんとに1000桁表示する) 10
In[23]:=  N[2^100000, 50]       
                                                              30102
Out[23]= 9.990020930143845079440327643300335909804291390542 10
In[24]:= 2.^(10^10000)
General::ovfl: Overflow occurred in computation.
Out[25]= Overflow[]

だそうです．

>>># ちなみに, こんなかでcoerceという関数があるのですが, これが私の欲しい
>>># メソッドですね.  
>>
>>おお，これは induced_from に近いような．
>
>すいません. ここでprecじゃなくてinduced_fromになるのは何故?
>
># この辺に感覚の違いがあるのかも.

かも知れません．induced_from という名前は数値とは
関係のない文脈でも使えると思うからです．coerce にも
同様の響きを感じます．一般に行列などは数値だけのものでは
ありませんが，GF(k) を位数 k の有限体として
  n次正方行列 Matrix(GF(3), n).induced_from(1) 
は許せる．これに対して prec は数値と関係があって欲しいので，
prec(Matrix(GF(3), n)) は気分的には許せません．
まぁ，Scott流の近似概念が扱えるなら数値でないときも 
prec でもいいですけど，ちょっと凄すぎ．

>>パラメトライズされたクラスを関数形式で書けるなら，
>>  (coerce #C(7/2 0) '(complex double-float))
>>は mathn 表記で，
>>  Complex(DoubleFloat).induced_from(Complex.new(7/2, 0))
>>と書けるとか．
>
>これ, 今は許されていませんよね? ComplexはPrecisionじゃないから. でも, 
>要素のタイプが確定していれば許すのかな?

これは上に書いた感覚のためです．ただし，Precision が何か
について新たな合意が得られれば， Complexization も
ある種の条件のもとで Precision にしても良いと思います．

>あと, そういうのもありますし, 以下のようなものありますよね.
>
>  (coerce 4.5s0 'complex) => #C(4.5s0, 0.0S0)
>
>こういう変換が許されるようになると, Rubyのcoerceは大部楽になるのに...
>ってことでした. Rubyのcoerceをprecで実装するには, こんな感じの変換を行
>なえる必要があるんですよね...

そうなんですよね．この辺が，Complex#prec を作っても
Precision のと違うし共有できないと感じるところです．
ただ，そこまでやると prec よりも新しい coerce モデルを
考えたくなりますが，今はヤめませう．

そもそも，なんでこの手のスレッドはこんなに盛り上がるのか
考えたんですけど，石塚さんとか原さんとかみたいなパワフルな
スキモノの存在はともかくとして，Ruby にはいろいろな
数学概念を実装しやすいと思わせるなにかがあるからでしょうね．
他の言語のコミュニティでもこういう現象はあるのかしらん．

>うーん. もっと大雑把にいうと, なんなんでしょう? セルオートマトンを専攻
>しているっていうと間違いなんでしょうね? 数学基礎論とかソフトウェア基礎
>論とかも深いですが関係あるんです? 一見なさそうな気もしないような気がし
>ないでもないですが...
>
>それにこれって数値計算と関係あるのかしら??

特に分野に名前はありません．強いて言えば計算機科学です．
えっと，セルオートマトンは技術的な発見をしたのでたまたま
やってるんですけど，ライフゲームといえばアナログガジェット
みたいな並列計算って実は普通の計算と違うんではないかと
思っているとか，
なら普通の計算じゃないっていうのはどうやって定義するのとか，
実際にアナログなものを考えるときは，カオスという力学系の
性質を避けて通れないけどそれって計算できるのとか，
そして，ニューロンで行われていると思っちゃう「情報処理」
ってどうやったら定式化されるのかとか，
あるいは「機能」とは一体何なのとか…

まぁそんなこんなで，まずはカオスは数値計算でみえるのか
というのと計算と呼ばれているものにはどういう言い換えが
あるのかということを勉強してます．

cf. http://www.chaosken.com/comp_subgroup.html

-- gotoken