[ruby-dev:34501] Re: ComplexFloat

> 私の言う事をそのまま進めれば、Array(Integer) 型などが必要となるというの
> は、確かにそのまま進めればそういうことになるのですが、私は「複素数に限っ
> て」 Complex(Float) 型のようなものを推しています。多分、複素数を利用す
> る人の大部分はそれが欲しいのだ、という推定があるからです。

整数などを拒否する理由がよくわらないですが、邪魔になるということなんで
すかね。

Complex(Float,Float) は最初から汚染された存在なので、大部分の人がこれ
を利用するというなら、とくに気をつかうべきところもないように思います。

Complex に限らないですが、正確でも非正確でもそれなりに計算するしかない
ので、Complex で、一律に定まらないからよくないということもないと思いま
す。

で、ここで、exact? と inexact? の話を出そうと思ったら、田中哲さんが、
思っていたことを完璧に説明してくれました。exact? と inexact? は、既に
コードは用意しています。

> うーん、Complex の仕様を曲げる気はないんだけどなあ。むしろ Complex には
> できるだけそのままの仕様で、という提案なんだけど。何度も言いますが、
> Complex は必須です。

結局、ComplexFloat が組み込みになった場合は、これが Complex になると考
えています。ComplexFloat (FloatComplex?) は、ComplexInteger とか、
ComplexRational の存在可能性を暗に示してしまうのも問題になると思います。
既存の Complex は忘れるしかないように思います。

余談ですが、とくに振舞いの違いを気にして、Complex* のようなものを導入
するくらいなら、TrueInteger のようなものを導入したほうが本質的かもしれ
ません。/ の問題は、Integer の問題ともいえるので、まともな / を定義し
た代替のクラスを用意することで対処が可能なように思います、理屈としては。
もちろん、一番いいのは、Integer 自体を変更することだと思います。

Complex が ComplexFloat 相当になると、数の体系での包含関係でちょっと不
自然になると思います。mathn が目指しているものとの乖離も進み、ほとんど
崩壊すると思います。

> しかし、幾つかのプログラミング言語を見渡すと、Complex と ComplexFloat
> の二頭体制を取っているのは皆無ですね。この主張を通そうとすると、かなり
> 気が強く…じゃなくて…しっかりした根拠を示さないといけないようです。

よほどの事がない限り無理じゃないかと思います。

むしろ今の状況なら、Complex の組み込み自体を取り消されても驚きません。