View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2012
Re: Why is complex being deprecated again?
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
April 16, 2012
Re: Why is complex being deprecated again?
On 15/04/12 23:37, Tove wrote:
> On Sunday, 15 April 2012 at 21:09:13 UTC, Lars T. Kyllingstad wrote:
>>
>> 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.
>> Furthermore, the imaginary numbers have the unfortunate property of
>> not being closed under multiplication and division, which is
>> troublesome for generic code:
>>
>> ireal x;
>> x *= x; // boom
>>
>> It seems nobody noticed, but I did in fact rewrite all of std.complex
>> two years ago (almost to the day) in preparation for the deprecation
>> of the built-in types. If there is anything missing from the module, I
>> will be happy to add it.
>>
>> -Lars
>
> The quote on the 'Semantics' section has a counter example...
> http://dlang.org/cppcomplex.html
>

See my reply to Stewart.

-Lars
April 16, 2012
Re: Why is complex being deprecated again?
On 15/04/12 23:37, Caligo wrote:
> On Sun, Apr 15, 2012 at 4:09 PM, Lars T. Kyllingstad
> <public@kyllingen.net>  wrote:
>>   If there is anything missing from the module, I will be
>> happy to add it.
>>
>> -Lars
>
> How about Quaternions?

If such were to be added, I think it would be better to put them in a 
separate std.quaternion module.

-Lars
April 16, 2012
Re: Why is complex being deprecated again?
On 16/04/12 00:31, bearophile wrote:
> Lars T. Kyllingstad:
>
>> If there is anything missing from the module, I will be happy to add it.
>
> You have seen std.math.expi, that returns a creal using the instructions
> sincos plus a registers swap (so it returns complex(cos,sin)). Maybe
> it's worth adding to Phobos a fully inlinable core.bitop.sincos
> intrinsic that performs just the sincos.

You're right, expi() should be added.  I remember that being on my to-do 
list, but I don't know why I skipped it.

-Lars
April 16, 2012
Re: Why is complex being deprecated again?
On Monday, 16 April 2012 at 06:06:12 UTC, Lars T. Kyllingstad 
wrote:
> 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

Sorry, that would be eight.  I forgot

     infinity
    -infinity
     i * infinity
    -i * infinity

which seems to be what the comparison page calls for.

-Lars
April 16, 2012
Re: Why is complex being deprecated again?
On 15/04/12 06:20, Andrei Alexandrescu wrote:
> On 4/14/12 10:10 PM, Mehrdad wrote:
>> Why is complex being phased out?
>> What happened to all this? http://dlang.org/cppcomplex.html
>
> I don't think that page makes a compelling argument, but I'm not an
> expert. If Walter and Don agree, I'd remove the page.
>
> Andrei


I agree, I think that page should be killed.

The efficiency argument is valid but reduces to this: The complier 
*MUST* be able to generate equally good from a library type, as from a 
built-in language type.
Once we've reached that point, we can remove the built-in type.

The correctness issue is a good argument for implementing complex 
functions correctly (basically, you should do your branch cuts on the 
negative real axis, whenever possible). But to go from there to 
requiring that the language has a pure imaginary type is not convincing.

We don't have a 'negint' type for negative integers, why have a pure 
imaginary type?
April 16, 2012
Re: Why is complex being deprecated again?
On 16/04/2012 07:06, Lars T. Kyllingstad wrote:
<snip>
> For any standard type (built-in or library) to be useful, it has to actually be used for
> something.

You mean someone has to use it in order to prove that it's usable and therefore useful? 
Well, if a feature isn't usable, it's probably due to something wrong with its design. 
And in many cases it's a reason to rethink the design, rather than throw the feature out 
of the window.

> And in all my years of using D, I have never seen a *single* real-world use of
> the pure imaginary types.

How many of those years you spent "using" D did you spend looking at other people's 
real-world applications written in it?

Of these, how many have a focus on number crunching?

And of these, how many use complex numbers?

It's bound to be a rarely used feature.  But "nobody's using it" is a prime example of a 
self-fulfilling prophecy if it leads to the feature's removal.

Do you feel the SETI Institute should have given up years ago?

> 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.

This doesn't cover the case of multiplying a complex number by an imaginary number.  In 
the absence of imaginary types, one would have to use complex(-z.im * k, z.re * k), just 
because z * complex(0, k) isn't guaranteed to produce the correct result.  Seems a bit 
silly.  Or have you another suggestion for dealing with this?

<snip>
> 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".
<snip>

But the Riemann sphere is only one of the various possible extended complex planes.  You 
could just as well use the polar circle of infinities, the cartesian square of infinities, 
or the real projective plane model (by which -∞ = ∞, but ∞i, ∞(2+i), etc. are distinct).

Stewart.
April 16, 2012
Re: Why is complex being deprecated again?
Le 16/04/2012 08:09, Lars T. Kyllingstad a écrit :
> On 15/04/12 23:37, Caligo wrote:
>> On Sun, Apr 15, 2012 at 4:09 PM, Lars T. Kyllingstad
>> <public@kyllingen.net>  wrote:
>>>   If there is anything missing from the module, I will be
>>> happy to add it.
>>>
>>> -Lars
>>
>> How about Quaternions?
> 
> If such were to be added, I think it would be better to put them in a
> separate std.quaternion module.
> 
> -Lars
Or rather std.math.quaternion
April 16, 2012
Re: Why is complex being deprecated again?
On Monday, 16 April 2012 at 11:27:29 UTC, Stewart Gordon wrote:
> On 16/04/2012 07:06, Lars T. Kyllingstad wrote:
> <snip>
>> For any standard type (built-in or library) to be useful, it 
>> has to actually be used for
>> something.
>
> You mean someone has to use it in order to prove that it's 
> usable and therefore useful? Well, if a feature isn't usable, 
> it's probably due to something wrong with its design. And in 
> many cases it's a reason to rethink the design, rather than 
> throw the feature out of the window.
>
>> And in all my years of using D, I have never seen a *single* 
>> real-world use of
>> the pure imaginary types.
>
> How many of those years you spent "using" D did you spend 
> looking at other people's real-world applications written in it?
>
> Of these, how many have a focus on number crunching?
>
> And of these, how many use complex numbers?

This is why I said: "[...] 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 [...]"


> It's bound to be a rarely used feature.  But "nobody's using 
> it" is a prime example of a self-fulfilling prophecy if it 
> leads to the feature's removal.

I'm not saying it is *never* useful.  I'm saying I don't think 
it's useful *enough* to warrant inclusion in the standard library.


> Do you feel the SETI Institute should have given up years ago?

I don't really see the similarity between SETI and Phobos.


>> 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.
>
> This doesn't cover the case of multiplying a complex number by 
> an imaginary number.  In the absence of imaginary types, one 
> would have to use complex(-z.im * k, z.re * k), just because z 
> * complex(0, k) isn't guaranteed to produce the correct result.
>  Seems a bit silly.  Or have you another suggestion for dealing 
> with this?

Yes:  Define Complex!T so it produces the desired result in each 
case.


> <snip>
>> 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".
> <snip>
>
> But the Riemann sphere is only one of the various possible 
> extended complex planes.  You could just as well use the polar 
> circle of infinities, the cartesian square of infinities, or 
> the real projective plane model (by which -∞ = ∞, but ∞i, 
> ∞(2+i), etc. are distinct).

My point exactly.

-Lars
April 16, 2012
Re: Why is complex being deprecated again?
On 4/16/12 4:21 AM, Don Clugston wrote:
> On 15/04/12 06:20, Andrei Alexandrescu wrote:
>> On 4/14/12 10:10 PM, Mehrdad wrote:
>>> Why is complex being phased out?
>>> What happened to all this? http://dlang.org/cppcomplex.html
>>
>> I don't think that page makes a compelling argument, but I'm not an
>> expert. If Walter and Don agree, I'd remove the page.
>>
>> Andrei
>
>
> I agree, I think that page should be killed.

Done.


Thanks,

Andrei
1 2 3 4
Top | Discussion index | About this forum | D home