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)
C99 example incorrect?
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)
- I agree with what you say. The task requires addition and multiplication of two complex numbers, and inversion and negation of a single complex number. The C solution uses C arithmetic operators. C99 does not provide operator overloading. This means that the arithmetic operators can only be used if implicit conversion to a primitive type occurs. Either the example is wrong because it improperly uses arithmetic operators for complex arithmetic, or it is wrong because implicit conversions result in real arithmetic, not complex arithmetic. The truth can be easily demonstrated by printing the results of the operations in C.--Waldorf 09:30, 13 March 2008 (MDT)
- Waldorf, I don't know what you're going on about. When I compile this with gcc -std=c99 I get correct results (once I corrected the constants). The implicit conversions only happen when there are type mismatches, but all the operations are between complex types. For 1.0/a, there is an up conversion to 1+0i before dividing. The standard operators are all defined correctly for complex types, and other library functions like conj() for the conjugate are defined for complex-specific operations. --IanOsgood 10:47, 13 March 2008 (MDT)
- As for operator overloading, perhaps you are confusing this with operator overloading for user defined types. This is trivially true for C because you cannot define functions that overload the symbolic infix operators (as opposed to the operator+() overloading in C++). However operator overloading for built-in types is well supported in C. C99 happens to add complex numbers as built-in types. --IanOsgood 11:10, 13 March 2008 (MDT)
- To avoid this kind of argument in the future, I am changing the task requirements to require printing the results. --IanOsgood 11:10, 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)
Complex conjugate
ooRexx
say c1/c1 seems to be incorrect!?! --Walterpachl (talk) 19:47, 12 May 2014 (UTC)
- Yea, I get 0.44+0.08i so flagged it as incorrect. --Paddy3118 (talk) 20:30, 12 May 2014 (UTC)
- I've corrected the inv method which was incorrect --Walterpachl (talk) 19:22, 14 May 2014 (UTC)
Formulae made invisible by under-tested cosmetic edits at 01:25, 25 August 2016
Under-tested cosmetic edits made to the task page at 01:25, 25 August 2016, including the injection of spaces around expressions in <math> tags, have left some or all of the task description formulae completely invisible to all browsers which display the graphic file version of formulae rather than processing the MathML (this is, in fact, the majority of browsers). The MediaWiki processor does not currently expect such spaces, and generates syntactically ill-formed HTML if they are introduced. Other aspects of these cosmetic edits may further compound the problem. Hout (talk) 10:36, 24 September 2016 (UTC)
Assembly
Is it cheating if I consider to be 255 since that's negative 1 on an 8 bit computer? --Puppydrum64 (talk) 20:39, 12 September 2021 (UTC)
