From: Shin-ichiro HARA Date: 2008-05-07T17:55:58+09:00 Subject: [ruby-dev:34599] Re: ComplexFloat 原です。 まつもとさんが ComplexFloat を却下したい意向を表明して、もや はそれを覆すだけの説得力を持つ論拠がみつからないので、一応こ のスレッドは終わったと思います。 が、ほとんど残務処理（敗戦処理？）ですが、ある程度誤解は解い ておきたいので、もうちょっとだけ。 > まつもと ゆきひろです > > In message "Re: [ruby-dev:34541] Re: ComplexFloat" > on Wed, 30 Apr 2008 18:50:06 +0900, Shin-ichiro HARA writes: > > |Tanaka Akira さんは書きました: > |> Complex と ComplexFloat とクラスをふたつに分ける理由がどうに > |> もわかりません。 > | > |その理由こそちゃんと述べないといけないのですが、なかなか伝わ > |らないですね。うまく表現ができてないみたいです。一応答えるこ > |とができるところだけ答えます。 > > 何度か読み返したのですが、やっぱりよくわかりません。 > > * Complex.newの存在は純粋に互換性だけが理由だと考えています。 > ですから、Complex.newの存在はなんの根拠にならないと思います。 > いっそComplex.newを削ってもよいでしょう。 ComplexFloat の話と Complex.new は関係ないです。 Complex.new の存在を根拠に何かを主張したはずはないんだけれど、書き方が紛 らわしかったんだろうなあ。 > * Floatを成分として持つComplexとComplexFloatが挙動を含めて等 > しいものであるのにもかかわらずComplexFloatとComplexの両方 > があった方が良い理由として、 > > (a) Complexの用法としてComplexFloatがほとんどであろうと推 > 測される > > (b) 挙動がクラスで決まる、というのはよいことではないかと考 > える > > の2点があげられていますが、 これは、「ComplexFloatとComplexの両方があった方が良い理由」では なくて、「ComplexFloatがあった方が良い理由」です。 > の2点があげられていますが、前提から考えて(どうせ同じ挙動な > んだから)Complexの用法としてFloat成分がほとんどであろうがな > かろうが、ComplexFloatを分離する根拠にはならないと思います。 これは、f() を関数なり操作なり(= 挙動)とするとき、 (c) Float 成分の Complex である x と、それと等しい ComplexFloat の y に対して f(x) と f(y) は等しい ので、y の方はいらないんじゃないか、ということですよね。(c)は その通りです。 おとといの晩妻にあることがきっかけで、頭のおかしい意固地なお じさん呼ばわりされた（しかも心当たりはある）ので、度々同じ話 を繰り返すのは、はばかれるのですが、私の主張をもう一度言うと、 f() を関数なり操作なりとするとき、 (d) Complex である x と、それと等しい Complex の y に対して f(x) と f(y) が等しくない ということがあり、これを問題にしました。 くどいですが、もう一度言うと、(a) を ComplexFloat を分離する 直接の根拠としたのではなく、(d) を Complex の欠点と指摘し、そ の欠点が無い ComplxFloat を組み込みとして導入する根拠とした。 一方、Complex 利用者の多くは ComplexFloat があるのならそちら を利用するようになるだろう。その根拠が (a) です。 ところで、ケース (d) が発生数する頻度も多くありません。こちら は頻度が少なくても問題であると考えました。(問題になる例として、 すぐ思い浮かぶのは、行列の階数や行列式の話なのですが、分かり やすくないわりには説得力が十分とは言えないので、結局説明を断 念しました。) > 「現行の組み込みの数値クラスはすべてクラスで決まっている」 > とありますが、たとえばFixnumとBignumは本当は同じIntegerクラ > スにしたかったのが、一方が即値であるためにできなかったとい > う「私の思い」があり、「設計者がしたいのにできなかった」こ > とをもって「よいこと」と断じられるのは不本意です。 これって「設計者がしたいのにできなかった事を、できたかの様に 言い(事実誤認)、かつそれをよいことと断じた」という意味でしょ うか。 そういうつもりじゃなかったんだけど。 なぜ、そうとられたのかずっと分からなかったのですが、今さっき やっとわかりました。私が「現行の組み込みの数値クラスはすべて クラスで決まっている」と書いたのが紛らわしかった。言いたかっ たのは「現行の組み込みの数値は、ひとつのクラスに対して、ひと つの挙動が一意に決まっている」ということです。これは、Finxum と Bignum も、それぞれ挙動が一意に決まっているので、例外では ないです。現行では整数の持つべき挙動に対して、クラスが一意に 決まっていないわけですが、これについてコメントをしているので はありません。つまり「クラス -> 挙動」という対応をコメントし たのであって、「挙動 -> クラス」の対応をコメントしたのではな かったんです。表現が悪くてすいませんでした。 というわけで、不本意と捉えないでいただくとありがたいです。 > また、「数値クラスという単純であるべき」とありますが、 > Complexというクラスひとつを導入するのとComplexFloatを代表す > る多数の「Complex族」を導入したり、あるいはComplexFloatとほ > ぼ同じ動作を内包するようなComplexクラスを並立させたりするこ > とは、成分ごとに挙動が多少変化するComplexよりも複雑に(私に > は)感じます。 「Complex 族」を導入することは全く考えていませんでした。 > |exact? と inexact? の導入は検討されてもいいと思います。しかし > |数の挙動を表現する情報としては不十分なわけで(例えば Rational > |と Integer は exact だけど挙動はかなり違う)、そのものズバリ > |「クラスが体を表す」のはいいことではないかと思うのですが... > |数値なのにクラスで性質が判断できない、という気持ち悪さを感じ > |過ぎなのかなあ。 > > 確かに数値クラス群はRubyの中では例外的にクラスが意味を持つ傾 > 向がありますが、絶対視する必要はないように思うのです。 確かにその通り、私は Ruby というプログラミング言語全体のバラ ンスを考える以上にこの性質を絶対視し過ぎていたかもしれません。 これについては自己批判すると、最初 Ruby を見たとき、クラスが いわゆる「群・環・体」などの「代数系」を表現しているように見 えていたく感激した、その感激を引きずっていたように思います。 「そういうアナロジーも使えることがあります」程度に考えるべき でした。