12,623,882 members (27,887 online)
alternative version

28.5K views
13 bookmarked
Posted

# A C# class for complex numbers

, 3 Jul 2007 CPOL
 Rate this:
Implementation of the most common functions of complex numbers.

## Introduction

Here you go: a simple but mathematically rigorous implementation of complex numbers in one small C# library. No problem in square rooting negative numbers anymore!

## Functions

• Absolute value
• Argument
• Conjugation
• Cosine
• Exponential function
• Exponentiation
• Division
• Hyperbolic functions (Sinh, Cosh, Tanh, Coth, Sech, Csch)
• Logarithm
• Multiplication
• Sine
• Square root
• Subtraction

## Using the code

Either add a reference to CompLib.dll to your project, or directly use the class Complex.cs within your project.

The actual usage is intuitive:

```Complex I = Complex.I; // imaginary unit
Complex a = new Complex(1, 3); // inits a = 1+3i
Complex a2 = 1 + 3 * I; // a equals a2

Complex z = Complex.Pow((Complex.Sin(1/(1+I))), 1/3);```

## Points of interest

One more thing: Complex logarithm is not a unique operation; the main value is computed as is common in the CAS world. E.g., the equation z^4 = -1 has four complex solutions, but only one is returned when trying "`z = Complex.Sqrt(Complex.Sqrt(-1));`" (as does Maple, for instance). This is due to the computation of the exponentiation:

`Pow(a,b) := Exp(b * Log(a))`

## History

### Coming soon

• init complex number with format string such as "3+4i" using regex.

### Update July 3, 2007 #2

• Major bug in Arg() fixed (thanks Petr Stanislav!); this affects `Log()`, `Pow()`, and `Sqrt()`.

### Update June 10, 2007

• Replaced ^-operator with "`public static Complex Pow`", similar to `Math.Pow`.

### Update June 7, 2007

• Added `Zero` and `One` as constants (e.g., use "`Complex z = Complex.One;`" instead of "`Complex z = new Complex(1)`").
• Major bug of division operation removed (using `a/b = a*Conj(b)*(1/(Abs(b)*Abs(b))` now).
• `ToString` method bug fixed.

## Share

 Germany
No Biography provided

## You may also be interested in...

 Pro

 First Prev Next
 code licence enrico.deg10-Jun-10 23:53 enrico.deg 10-Jun-10 23:53
 struct instead of class Member 190663510-Jun-08 2:17 Member 1906635 10-Jun-08 2:17
 Re: struct instead of class PIEBALDconsult2-Apr-09 13:56 PIEBALDconsult 2-Apr-09 13:56
 7-Zip will extract Dom Rositas20-Jun-07 17:22 Dom Rositas 20-Jun-07 17:22
 Re: 7-Zip will extract [modified] hanzzoid3-Jul-07 3:19 hanzzoid 3-Jul-07 3:19
 WinZip unknown compression type Dom Rositas20-Jun-07 8:49 Dom Rositas 20-Jun-07 8:49
 Cannot extract files from ZIP archive Tom14-Jun-07 4:54 Tom1 4-Jun-07 4:54
 Re: Cannot extract files from ZIP archive Tom118-Jun-07 6:39 Tom1 18-Jun-07 6:39
 Exponentiation ALWAYS binds more strongly than multiplication. sherifffruitfly3-Jun-07 12:08 sherifffruitfly 3-Jun-07 12:08
 Re: Exponentiation ALWAYS binds more strongly than multiplication. Keith Rule3-Jun-07 21:16 Keith Rule 3-Jun-07 21:16
 Re: Exponentiation ALWAYS binds more strongly than multiplication. peterchen3-Jun-07 23:20 peterchen 3-Jun-07 23:20
 I think sherifffruitfly is right, and using the XOR-Operator for pow is dangerous. The whole point of operator overloading is to make expressions more intuitive, and close to the "problem domain". With overloading pow, you seem to extend that, but introduce a difference that may be sublte but devastating (depending on the context it is used). It would be OK if all other operators would generally evaluate from left to right and parantheses for mathematically correct evaluation would always be required. In C++, this already has been discussed to death. Virtually all of the discussion, however, is the inability to overload a exponentiation operator. So C# could define a ** operator, and make millions happy We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CPMy first real C# project | Linkify!|FoldWithUs! | sighist
 Re: Exponentiation ALWAYS binds more strongly than multiplication. hanzzoid3-Jul-07 3:15 hanzzoid 3-Jul-07 3:15
 Re: Exponentiation ALWAYS binds more strongly than multiplication. PIEBALDconsult2-Apr-09 13:59 PIEBALDconsult 2-Apr-09 13:59
 Re: Exponentiation ALWAYS binds more strongly than multiplication. sherifffruitfly2-Apr-09 14:22 sherifffruitfly 2-Apr-09 14:22
 Re: Exponentiation ALWAYS binds more strongly than multiplication. PIEBALDconsult2-Apr-09 17:28 PIEBALDconsult 2-Apr-09 17:28
 Last Visit: 31-Dec-99 19:00     Last Update: 4-Dec-16 10:26 Refresh 1