ruby-dev

原です。

> まつもと ゆきひろです

> |> * Floatを成分として持つComplexとComplexFloatが挙動を含めて等
> |>   しいものであるのにもかかわらずComplexFloatとComplexの両方
> |>   があった方が良い理由として、
> |>
> |>   (a) Complexの用法としてComplexFloatがほとんどであろうと推
> |>       測される
> |>
> |>   (b) 挙動がクラスで決まる、というのはよいことではないかと考
> |>       える
> |>
> |>   の2点があげられていますが、
> |
> |これは、「ComplexFloatとComplexの両方があった方が良い理由」では
> |なくて、「ComplexFloatがあった方が良い理由」です。
>
> でも、「両方あった方がよい」と思ってるんですよね。その辺がよ
> くわからない。

ComplexFloat だけでは表現できない数があるので、Complexを廃止
する事は考えもしていません。

> |>   の2点があげられていますが、前提から考えて(どうせ同じ挙動な
> |>   んだから)Complexの用法としてFloat成分がほとんどであろうがな
> |>   かろうが、ComplexFloatを分離する根拠にはならないと思います。
> |
> |これは、f() を関数なり操作なり(= 挙動)とするとき、
> |
> |  (c) Float 成分の Complex である x と、それと等しい
> |      ComplexFloat の y に対して f(x) と f(y) は等しい
> |
> |ので、y の方はいらないんじゃないか、ということですよね。(c)は
> |その通りです。
>
> そこは共有してるんですね。よかった。

(c) は共有しています。「y の方はいらない」を共有していないの
だと思います。

> |f() を関数なり操作なりとするとき、
> |
> |  (d) Complex である x と、それと等しい Complex の y に対して
> |      f(x) と f(y) が等しくない
> |
> |ということがあり、これを問題にしました。
> |
> |くどいですが、もう一度言うと、(a) を ComplexFloat を分離する
> |直接の根拠としたのではなく、(d) を Complex の欠点と指摘し、そ
> |の欠点が無い ComplxFloat を組み込みとして導入する根拠とした。
> |一方、Complex 利用者の多くは ComplexFloat があるのならそちら
> |を利用するようになるだろう。その根拠が (a) です。
> |
> |ところで、ケース (d) が発生数する頻度も多くありません。こちら
> |は頻度が少なくても問題であると考えました。(問題になる例として、
> |すぐ思い浮かぶのは、行列の階数や行列式の話なのですが、分かり
> |やすくないわりには説得力が十分とは言えないので、結局説明を断
> |念しました。)
>
> で、ここが重要です。まず確認ですが(d)のようなケースがあるん
> ですね。私には「行列の階数や行列式の話」はわからないので、こ
> こでは「ある」と仮定して話を進めます。

繰り返しになりますが、(d) の例は

  # 例1
  require "rational"
  require "complex"

  def f(x)
    x - Complex(0,1)
  end

  x = Complex(0, 1.6)
  y = Complex(0,Rational(16, 10))
  p x == y       #=> true
  p f(x) == f(y) #=> false

です。

行列式云々というのは、上の f() の例に対して「確かに f(x) と
f(y) は異なるが、十分近いので問題にならないのではないか」と
いう疑問に答えるものです。次の例が

  (e) Complex である x と、それと等しい Complex の y に対して
      f(x) と f(y) がはっきり異なる

というものです。

  # 例2
  require "rational"
  require "complex"
  require "matrix"

  def f(x)
    Matrix[[Complex(0,1), Complex(0,1), Complex(0,1)],
           [Complex(0,1), Complex(0,1.6), Complex(0,1.6)],
           [Complex(0,1), Complex(0,1.6), x]].rank
  end

  x = Complex(0, 1.6)
  y = Complex(0,Rational(16, 10))
  p x == y #=> true
  p f(x)   #=> 2
  p f(y)   #=> 3

> そのようなケースがあるとして、それは本質的に解決不能なんでしょ
> うか。おそらくはそうなんでしょうね。しかし、頻度はあまり多く
> なく、わかりやすくなく、説得力も十分ではないと。ふむ。

「頻度は多くない」は、1.6 という癖の有る浮動小数点数を問題に
している事です。一般の小数ではこのような事は起こりません。

「わかりやすくない」というのは、rank という一般には馴染みの
ない関数をしかも 3 次の行列に使っているところです。2 次行列
あるいは行列を使わない方法で自然な例が出せれば良かったのです
が。

「説得力が十分でない」のは、多くの人にとって rank はどうでも
いいからです。しかし、rank は重要な関数であり、またここで使わ
れている rank の計算アルゴリズムは、極めてポピュラーなもので、
一部の人に対しては一定の説得力はあります。

補足すると、「(例1)と(例2)は x と y が正確数か非正確数である
かで区別ができる」という批判があり得るのですが、次の例は x も
y も正確数となり、区別できない例です。

  # 例3
  require "rational"
  require "complex"
  require "matrix"

  def f(x)
    Matrix[[x, Complex(0,2)],
           [Complex(0,2), Complex(0,1)]].rank
  end

  x = Complex(0,4)
  y = Complex(0,Rational(4))
  p x == y #=> true
  p f(x)   #=> 2
  p f(y)   #=> 1

この(例3)に対しても様々な批判があり得ます。例えば、「これは
Integer#/ に責任があるのであって、Complex にはない」、「x と
y を区別するのにクラスを用いる必要があるのか、別の述語を考え
たらどうか」、「そもそもそのような特殊なケースを考慮するため
に数値システムをいじるべきではない」、「ComplexFloat を導入し
てもこの問題が解決されるわけではない。これが ComplexFloat を
導入する根拠になるのか？」等です。

それぞれに対して、再反論は可能ですが、再々反論も可能で、再々々
反論、再々々々反論と続きそうです。

というわけで、(例1)、(例2)、(例3)は、それなりですが、概して
「説得力が十分ではない」と言われてしまってもしかたがない。

> ここに説得力があり、問題が具体的であれば、それを解決するため
> のアイディアが無いかみんなで知恵を絞る余地はあると思うのです
> が、当の本人があきらめているようだしなあ。

そうです。