Complex Numbers

[GoogleCodeExporter]

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

Original issue reported on code.google.com by dany0...@gmx.at on 7 Jun 2007 at 3:45

[GoogleCodeExporter]

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.

Original comment by helder.p...@gmail.com on 7 Jun 2007 at 6:03

• Changed title: Complex Numbers
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by helder.p...@gmail.com on 12 Jun 2007 at 9:51

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Original comment by helder.p...@gmail.com on 16 Dec 2007 at 9:45

• Changed state: New
• Removed labels: Milestone-Release1.0

[GoogleCodeExporter]

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?

Original comment by helder.p...@gmail.com on 16 Jan 2008 at 12:15

[GoogleCodeExporter]

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

Original comment by helder.p...@gmail.com on 16 Jan 2008 at 12:16

[GoogleCodeExporter]

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.

Original comment by wolf.lam...@googlemail.com on 16 Jan 2008 at 2:00

[GoogleCodeExporter]

> 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 :)

Original comment by helder.p...@gmail.com on 16 Jan 2008 at 2:24

[GoogleCodeExporter]

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

Original comment by gabriel....@gmail.com on 30 Jan 2014 at 8:46

[GoogleCodeExporter]

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.

Original comment by helder.p...@gmail.com on 30 Jan 2014 at 9:10

[GoogleCodeExporter]

Issue 565 has been merged into this issue.

Original comment by helder.p...@gmail.com on 3 Aug 2015 at 5:05