The complex type in std.complex restricts the real/imaginary
parts of the number to be float/double/real.  I am curious to
know if there is a reason why integral types are not permitted. I
checked the C++ equivalent and it does not have the same
requirement.

I mention this because some of my work is done with radar
satellite images. All pixels in such an images are stored as
complex numbers, but in all cases I am aware of they are stored a
short int values. Most software that operates on the images uses
complex<short> (most of it is C++).

Is there any reason why complex numbers in D's standard lib must
be of non-integral types?  I believe in C++ the type is optimized
for floating point values, but allows other types.

On 11/18/13 5:44 PM, Craig Dillabaugh wrote:
> The complex type in std.complex restricts the real/imaginary
> parts of the number to be float/double/real.  I am curious to
> know if there is a reason why integral types are not permitted. I
> checked the C++ equivalent and it does not have the same
> requirement.
>
> I mention this because some of my work is done with radar
> satellite images. All pixels in such an images are stored as
> complex numbers, but in all cases I am aware of they are stored a
> short int values. Most software that operates on the images uses
> complex<short> (most of it is C++).
>
> Is there any reason why complex numbers in D's standard lib must
> be of non-integral types?  I believe in C++ the type is optimized
> for floating point values, but allows other types.

The simple reason is we couldn't find appropriate applications. If you make a good argument, we'll include integral types as well. Submit an enhancement request on bugzilla including your example and let's take it from there.

Andrei

On Tuesday, 19 November 2013 at 02:03:05 UTC, Andrei Alexandrescu
wrote:
> On 11/18/13 5:44 PM, Craig Dillabaugh wrote:
>> The complex type in std.complex restricts the real/imaginary
>> parts of the number to be float/double/real.  I am curious to
>> know if there is a reason why integral types are not permitted. I
>> checked the C++ equivalent and it does not have the same
>> requirement.
>>
>> I mention this because some of my work is done with radar
>> satellite images. All pixels in such an images are stored as
>> complex numbers, but in all cases I am aware of they are stored a
>> short int values. Most software that operates on the images uses
>> complex<short> (most of it is C++).
>>
>> Is there any reason why complex numbers in D's standard lib must
>> be of non-integral types?  I believe in C++ the type is optimized
>> for floating point values, but allows other types.
>
> The simple reason is we couldn't find appropriate applications. If you make a good argument, we'll include integral types as well. Submit an enhancement request on bugzilla including your example and let's take it from there.
>
> Andrei
I will see if I can put something together.

Regards,
Craig

//Hijack

http://digitalmars.com/d/1.0/cppcomplex.html

> • Consider the formula (1 - infinity*i) * i which should produce (infinity + i). However, if instead the second factor is (0 + i) rather than just i, the result is (infinity + NaN*i), a spurious NaN was generated.
> • A distinct imaginary type preserves the sign of 0, necessary for calculations involving branch cuts.

Is this stuff no longer an issue?

-Shammah

On Saturday, 23 November 2013 at 04:37:19 UTC, Shammah Chancellor wrote:
> //Hijack
>
> http://digitalmars.com/d/1.0/cppcomplex.html
>
>> • Consider the formula (1 - infinity*i) * i which should produce (infinity + i). However, if instead the second factor is (0 + i) rather than just i, the result is (infinity + NaN*i), a spurious NaN was generated.
>> • A distinct imaginary type preserves the sign of 0, necessary for calculations involving branch cuts.
>
> Is this stuff no longer an issue?
>
> -Shammah

I believe D used to have builtin complex types, back in the old days. They have been removed (deprecated?) and replaced by the library type std.complex.

At least that is my understanding.

Craig

On 11/22/2013 09:22 PM, Craig Dillabaugh wrote:

> On Saturday, 23 November 2013 at 04:37:19 UTC, Shammah Chancellor wrote:
>> //Hijack
>>
>> http://digitalmars.com/d/1.0/cppcomplex.html
>>
>>> • Consider the formula (1 - infinity*i) * i which should produce
>>> (infinity + i). However, if instead the second factor is (0 + i)
>>> rather than just i, the result is (infinity + NaN*i), a spurious NaN
>>> was generated.
>>> • A distinct imaginary type preserves the sign of 0, necessary for
>>> calculations involving branch cuts.
>>
>> Is this stuff no longer an issue?
>>
>> -Shammah
>
> I believe D used to have builtin complex types, back in the old days.
> They have been removed (deprecated?)

It still compiles.

> and replaced by the library type
> std.complex.
>
> At least that is my understanding.

And it makes what Shammah Chancellor quoted even more interesting. cdouble and idouble still work correctly but std.complex produces "incorrect" result:

import std.stdio;
import std.complex;

void main()
{
    writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
    writeln((1L - ireal.infinity) * 1i);
}


The output:

inf-nani    <-- "incorrect" according to the quoted page
inf+1i      <-- correct

>
> Craig
>

Ali

"Craig Dillabaugh" <craig.dillabaugh@gmail.com> wrote in message news:izowcplookyzxrpzmoci@forum.dlang.org...
> On Saturday, 23 November 2013 at 04:37:19 UTC, Shammah Chancellor wrote:
>> //Hijack
>>
>> http://digitalmars.com/d/1.0/cppcomplex.html
>>
>>> . Consider the formula (1 - infinity*i) * i which should produce
>>> (infinity + i). However, if instead the second factor is (0 + i) rather
>>> than just i, the result is (infinity + NaN*i), a spurious NaN was
>>> generated.
>>> . A distinct imaginary type preserves the sign of 0, necessary for
>>> calculations involving branch cuts.
>>
>> Is this stuff no longer an issue?
>>
>> -Shammah
>
> I believe D used to have builtin complex types, back in the old days. They have been removed (deprecated?) and replaced by the library type std.complex.
>
> At least that is my understanding.
>
> Craig
>

They are not deprecated yet, but it has been 'planned' for a long time. It's one of those things where not deprecating them doesn't hurt anyone, so it isn't high priority.

On Saturday, 23 November 2013 at 08:18:35 UTC, Daniel Murphy wrote:
> They are not deprecated yet, but it has been 'planned' for a long time.
> It's one of those things where not deprecating them doesn't hurt anyone, so
> it isn't high priority.

Must say that, whatever the behind-the-scenes of the implementation, it seems a shame to lose the nice z = x + y*i notation.

OTOH I guess that could lead to ambiguous code, e.g.

    int i = 4;
    complex z = x + y*i;     // what does i mean here?

"Joseph Rushton Wakeling" <joseph.wakeling@webdrake.net> wrote in message news:pyjudfnteduztpporndj@forum.dlang.org...
> On Saturday, 23 November 2013 at 08:18:35 UTC, Daniel Murphy wrote:
>> They are not deprecated yet, but it has been 'planned' for a long time.
>> It's one of those things where not deprecating them doesn't hurt anyone,
>> so
>> it isn't high priority.
>
> Must say that, whatever the behind-the-scenes of the implementation, it seems a shame to lose the nice z = x + y*i notation.
>
> OTOH I guess that could lead to ambiguous code, e.g.
>
>     int i = 4;
>     complex z = x + y*i;     // what does i mean here?

I feel mostly the same way - except - I've never actually used them in my own code, and when I've built test cases for them while fixing other bugs I've found some horrific bugs in dmd.  This makes me think that _nobody_ is using them.  And if that's true, we might as well get rid of them.

eg https://d.puremagic.com/issues/show_bug.cgi?id=7594

Shammah Chancellor:
> //Hijack

More hijack, see also:
http://forum.dlang.org/thread/lxuhrynxujrujoksrvdi@forum.dlang.org

Bye,
bearophile