From: Kenta Murata Date: 2008-04-13T14:08:51+09:00 Subject: [ruby-dev:34381] Re: ComplexFloat むらたです． 2008/4/13 Tanaka Akira : > 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