Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » [DISCUSSION] Add 'complex' datatype, to Value too
[DISCUSSION] Add 'complex' datatype, to Value too [message #32803] Fri, 10 June 2011 16:00 Go to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi guys..

upp has AFAIK no complex datatype. why not add one.?
does not need to be fancy, in fact best to be compatible in alignment for later use with fftw or the like.

up for discussion:

struct complex
{
	double re;
	double im;

public:
	static const complex i;
	static const complex j;
	static const complex zero;

	complex() : re(0.), im(0.) {}
	complex(double re) : re(re), im(0.) {}
	complex(double re, double im): re(re), im(im) {}

	complex& operator=(const complex& c) { re = c.re; im = c.im; return *this; }
	complex& operator=(const double& val) { re = val; im = 0.; return *this; }

	complex conj() const { return complex(re, -im); }
	double norm() const { return re * re + im * im; }

	complex& operator++ () { ++re; return *this; }
	complex operator++ (int) { complex temp(*this); ++re; return temp; }
	complex& operator-- () { --re; return *this; }
	complex operator-- (int) { complex temp(*this); --re; return temp; }

	complex operator+(const complex& c) const { return complex(re + c.re, im + c.im); }
	complex operator-(const complex& c) const { return complex(re - c.re, im - c.im); }
	complex operator*(const complex& c) const { return complex(re * c.re - im * c.im, re * c.im + im * c.re); }
	complex operator/(const complex& c) const { double den = c.re * c.re + c.im * c.im; return complex((re * c.re + im * c.im) / den, (im * c.re - re * c.im) / den); }
	complex& operator+= (const complex& c) { re += c.re; im += c.im; return *this; }
	complex& operator-= (const complex& c) { re -= c.re; im -= c.im; return *this; }
	complex& operator*= (const complex& c) { const double temp = re; re = re * c.re - im * c.im; im = im * c.re + temp * c.im; return *this; }
	complex& operator/= (const complex& c) { const double den = c.re * c.re + c.im * c.im; const double temp = re; re = (re * c.re + im * c.im) / den; im = (im * c.re - temp * c.im) / den; return *this; }
	
	complex operator+ (const double& val) const { return complex(re + val, im); }
	complex operator- (const double& val) const { return complex(re - val, im); }
	complex operator* (const double& val) const { return complex(re * val, im * val); }
	complex operator/ (const double& val) const { return complex(re / val, im / val); }
	complex& operator+= (const double& val) { re += val; return *this; }
	complex& operator-= (const double& val) { re -= val; return *this; }
	complex& operator*= (const double& val) { re *= val; im *= val; return *this; }
	complex& operator/= (const double& val) { re /= val; im /= val; return *this; }

	friend complex operator+ (const double& l, const complex& r) { return complex(l + r.re, r.im); }
	friend complex operator- (const double& l, const complex& r) { return complex(l - r.re, -r.im); }
	friend complex operator* (const double& l, const complex& r) { return complex(l * r.re, l * r.im); }
	friend complex operator/ (const double& l, const complex& r) { const double den = r.re * r.re + r.im * r.im; return complex(l * r.re / den, -l * r.im / den); }

	bool operator==(const complex &c) const { return re == c.re && im == c.im; }
	bool operator!=(const complex &c) const { return re != c.re || im != c.im; }
	bool operator==(const double& val) const { return re == val && im == 0.; }
	bool operator!=(const double& val) const { return re != val || im != 0.; }

	friend bool operator==(const double& l, const complex& r) { return l == r.re && r.im == 0.; }
	friend bool operator!=(const double& l, const complex& r) { return l != r.re || r.im != 0.; }
};

//.cpp
#include "complex.h"

const complex complex::i(0., 1.);
const complex complex::j(0., 1.);
const complex complex::zero(0., 0.);


note that it does not know anything about Value !! to keep it as 'native' as possible.

thus is tricky to make it Value aware from 'outside'. a way would be what i described in
http://www.ultimatepp.org/forum/index.php?t=msg&goto=325 14&#msg_32514
see my last patch.

this would make possible to use types for Value, that are not intrinsic but not 'editable' (so as to specify AssignTypeNo etc. in derive list).

NAMESPACE_UPP

template<> inline bool IsNull(const complex& r) { return r.re < DOUBLE_NULL_LIM || r.im < DOUBLE_NULL_LIM; }
template<> inline void SetNull(complex& x) { x.re = x.im = DOUBLE_NULL; }
inline const complex& Nvl(const complex& a, const complex& b)  { return IsNull(a) ? b : a; }

const dword COMPLEX_V   = 20;
template<> inline dword ValueTypeNo(const complex*)   { return COMPLEX_V; }

VALUE_COMPARE(complex)

template<> inline unsigned GetHashValue(const complex& x) { return CombineHash(GetHashValue(x.re), GetHashValue(x.im)); }
template<> inline String AsString(const complex& x) { return String().Cat() << "C(" << x.re << "," << x.im << ")"; }
template<> inline Stream& operator%(Stream& s, complex& x) { s % x.re % x.im; return s; }

END_UPP_NAMESPACE


ideas and critics welcome Smile

background: i'm on way of wrapping fftw or providing some native fft support for Upp..we don't habve anything such here yet.
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32804 is a reply to message #32803] Fri, 10 June 2011 22:52 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Hi!

You are right about U++ missing the basic mathematical tools. As a physicist, I have needed the complex numbers in my programs many times. The same goes for many other mathematical tools.

Complex type doesn't really fit into Core, but what about creating a Math package, that would include such tools? It could also use the Eigen package (btw: I think there is already a complex numbers type in eigen, what about just wrapping that one?) and the fftw package you talked about. And possibly others, as they emerge.

About your proposed implementation: It looks quite good, from the quick look it has most of the basic functions I ever needed... I don't think I would really use a Value compatibility, but if you write it, I won't mind I have only one objection: The "complex::i" is not very useful. It is too long to use in equations Smile I would prefer something like global constant/macro named just "I". In uppercase to avoid problems with "int i", which is on thousands of places in any program I know Wink

Best regards,
Honza

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32809 is a reply to message #32804] Sun, 12 June 2011 09:30 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
here comes a first package. complex extended a bit. got some ideas here and there..

it also has an fft implementation, which i havent credited to author yet. but i think this will be refactored anyway. it's just example..

proper complex implementation should go out of Math anyway..
since Nuller needs to have it as 'operator complex()'..

i'd really like to keep complex as netaive as possible.

se for your own. i'll be away for a week Smile
  • Attachment: Math.rar
    (Size: 4.44KB, Downloaded 204 times)
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32811 is a reply to message #32809] Sun, 12 June 2011 18:04 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi,

As you are referring to FFT etc.. Please check out Ooura FFT packages at http://www.kurims.kyoto-u.ac.jp/~ooura/fft.html as they have decent license terms (IMO) in contrast to e.g. fftw. I have used those for several years now and including them in Upp would be optimal.

Best regards,

Tom

[Updated on: Sun, 12 June 2011 18:05]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32821 is a reply to message #32809] Mon, 13 June 2011 08:47 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3356
Registered: August 2008
Senior Veteran
Hello kohait

There is also a FFT package in Eigen.

See here: http://eigen.tuxfamily.org/index.php?title=EigenFFT


Best regards
IƱaki
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32826 is a reply to message #32821] Mon, 13 June 2011 11:20 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Koldo,

Please note that EigenFFT license terms (GPL/LGPL) are not especially favorable from the Upp point of view. Of course the FFTW (one fft backend for EigenFFT) offers a commercially usable license option, but it comes with a price tag on it.

Best regards,

Tom
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32827 is a reply to message #32826] Mon, 13 June 2011 12:15 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Tom1 wrote on Mon, 13 June 2011 11:20

Hi Koldo,

Please note that EigenFFT license terms (GPL/LGPL) are not especially favorable from the Upp point of view. Of course the FFTW (one fft backend for EigenFFT) offers a commercially usable license option, but it comes with a price tag on it.

Best regards,

Tom


Hi Tom,

Since Eigen consist of headers only, it can be used in comercial projects without worrying about the (L)GPL Wink Also AFAIK at least on of the backends (kissfft) is licensed under the same terms as Eigen to assure compatibility.

Eigen authors say this about LGPL:
Quote:

When you distribute software that uses [unmodified] Eigen, the LGPL requires you to:
Say somewhere that that software uses Eigen, and that Eigen is LGPL-licensed.
Give a link to the text of the LGPL license.
See Section 3 of the LGPL.
That's pretty much the same as the 2-clause BSD license.

Please read the Licensing FAQ on Eigen website for further details and explanations Wink

Best regards,
Honza
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32830 is a reply to message #32827] Mon, 13 June 2011 19:24 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi all,

Please do not get me wrong, but I'm really and severely allergic to both GPL and LGPL... If I pick up anything with even LGPL license, I feel like digging a hole for myself.

Generally: I like to link statically to keep everything compatible and hassle free on my clients' computers. So even LGPL is not an option.

OK, I looked at http://sourceforge.net/projects/kissfft/ and it says it's BSD licensed, so kissfft is OK in that sense.

Best regards,

Tom

[EDIT] Oh yes, forgot to mention: I understand they have a finely tuned licensing solution with the header structure to make it almost like BSD, but still LGPL without the hassle.... I wonder why not BSD if this is what they want to compare it to?

[Updated on: Mon, 13 June 2011 19:28]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32831 is a reply to message #32830] Mon, 13 June 2011 20:12 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
W.r.t. complex, maybe in this particular, would not it be a good ideas to use std::complex this time?

Mirek
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32835 is a reply to message #32831] Tue, 14 June 2011 07:44 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

mirek wrote on Mon, 13 June 2011 20:12

W.r.t. complex, maybe in this particular, would not it be a good ideas to use std::complex this time?

Mirek

Hi Mirek,
Std::complex is not a bad implementation. It is versatile, optimized and also has a good support in gdb Smile On the other hand, I'd like to have sommething more "U++-like". What about wrapper class that would have std::complex as a base and just add functions like ToString, Xmlize etc.?

Honza
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32836 is a reply to message #32835] Tue, 14 June 2011 08:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Tue, 14 June 2011 01:44

mirek wrote on Mon, 13 June 2011 20:12

W.r.t. complex, maybe in this particular, would not it be a good ideas to use std::complex this time?

Mirek

Hi Mirek,
Std::complex is not a bad implementation. It is versatile, optimized and also has a good support in gdb Smile On the other hand, I'd like to have sommething more "U++-like". What about wrapper class that would have std::complex as a base and just add functions like ToString, Xmlize etc.?

Honza


Some of them could be done as external function, just like we did it for int/double...

Mirek
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32838 is a reply to message #32836] Tue, 14 June 2011 08:45 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

mirek wrote on Tue, 14 June 2011 08:15

dolik.rce wrote on Tue, 14 June 2011 01:44

mirek wrote on Mon, 13 June 2011 20:12

W.r.t. complex, maybe in this particular, would not it be a good ideas to use std::complex this time?

Mirek

Hi Mirek,
Std::complex is not a bad implementation. It is versatile, optimized and also has a good support in gdb Smile On the other hand, I'd like to have sommething more "U++-like". What about wrapper class that would have std::complex as a base and just add functions like ToString, Xmlize etc.?

Honza


Some of them could be done as external function, just like we did it for int/double...

Mirek

I know it is possible in most cases... But the wrapper has more pros that I forgot to mention. E.g. it is a clean way to "move" complex to Upp namespace... I am too lazy person to type "using std::complex;" every time I want to use it Smile (And hardcoding the using clause into U++ doesn't feel right...)

Honza

[Updated on: Tue, 14 June 2011 08:46]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32918 is a reply to message #32838] Mon, 20 June 2011 09:36 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Quote:


I know it is possible in most cases... But the wrapper has more pros that I forgot to mention. E.g. it is a clean way to "move" complex to Upp namespace... I am too lazy person to type "using std::complex;" every time I want to use it (And hardcoding the using clause into U++ doesn't feel right...)


this is again a base principles decision. why not thinking of complex as 'just another logical type like int or double'. this would relief the namespace boundaries..

i'm not quite familiar with the std::complex implementation, which states to be optimized (through template specialization) for double, int and float..

but as mirek said, i dont mind to use std::complex at all.

again, to make std::complex usable in Value, we'd need to have those (or some related) changes in SetNull behaviour or extend Nuller (which probably is a lot esier.

as of fft: doubtlessly fftw is the fastest implementation and the most versatile. but the api sucks definitely. so it'd be a must to have it as plugin to be able to expose it's c api as C++, thus avoiding LGPL issues. ofcorse static linkage isnt possible then.

EDIT: in case std::complex<>: to write complex<double> each time is cumbersome. a \typedef complex<double> cdouble' and respectively for the others would be good..
typedef

EDIT: no need to derive from complex to pull it into upp namespace. just place the 'typedef std::complex<double> cdouble' in the upp namespace..cdouble is then Upp::cdouble. just tested it.

[Updated on: Mon, 20 June 2011 10:46]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32919 is a reply to message #32918] Mon, 20 June 2011 13:44 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
as of EigenFFT:
Quote:


The work is currently in the unsupported section.
Help is welcome.


seems as if they are still in progress with it.

as of FFTW, which is GPL, there will be a problem adding it as plugin isn't it? would a c++ wrapper be considered derivative work? (the old hassle question..)
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32920 is a reply to message #32919] Mon, 20 June 2011 14:24 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
as a starting point:

#include <complex>

NAMESPACE_UPP

typedef std::complex<double> cdouble;

template<> inline bool IsNull(const cdouble& r) { return r.real() < DOUBLE_NULL_LIM || r.imag() < DOUBLE_NULL_LIM; }
template<> inline void SetNull(cdouble& x) { x = cdouble(DOUBLE_NULL, DOUBLE_NULL); }
inline const cdouble& Nvl(const cdouble& a, const cdouble& b)  { return IsNull(a) ? b : a; }

const dword COMPLEX_V   = 20;
template<> inline dword ValueTypeNo(const cdouble*)   { return COMPLEX_V; }

//VALUE_COMPARE(cdouble), doesnt work since Value has no native cdouble conversion support, TODO
inline bool operator==(const Value& v, cdouble x)   { return RichValue<cdouble>::Extract(v) == x; }
inline bool operator==(cdouble x, const Value& v)   { return RichValue<cdouble>::Extract(v) == x; }
inline bool operator!=(const Value& v, cdouble x)   { return RichValue<cdouble>::Extract(v) != x; }
inline bool operator!=(cdouble x, const Value& v)   { return RichValue<cdouble>::Extract(v) != x; }

template<> inline unsigned GetHashValue(const cdouble& x) { return CombineHash(x.real(), x.imag()); }
template<> inline String AsString(const cdouble& x) { return String().Cat() << "C(" << x.real() << "," << x.imag() << ")"; }
template<> inline Stream& operator%(Stream& s, cdouble& x) {
	double r,i;
	if(s.IsStoring()) { r = x.real(); i = x.imag(); }
	s % r % i;
	if(s.IsLoading()) { x = cdouble(r,i); }
	return s;
}

END_UPP_NAMESPACE
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32930 is a reply to message #32920] Tue, 21 June 2011 19:00 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i'm done with a 'plugin/kissfft', but need the cdouble thing for it.

Core.h
#include <string>
+ #include <complex>


Defs.h:247
+ typedef std::complex<double> cdouble;


String.h:783
+ template<> inline String AsString(const cdouble& x)         { return String().Cat() << "C(" << x.real() << "," << x.imag() << ")"; }


with theese changes it should be possible to use the plugin in attachment, move the kissfft to plugin folder.

for Value interaction i need some help, since the simple = Null assignment wont work due to ctor and operator= ambiguities in std::complex. will try to outline it in next post.

  • Attachment: kissfft.rar
    (Size: 27.25KB, Downloaded 184 times)
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32935 is a reply to message #32930] Wed, 22 June 2011 13:12 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
here comes a patch file for including complex as an additional basic datatype. thats why i have placed it in Defs.h, though it's 'math' related, but the other data types are math as well, right Smile
it contains the integration of it in Value as far as possible. but due to it beeing a class/struct and having ctor and operator=, it is not possible to use =Null / from-Value-conversion semantics. or at least i havent succeeded to do so. see my ComplexTest.

quick view, maybe anyone has an idea how to make this possible anyway..or leave it as issue.

NOTE: for successfull usage of std::complex (cdouble) in RichValue, the SetNull template usage change is needed. see my thread
http://www.ultimatepp.org/forum/index.php?t=msg&goto=325 14&#msg_32514

attached is a complete patch for that.. (patch8)

	//cdouble to value conversion test
	Value v = RichToValue(y);
	v = y;

	//Value to cdouble conversion test	
//	x = v; //ambiguity in std::complex::operator=
	x = v.operator cdouble(); //needs explicit call
#if flagMSC
	//works for MSC, GCC has constructor amiguity
	x = cdouble(v);
	x = (cdouble)v;
#endif

//	x = Null; //ambiguity in std::complex::operator=
	x = Null.operator cdouble(); //needs explicit call
#if flagMSC
	//works for MSC, GCC has constructor amiguity
	x = cdouble(Null);
	x = (cdouble)Null;
#endif


EDIT:


Topt.h:227
+NTL_MOVEABLE(cdouble);

[Updated on: Wed, 22 June 2011 13:36]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32958 is a reply to message #32935] Sat, 25 June 2011 19:48 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, I am afraid that Null issue is actually unsolvable without encapsuplating std::complex... IMO, it is good enough reason to do so..
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32960 is a reply to message #32935] Sun, 26 June 2011 09:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 22 June 2011 07:12



// x = Null; //ambiguity in std::complex::operator=
x = Null.operator cdouble(); //needs explicit call



Well, thought that through and it now seems to me that we can easily do this after all. See this (U++ without complex support):

#include <Core/Core.h>
#include <complex>

using namespace Upp;

typedef std::complex<double> complex;

CONSOLE_APP_MAIN
{
	complex x = Null;
	DDUMP(x.real());
}


-> we do not need to add complex to Nuller, it is enough to exploit Nuller::operator double() here Smile


Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32961 is a reply to message #32960] Sun, 26 June 2011 10:47 Go to previous messageGo to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
thats nice idea...

one remains though..

the assignment from Value
//	x = v; //ambiguity in std::complex::operator=


EDIT: tried the version with derive..
struct cdouble : std::complex<double>
{
	typedef std::complex<double> C;
	cdouble() {}
	cdouble(double r) : C(r) {}
	cdouble(double r, double i) : C(r,i) {}
	cdouble(const Nuller&) { operator=(DOUBLE_NULL); }
};

it works, but i've got problems with those COMPARE_VALUE() things..again ambiguity, due to some template operator specifications as it seems..

any idea?

[Updated on: Sun, 26 June 2011 13:52]

Report message to a moderator

Previous Topic: Bugs in Tuple, RemoveSorted and in Scribble Example
Next Topic: PLATFORM_X11 warnings
Goto Forum:
  


Current Time: Tue Apr 16 13:21:25 CEST 2024

Total time taken to generate the page: 0.01970 seconds