On 15/04/12 23:56, Stewart Gordon wrote:
On 15/04/2012 22:09, Lars T. Kyllingstad wrote:
On 15/04/12 14:29, Stewart Gordon wrote:
<snip>
My impression was that the plan is to deprecate it once the stuff in
std.complex is complete. std.complex has clearly grown since that
discussion, but it still needs a pure imaginary type (and I don't know
what else at the moment).
I absolutely do not think it does. There is nothing you can do with a
pure imaginary type
that you cannot do with a complex type.
<snip>
What proof have you of this - and in particular, that the rationale for
pure imaginary types on the comparison page is wrong?
For any standard type (built-in or library) to be useful, it has to
actually be used for something. And in all my years of using D, I have
never seen a *single* real-world use of the pure imaginary types.
The reason the imaginaries are so seldomly used is precisely because
there are so few things you can do with them. Basically, if you do
anything beyond addition and subtraction, and multiplication with a real
number, you are back in the complex plane. And if those operations are
all you need, the real line is just as good as the imaginary line, and
you might as well fake it with a real floating-point type.
Yes, complex and imaginary numbers have some quirks and subtleties that
need to be taken into consideration, but I see this as an implementation
issue with the complex type, and not a justification for the existence a
pure imaginary type.
All that said, however, if anyone can demonstrate that the pure
imaginary types are in fact used in a substantial body of real-world
code, I will be happy to change my stance on the above.
Now, to address the rationale for pure imaginary types on
http://dlang.org/cppcomplex.html.
Firstly, in light of what I've said above (and given that I am not wrong
<g>), the efficiency issue would appear moot. That leaves the semantic
issues. The quote by prof. Kahan mentions that the identities
sqrt(conj(z))==conj(sqrt(z)) and log(conj(z))==conj(log(z)) should hold
even when z is a negative real number. IIRC, f(conj(z))==conj(f(z))
holds when f is analytic, but both sqrt and log (conventionally) have
branch cuts along the negative real axis.
Case in point: Neither of these identities hold in Mathematica, which
is considered the state of the art in mathematical software:
Conjugate[Log[-1]] evaluates to -I Pi
Log[Conjugate[-1]] evaluates to I Pi
Conjugate[Sqrt[-1]] evaluates to -I
Sqrt[Conjugate[-1]] evaluates to I
The page also mentions some identity involving infinities which is
supposed to hold. This is not obviously true. An IEEE infinity has
very little to do with mathematical infinity, it is just a special value
which means either "this number is too large to be represented by the
given number of bits", or "this is a result of a divide by positive
zero". (The signedness of zero is another quirk of IEEE floats.
Basically, -0.0 means "a negative number which is arbitrarily close to
zero", and dividing by it yields an arbitrarily large negative number,
i.e. -double.infinity. Mathematically, something/0 makes no sense at
all. Personally, I think IEEE made a mistake in defining FP numbers in
this way.)
It is true that the real line can be extended with elements called plus
and minus infinity (affinely extended real line, see
https://en.wikipedia.org/wiki/Extended_real_number), and the IEEE floats
can be said to approximate this system, but this does not generalise
directly to complex numbers. The extended complex plane (see
https://en.wikipedia.org/wiki/Riemann_sphere) only has one "infinity".
How should the IEEE system be extended to the complex plane, anyway? If
we look at the problem in terms of the cartesian representation, we may
want four infinities, namely:
infinity + i * infinity
-infinity + i * infinity
infinity - i * infinity
-infinity - i * infinity
If, on the other hand, we take a polar view of things, there are MANY
possibilies:
infinity * exp(i * r) // where r is any real number
Now, we may invent our own rules for operations with complex numbers
involving infinities, if nothing else for predictability in
calculations. (And maybe such rules are well established already?) But
it does not justify the existence of a pure imaginary type.
-Lars
