Complex Numbers

[Former user]

Originally reported on Google Code with ID 47

Would it be hard to implement a complex number system and implement the 
complex capaple functions (sin, cos, e^....) also.

Maybe even some option to toggle the output format (rectengular (a+jb), 
polar r*e(j*angle))

And a option what sqrt(-1) is: i or j.

TIA
Daniel

Reported by [e-mail] on 2007-06-07 15:45:33

[Former user]

``` Hi, thank you for your suggestion. I'm marking this as an enhancement instead of a defect, though. We haven't talked about complex number feature introduction but it has been in my mind lately. I'd say that should be one of the enhancements for either version 0.9 or 1.0. ```

Reported by `helder.pereira.correia` on 2007-06-07 18:03:34 - Status changed: `Accepted` - Labels added: Type-Enhancement - Labels removed: Type-Defect

[Former user]

Reported by `helder.pereira.correia` on 2007-06-12 09:51:59 - Labels added: Milestone-Release1.0

[Former user]

Reported by `helder.pereira.correia` on 2007-12-16 21:45:05 - Status changed: `New` - Labels removed: Milestone-Release1.0

[Former user]

``` Wolf: regarding the parser, I think there's no problem adopting the convention c(3;4) or similar to represent the complex number 3+4j (or 3+4j). But what would be the effort to add support for complex numbers to floatnum? I guess it should start by the concept that a real number is a complex number with no imaginary part. Could we build it easily from there? ```

Reported by `helder.pereira.correia` on 2008-01-16 00:15:31

[Former user]

``` I obviously meant "(or 3+4i)"... ```

Reported by `helder.pereira.correia` on 2008-01-16 00:16:04

[Former user]

``` The parser can be adapted within short time, because only literal complex constants have to be introduced. The grammar does not change because complex numbers behave in many respects the same way real numbers do. But: one core problem is to replace the HNumber class by something more flexible, Actually, even the current version would benefit from such a replacement, because I have difficulties in expressing logic data types like 32-bit integers and their special behaviour in HNumber. I think the best is a Variant type. Not only would this help to solve my current problems with logic data representations, one could easily extend this concept to other numerical data types like fractions, dates, time etc., and of course complex numbers too. Because of the advantages are so overwhelming, I am already working on such a replacement.

Most problematic is the high precision evaluation of higher mathematical functions in the complex plane. Even basic functions like log, sqrt need some extra consideration, because they are multi-valued. But when it comes to functions like Gamma or erf... oh oh.

Don't expect complex numbers to be in reach of version 0.10. ```

Reported by `wolf.lammen` on 2008-01-16 02:00:36

[Former user]

```

Don't expect complex numbers to be in reach of version 0.10.

Of course not. In fact, I'm not even considering it for 0.11, because of its "complexity". Re-designing HMath is definitely the best way to go. Even because then we can adapt it to rational numbers too, which is very important and a killer feature IMO. And I still think we can use a simplified syntax such as "c(2;3) + 3,432 * pi / r(9;7)", where "r" (or "rat") returns the rational number 9/7.

But for now let's focus on 0.10 :) ```

Reported by `helder.pereira.correia` on 2008-01-16 02:24:41

[Former user]

Would be a nice and useful feature. Any chance to get it?

Reported by gabriel.gross on 2014-01-30 08:46:53

[Former user]

Hi Gabriel. I'd love to offer this, but it requires heavy changes at the math engine
and parser levels. Most likely not at the very top of my TODO list, unfortunately.

Reported by helder.pereira.correia on 2014-01-30 09:10:40

[Former user]

Issue 565 has been merged into this issue.

Reported by helder.pereira.correia on 2015-08-03 17:05:05

[Hadrien Theveneau]

I just made some test implementation of complex numbers. I will make a pull request as soon as I finish to check it in depth.

[Helder Correia]

Thanks, @thadrien Looking forward to it. What is the syntax you have in mind?

[Hadrien Theveneau]

Syntax I have in mind is Python-like: i or j suffix to numbers, for example 1i or 1j. Full complex numbers are written like 1+19j. I rely on the evaluator for this.

The version I have works pretty good, but I have still one problem: some functions return results like 1+1E-81j instead of simply 1.

Btw, just a question before my pull request : the test programs have no .pro file to build them. I made some files to easily build them. Should I add these files in the commit ?

[Hadrien Theveneau]

Just PR : see pull request 13.

Have a nice day.

[Helder Correia]

@thadrien IIRC only the CMake project file builds the tests. Are you able to use cmake?

[Hadrien Theveneau]

@heldercorreia cmake is not installed on my system. I use qmake because it is included on Qt toolchain.

[Helder Correia]

Shouldn't 'i' be also supported like 'j'?

[Hadrien Theveneau]

@heldercorreia: Yes it should definitely.

[Pol Welter]

Personally I don't mind using either one. Typically engineers use j (so not to confuse it with electric current) while we physicists prefer i.

Again, I don't want to clutter the namespace too much.

[Helder Correia]

Don't worry about the namespace. People WILL ask for 'i', trust me :)

[Pol Welter]

Just i=j, and they are good to go :)

Seriously. That's it.

[Helder Correia]

Fair enough. Should be highlighted in the manual.