ruby-dev

むらたです．

2008/4/13 Tanaka Akira <akr@fsij.org>:
> In article <761216ce0804121126i557ad854j6e52283f7ef4542@mail.gmail.com>,
>  あと、さらに考えて疑問に思ったんですが、仮に、そういう、すご
>  い、データフロー解析が可能だとしたら、なぜクラスを別にする必
>  要があるのだろうか、という点もあるかもしれません。データフロー
>  解析により、ある Complex のコンストラクタの引数が Float であ
>  ることが判明すれば、そこで生成される Complex オブジェクトは
>  内部が浮動小数点数で表現されることもわかるでしょうから、
>  ComplexFloat という異なるクラスにする必要はないかもしれませ
>  ん。

究極のデータフロー解析，というかそこまでいくと型推論と言ったほうが
近そうですね．

最初に ComplexFloat というクラスの新設を主張した理由は，私には
現在の Complex (および Rational) のコンテナ的な仕様が既に決定事項
であるように思えたからです．

complex.c や rational.c がコミットされるまでは，誰一人として同様の主張を
していませんよね．コミット後に少数の人が「C99 の複素数を持つ実装も
ありますよ」と言っても，良く分からない反論だけが返ってくる状態でした．
私はこのような状況を見て「Complex の中身は変更できないんだな」と判断しました．
そのため，最初に提案する時点では ComplexFloat という新しいクラスを
導入するしかないと考えていました．

>  でも、ComplexFloat が生成されて足し算などの演算にたどり着く
>  ことは判断できるが、Float が生成されて Complex のコンストラ
>  クタにたどり着くのは判断できない、という理由を考えるのはなか
>  なか難しい気がします。少なくとも現時点で私には思いつきません。

私は ComplexFloat を導入して欲しいと言ったときの理由の一つに，
「ComplexFloat は Float で定義されている演算規則には依存しない」
という仕様を持たせられる事を挙げました．

Complex がコンテナであり，Float の演算規則に依存している以上，
Float が生成されて Complex の成分になったところで最適化できない
可能性があります．Float だけではなく，Integer/Rational にも依存するわけで，
コンテナとして実装されている Complex は最適化できない状況が多いです．
例えば，あるクラスの coerce が再定義されてしまうと，普通なら Float を
期待できる文脈もそうでは無くなってしまいます．

ComplexFloat は他のクラスの演算をせず，すべての演算を C で定められた
演算規則で実行するので，他のクラスが再定義されている事には依存せず
ComplexFloat の状態だけで最適化の可能性が決定できます．

という話を何度か説明させていただきましたが，Complex の仕様自体がまだ
流動的であると言われてしまい，最初に ComplexFloat を提案したときの
前提が崩れています．ですから今の時点では，Complex の仕様によっては
ComplexFloat を導入しなくても私が主張した ComplexFloat の利点を実現
できる可能性があります．

-- 
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

Thread

Prev Next

In This Thread

Prev Next