www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - Complex numbers

reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
The site says they are deprecated. In the same time it is real 
pain to use core.stdc.complex with std.complex.
Oct 16 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 16 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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
Oct 17 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 17 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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
Oct 17 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 17 2016
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 18 2016
prev sibling parent Martin Nowak <code dawg.eu> writes:
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.
Oct 19 2016