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

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?

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

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.

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

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.

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

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

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

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