[ruby-dev:34362] Re: ComplexFloat

むらたです．

2008/4/11 Yukihiro Matsumoto <[e-mail]>:
>  |その上で，やはり閉じた複素数もあるべきだと思います．そして，最適化等の
>  |可能性を考えれば，閉じた複素数が組込みで提供されている方が自然である
>  |と思います．
>
>  単純さや他のクラス構成との整合性を犠牲にしてまで閉じた複素数
>  クラスを別に用意すべき理由は最適化だけですか？

最大の理由は最適化です．以下のような理由もあります．

成分が浮動小数点になってしまうと，その値は他の表現に暗黙に変換できません．
言い換えると，浮動小数点数を持つ複素数は，Rational や Integer を持つ複素数を
全部食べてしまうんです．それだけでなく，たとえば CMath.sin，CMath.exp などの
数学関数の結果は浮動小数点数を持つ複素数になるので，生成される複素数の多くが
浮動小数点数を持つことが予想できます．

ほとんどの Complex の成分が浮動小数点数なんだし，浮動小数点数から他の型には
変換されないんだから，ComplexFloat として特殊化しても良いだろうとも考えています．

# sin(π / 6) = 1/2 ですが，Math.sin(Math::PI / 6) の結果として Rational(1, 2) を
# 返してはならないという事に注意してください．Math::PI は π ではなく，
# π の近似値です．

>  現在のYARVの最適化実装を考えると、組み込みクラス(たとえば
>  Float)が変更されていない時には高速なプリミティブが動くという
>  動作をComplex(やRational)に適用してはいけない(or できない)理
>  由は無いと思うのですが。

現在の Complex は実部が Float で虚部が Rational のような状態になれます．
ですから，Complex に対してそのような最適化を行うとすると，成分の型検査を
実部・虚部に分けて毎回行う必要があります．ComplexFloat を導入すると，
データフロー解析で確実に ComplexFloat になることが分かっている部分は
型検査なしで最適化できます．

# ComplexFloat が絡む計算では ComplexFloat しか出てこない事に注意してください．
# ただし，演算の相手が Complex(BigDeciam, BigDeciam) である場合については，
# どうするべきかまだ分かりません．BigDecimal と Float は仮数部の基数の底が
# 異なっており，暗黙に変換すべきではないからです．

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