November 23, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On 2013-11-23 14:02:38 +0000, Daniel Murphy said:
> "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
I disagree. I was using them for physics simulations. They are very useful for the computational physics community. Just because most people are still using FORTRAN does not mean they won't switch eventually.
-Shammah
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shammah Chancellor | On Saturday, 23 November 2013 at 15:13:22 UTC, Shammah Chancellor wrote:
> I disagree. I was using them for physics simulations. They are very useful for the computational physics community. Just because most people are still using FORTRAN does not mean they won't switch eventually.
Would it cause you any particular disadvantage to use the library std.complex rather than the built-in complex type?
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | On 2013-11-24 15:50:46 +0000, Joseph Rushton Wakeling said:
> On Saturday, 23 November 2013 at 15:13:22 UTC, Shammah Chancellor wrote:
>> I disagree. I was using them for physics simulations. They are very useful for the computational physics community. Just because most people are still using FORTRAN does not mean they won't switch eventually.
>
> Would it cause you any particular disadvantage to use the library std.complex rather than the built-in complex type?
It would if the they don't work correctly. There needs to be an Imaginary type and some proper operations between complex and imaginary types. That doesn't seem to be the case currently. I personally think having the built-in type is very helpful. However, I can understand from a language perspective that having "i" around is hard for the parser.
Also, the argument "If complex/imaginary is built-in, why not have quaterions also" seems to imply that it should be a library type.
-Shammah
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On 23/11/13 08:43, Ali Çehreli wrote:
> 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
It's because 0.0L * (-real.infinity) evaluates to nan.
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
> On 23/11/13 08:43, Ali Çehreli wrote:
>> 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
>
> It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report?
Andrei
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2013-11-24 18:00:45 +0000, Andrei Alexandrescu said:
> On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
>> On 23/11/13 08:43, Ali Çehreli wrote:
>>> 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
>>
>> It's because 0.0L * (-real.infinity) evaluates to nan.
>
> Has this been submitted as a bug report?
>
> Andrei
It's more a fundamental problem with a complex type in general. C++ has this issue as well. You need a purely imaginary type with the appropiate operations between Complex and Imaginary defined.
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shammah Chancellor | 24-Nov-2013 22:03, Shammah Chancellor пишет: > On 2013-11-24 18:00:45 +0000, Andrei Alexandrescu said: > >> On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote: >>> On 23/11/13 08:43, Ali Çehreli wrote: >>>> 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 >>> >>> It's because 0.0L * (-real.infinity) evaluates to nan. >> >> Has this been submitted as a bug report? >> >> Andrei > > It's more a fundamental problem with a complex type in general. C++ > has this issue as well. You need a purely imaginary type with the > appropiate operations between Complex and Imaginary defined. > Can't it just check for the real part being exactly zero and special- case multiplication for that? -- Dmitry Olshansky |
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shammah Chancellor | Shammah Chancellor:
> It's more a fundamental problem with a complex type in general.
> C++ has this issue as well. You need a purely imaginary type with the appropiate operations between Complex and Imaginary defined.
Can't you add a new name to std.complex to implement the purely imaginary type?
Bye,
bearophile
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shammah Chancellor | On 11/24/13 10:03 AM, Shammah Chancellor wrote:
> On 2013-11-24 18:00:45 +0000, Andrei Alexandrescu said:
>
>> On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
>>> On 23/11/13 08:43, Ali Çehreli wrote:
>>>> 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
>>>
>>> It's because 0.0L * (-real.infinity) evaluates to nan.
>>
>> Has this been submitted as a bug report?
>>
>> Andrei
>
> It's more a fundamental problem with a complex type in general. C++
> has this issue as well. You need a purely imaginary type with the
> appropiate operations between Complex and Imaginary defined.
But that originates as a call to multiplication between two Complex numbers. Can't the problem be addressed at that level?
Andrei
|
November 24, 2013 Re: std.complex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2013-11-24 18:37:51 +0000, Andrei Alexandrescu said: > But that originates as a call to multiplication between two Complex numbers. Can't the problem be addressed at that level? > > Andrei I don't believe so because IEEE floats define inf*0 to be NaN. You would have to check to see if rhs.re == 0 || lhs.re == 0 and then just return zero. Somewhat unfortunate. You really do need an imaginary type for reasons specified in the original page here: http://digitalmars.com/d/1.0/cppcomplex.html -Shammah |
Copyright © 1999-2021 by the D Language Foundation