complex-numbers

The FFTW manual says that its fftw_complex type is bit compatible to std::complex<double> class in STL. But that doesn't work for me: #include <complex> #include <fftw3.h> int main() { std::complex<double> x(1,0); fftw_complex fx; fx = reinterpret_cast<fftw_complex>(x); } This gives me an error: error: invalid cast from type ‘std::complex<double>’ to type ‘double [2]’ What am I doing wrong? Re-write your code as follows: #include <complex> #include <fftw3.h> int main() { std::complex<double> x(1,0); fftw_complex fx; memcpy( &fx, &x, sizeof( fftw_complex ) ); } Every compiler I've used will

Here's two ways to enter the command in Matlab. I don't think there's any difference between them. However, the result is really different. So I wonder what's I missed in this situation. Here's the first input: >> A = [(-0.025+0.01i) -0.025; 3 (1-2i)]; >> B = [(5.7955+1.5529i) 0]'; >> I=inv(A)*B The output is like this: I = 1.0e+02 * -0.7063 - 1.2723i -1.1030 + 1.6109i Here's the second input: >> A = [(-0.025+0.01i) -0.025;3 (1-2i)]; >> B = [(5.7955+1.5529i);0]; >> I=inv(A)*B And the Matlab give me the result below: I = 2.44764705882354 - 145.499411764706i -176.067882352941 + 84.3624705882353i

I am wondering about the way Python (3.3.0) prints complex numbers. I am looking for an explanation, not a way to change the print. Example: >>> complex(1,1)-complex(1,1) 0j Why doesn't it just print "0"? My guess is: to keep the output of type complex. Next example: >>> complex(0,1)*-1 (-0-1j) Well, a simple "-1j" or "(-1j)" would have done. And why "-0"?? Isn't that the same as +0? It doesn't seem to be a rounding problem: >>> (complex(0,1)*-1).real == 0.0 True And when the imaginary part gets positive, the -0 vanishes: >>> complex(0,1) 1j >>> complex(0,1)*-1 (-0-1j) >>> complex(0,1)*-1*-1

The following code with VS2010 prints 0 , contrary to my expectations: #include <complex> #include <iostream> using namespace std; int main(void) { complex<int> z(20, 200); cout << abs<int>(z) << endl; return 0; } It works fine when the type is double . According to the C++ ISO spec, §26.2/2: The effect of instantiating the template complex for any type other than float , double or long double is unspecified. In other words, the compiler can do whatever it wants to when you instantiate complex<int> . The fact that you're getting 0 here is perfectly well-defined behavior from a language

Using gcc 4.9 I found that types generated with type literal for complex numbers are not the same as when created by conventional means, i.e.: typeid(complex<double>(0.0,1.0)) != typeid(1.0i) Am I making a mistake here? Is this a compiler bug or intended standard behavior? If intended standard behavior: What is the rationale behind? Adding the missing MCVE #include <complex> using std::complex; using namespace std::literals::complex_literals; #include <iostream> using std::cout; using std::endl; #include <typeinfo> int main(int argc, char* argv[]) { if (typeid(complex<double>(0.0, 1.0)) ==

According to the C++ ISO spec, §26.2/2: The effect of instantiating the template complex for any type other than float , double or long double is unspecified. Why would the standard authors explicitly add this restriction? This makes it unspecified, for example, what happens if you make complex<int> or a complex<MyCustomFixedPointType> and seems like an artificial restriction. Is there a reason for this limitation? Is there a workaround if you want to instantiate complex with your own custom type? I'm primarily asking this question because of this earlier question , in which the OP was

Playing with the NumPy concatenation and range building object r_ I stumbled over the following behavior: apparently, a complex step no matter whether real, imaginary or proper complex has its absolute value taken as the number of steps in a linspace like way. >>> import numpy as np >>> >>> np.r_[0:12:4] # start : stop : step array([0, 4, 8]) # that's expected >>> np.r_[0:12:4j] # start : stop : imaginary step array([ 0., 4., 8., 12.]) # that's in the docs >>> np.r_[0:12:4+0j] # real step of complex type ? array([ 0., 4., 8., 12.]) # this is not as far as I can tell # you can even do stuff