Talk:Arithmetic/Complex
Ada and C++ both still need negation. I forgot to put it in the Java example before but I added I it later. Sorry for the confusion. --Mwn3d 10:13, 9 March 2008 (MDT)
- The Ada entry has been amended to include negation. --Waldorf 14:40, 9 March 2008 (MDT)
I believe the C example is incorrect. The current written example relies upon operator overloading which is not supported by C99.--Waldorf 09:10, 11 March 2008 (MDT)
- I did some looking; there are complex built-in types in the C99 standard, with defined implicit casts up and down to the other numeric primitives. --IanOsgood 10:36, 11 March 2008 (MDT)
- How could an implicit cast from a complex type to a floating point or integer type result in a valid value? Simple integers and floats cannot represent both the real and imaginary parts of the complex number.--Waldorf 17:36, 11 March 2008 (MDT)
- The code example only uses conversions from real types to complex types; but complex types can be converted to real types by discarding the imaginary part. --Spoon! 18:21, 11 March 2008 (MDT)
- The code example includes addition, multiplication, and negation using the language-defined operators. In those instances no conversion is possible without loosing information (the imaginary part of the complex number). Without operator overloading no correct result can be obtained. Any implicit conversion will result in loss of the imaginary part of the complex number. The C example must therefore be incorrect.--Waldorf 07:18, 13 March 2008 (MDT)
- The only ways I can think of to convert a complex number to a purely real number without losing information is to find the length of the number in the complex plane or convert it to polar form. You can't reconstruct the original number from the length, so that shouldn't be done for this conversion. The polar form still requires two parts (magnitude and angle), so it's not really a primitive (at least in C). I don't know why anyone would want to convert a complex number to a real number when you can just get the "real part." The C example is not incorrect as the task is written because the task says nothing about casting to anything. A complex number is a complex number and that's all it will ever be. Any casts to purely real types should have information loss. (int)(2.5 + 3.2i) should be 2. (Complex)(3*5) should be 15 + 0i. That's how anyone could expect it to work. --Mwn3d 08:49, 13 March 2008 (MDT)
- The code example includes addition, multiplication, and negation using the language-defined operators. In those instances no conversion is possible without loosing information (the imaginary part of the complex number). Without operator overloading no correct result can be obtained. Any implicit conversion will result in loss of the imaginary part of the complex number. The C example must therefore be incorrect.--Waldorf 07:18, 13 March 2008 (MDT)
- The code example only uses conversions from real types to complex types; but complex types can be converted to real types by discarding the imaginary part. --Spoon! 18:21, 11 March 2008 (MDT)
- How could an implicit cast from a complex type to a floating point or integer type result in a valid value? Simple integers and floats cannot represent both the real and imaginary parts of the complex number.--Waldorf 17:36, 11 March 2008 (MDT)