November 19, 2013 std.complex | ||||
---|---|---|---|---|
| ||||
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. |
November 19, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | 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
|
November 19, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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
|
November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | //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 |
November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shammah Chancellor | 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
|
November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | 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 |
November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | "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. |
November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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?
|
November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | "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 |
November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shammah Chancellor | Shammah Chancellor: > //Hijack More hijack, see also: http://forum.dlang.org/thread/lxuhrynxujrujoksrvdi@forum.dlang.org Bye, bearophile |
Copyright © 1999-2021 by the D Language Foundation