From: Yukihiro Matsumoto Date: 2008-04-11T07:54:23+09:00 Subject: [ruby-dev:34322] Re: ComplexFloat まつもと ゆきひろです In message "Re: [ruby-dev:34318] Re: ComplexFloat" on Fri, 11 Apr 2008 02:30:58 +0900, "Kenta Murata" writes: |だとすると，ふなばさんは私の提案の何に対して「いびつ」であると |お感じになっているのでしょうか？そこがまだ理解できていないので |教えてください． 「早すぎる最適化」を懸念しておられる気がします。私としては村 田さんの主眼が読み切れてないので保留します。 * 機能セット(C99 complex関数相当を提供する) * 内部実装(C99 complexをオブジェクトに埋め込む) * 効率(メモリ効率、計算効率) * 拡張ライブラリの書きやすさ の話が同時に出てくるので判断しがたいです。 たとえば、 |少なくとも C99 の複素関数群をサポートするか否かは Ruby の数値系の |方向性に大きく影響するはずです．そして，複素関数群をサポートする場合の |実装方法として _Complex を持つかどうかという話になるわけですが， |それは今迄の議論で十分話し合われていると思います．すなわち， |Float を VALUE で持つ必要性は無いということです． で見ると、「影響するはずです」までは機能セットの話、 「Complexを持つかどうかという話」は内部実装の話です。また、 ComplexFloatを導入するのであれば、そこで「FloatをVALUEで持つ 必要性は無い」のはその通りですが、Complexクラスしか導入しな いという前提では逆に「Floatを特別扱いしてVALUEで持たない必要 性」はまだ結論が出ていない(個人的には消極的)です。 さて、個別の論点について整理しましょう。 まず、機能セットについては反対しません。また、その実装として (あれば)C99 complexを経由するのもよいと思います。ただし、C99 を必須にするのは当面避けたいので、利用するにしても結局互換層 を用意する必要があると思います。 内部実装についてですが、以前いただいたパッチのように直接オブ ジェクトに埋め込むのは全体のメモリ効率を低下させるので採用し がたいです。独立したComplexFloat(あるいはFloatComplex?)クラ スを採用すると決めるまではこれは保留するのがよいのではないか と思います。個人的にはあまり独立したクラスを導入したくないで すが。 効率についてですが、メモリはできるだけ消費しない、速度は速い に越したことはないですが、即値でない以上、限界があると思いま す。また、Rubyから呼び出す以上、メソッド呼び出しのコストが大 きいので、事前の予測は困難ですからあまり急いで最適化について 考える必要はなさそうに思います。 最後に拡張ライブラリの書きやすさですが、C99を必須にできない 点などからある程度困難をともないますが、結局はCのcomplexを表 現するデータとRubyのオブジェクトを相互変換するAPIがあるかど うかに帰結するように思います。これは内部実装をどのようにする かとは独立の話です。 まつもと ゆきひろ /:|)