The site says they are deprecated. In the same time it is real pain to use core.stdc.complex with std.complex.

On 10/16/2016 1:05 PM, Ilya Yaroshenko wrote:
> The site says they are deprecated. In the same time it is real pain to use
> core.stdc.complex with std.complex.

There's a tug of war going on to support C's ABI and not supporting complex as a native type. Probably the best way forward is to ensure that std.complex maps directly onto the C types.

On Sunday, 16 October 2016 at 20:56:08 UTC, Walter Bright wrote:
> On 10/16/2016 1:05 PM, Ilya Yaroshenko wrote:
>> The site says they are deprecated. In the same time it is real pain to use
>> core.stdc.complex with std.complex.
>
> There's a tug of war going on to support C's ABI and not supporting complex as a native type. Probably the best way forward is to ensure that std.complex maps directly onto the C types.

I would like to use native complex types in Mir instead of std.complex. D has not macro, only templates and mixins. This makes impossible to use complex arithmetic operations   the same way like normal arithmetic operations.

For example:

import ldc.attributes;
import std.complex;

pragma(LDC_no_moduleinfo);

@fastmath auto native_fma(cdouble a, cdouble b, cdouble c)
{
	return a * b + c;
}
->>>>
	.cfi_startproc
	vfmadd231sd	%xmm2, %xmm4, %xmm0
	vfnmadd231sd	%xmm3, %xmm5, %xmm0
	vfmadd231sd	%xmm2, %xmm5, %xmm1
	vfmadd231sd	%xmm3, %xmm4, %xmm1
	retq
	.cfi_endproc


@fastmath auto stdcomplex_fma(Complex!double a, Complex!double b, Complex!double c)
{
	return a * b + c;
}
->>>>
	.cfi_startproc
	vmulsd	%xmm4, %xmm2, %xmm6
	vmulsd	%xmm5, %xmm3, %xmm7
	vsubsd	%xmm7, %xmm6, %xmm6
	vmulsd	%xmm5, %xmm2, %xmm2
	vmulsd	%xmm4, %xmm3, %xmm3
	vaddsd	%xmm2, %xmm3, %xmm2
	vaddsd	%xmm6, %xmm0, %xmm0
	vaddsd	%xmm2, %xmm1, %xmm1
	retq
	.cfi_endproc

In addition, to generate stdcomplex_fma LDC generates 11900 assembler LOC of bloat. I am going to replace std.compex in Mir with native complex numbers, which are more user friendly in terms of optimisation and syntax.

Best regards,
Ilya

On 10/17/2016 3:48 AM, Ilya Yaroshenko wrote:
> [...]

This is worthy of another bugzilla issue.

One thing you can try is to reimplement std.complex using native complex numbers instead of the fields .re and .im, and see if that produces better code.

On Monday, 17 October 2016 at 18:48:17 UTC, Walter Bright wrote:
> On 10/17/2016 3:48 AM, Ilya Yaroshenko wrote:
> > [...]
>
> This is worthy of another bugzilla issue.
>
> One thing you can try is to reimplement std.complex using native complex numbers instead of the fields .re and .im, and see if that produces better code.

Does not help

On 10/17/2016 1:11 PM, Ilya Yaroshenko wrote:
> On Monday, 17 October 2016 at 18:48:17 UTC, Walter Bright wrote:
>> On 10/17/2016 3:48 AM, Ilya Yaroshenko wrote:
>> > [...]
>>
>> This is worthy of another bugzilla issue.
>>
>> One thing you can try is to reimplement std.complex using native complex
>> numbers instead of the fields .re and .im, and see if that produces better code.
>
> Does not help

Seems strange to me.

  cdouble

and:

  struct Complex { cdouble x; alias this x; }

should generate the same code.

On 10/16/2016 1:05 PM, Ilya Yaroshenko wrote:
> The site says they are deprecated. In the same time it is real pain to use
> core.stdc.complex with std.complex.

I've noticed that gcc generates significantly different code for these two functions:

  #include <complex.h>
  struct S { double re, im; };
  struct S foo(struct S* ps) { return *ps; }
  double complex bar(double complex *ps) { return *ps; }

The S versions are much worse. This is not good.

The ABIs are, sadly, different as well. The following should behave equivalently as far as ABI goes:

  double complex

  struct complex { double re, im; }

  double[2]

but alas, they do not.

On Sunday, 16 October 2016 at 20:05:22 UTC, Ilya Yaroshenko wrote:
> The site says they are deprecated. In the same time it is real pain to use core.stdc.complex with std.complex.

Would be great to avoid subjective opinions such as "is a real pain to work with" and instead properly explain the problem while also showing some examples of how important interaction with C's complex is.