Talk:Arithmetic/Complex: Difference between revisions
Content added Content deleted
(Wrong is still wrong.) |
(I see now...sorry) |
||
| Line 8: | Line 8: | ||
:::::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. --[[User:Mwn3d|Mwn3d]] 08:49, 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. --[[User:Mwn3d|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.--[[User:Waldorf|Waldorf]] 09:30, 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.--[[User:Waldorf|Waldorf]] 09:30, 13 March 2008 (MDT) |
||
:::::::OK...looking into it you're right. I offer two solutions. 1: I added an example which defines a struct and the desired operations, 2: rework the complex.h solution to use creal and cimag functions (from [http://en.wikipedia.org/wiki/Complex.h complex.h]) as part of other functions to do the math. --[[User:Mwn3d|Mwn3d]] 10:01, 13 March 2008 (MDT) |
|||
Revision as of 16:01, 13 March 2008
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)
- 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)
- 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)