U++ framework
Do not panic. Ask here before giving up.

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: 1796
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 355 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: 1319
Registered: March 2007
Ultimate 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: 3461
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: 1319
Registered: March 2007
Ultimate 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: 1796
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: 1319
Registered: March 2007
Ultimate 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: 14291
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: 1796
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: 14291
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: 1796
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 326 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: 14291
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: 14291
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 next 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

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32970 is a reply to message #32961] Sun, 26 June 2011 16:05 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
ok this all doesnt help..we got a semantic problem here.

complex can be constructed both from double and anther complex.
same applies for operator=, it can assign a double or a complex.

now, for Value support (and Nuller) we have both operator double() and operator cdouble() implicit conversion, that applies here.

so the compiler could construct a cdouble from a Value (or Nuller) in 2 paths, converting it to double or cdouble. and it does not know which one to prefer.

cdouble x = val.operator double();
cdouble x = val.operator cdouble();

both work, same for Null.

thats due to the implicit handling of double as a sole real part in complex context in std::complex. so there is no way around that. not even deriving from std::complex, unless we spare out the complex(double) ctor and operator=(double).

and it only touches Value conversion stuff. one could leave out the Value support, but it's bad too. so at least to have the Value support like that (dealing with explicit conversion access in this special context) is an advantage, at least the user could know what to call if the compiler doesnt.

RESULT: though it's 'ugly' to explicitly call Null.operator cdouble() and v.operator cdouble(), it's a reasonable price to pay for a common std::complex usage which we dont need to code oursselves anymore. Nuller.operator cdouble() even could be left out, so it only would apply to Value.operator cdouble() to call. but i'd keep it the same semantic, Null.operator cdouble() as well.

is it worth it, that's the final question? everything else works..

[Updated on: Sun, 26 June 2011 16:21]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32985 is a reply to message #32970] Mon, 27 June 2011 18:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
I think it is possible that constructor from const Value& might improve the situation.
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32991 is a reply to message #32985] Tue, 28 June 2011 09:04 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
do you mean explicit Value(const cdouble&) ?
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32992 is a reply to message #32991] Tue, 28 June 2011 09:16 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
No, cdouble(const Value&).

See e.g. Color...

Not sure if that helps, but I guess it is worth of try...
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #32993 is a reply to message #32992] Tue, 28 June 2011 09:22 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
then the go is for deriving? i'll try.
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33054 is a reply to message #32993] Tue, 05 July 2011 13:28 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
got sth workin.. i think it would do it. thanks for the hints..

attached are Complex.h and Complex.cpp for Core.
the attached patch is to include them properly...

cdouble is derived from std::complex. i wanted cdouble to have as little code as possible and use native external means, except for where not otherwise possible like Value conversion.

if this could go to Core, the posted plugin/kissfft (see above) is also possible..

test

void Test(const cdouble& c) { RLOG(c); }

CONSOLE_APP_MAIN
{
	cdouble y(1.,5.);
	cdouble x = 12;

	//cdouble handling
	double d = y.real();
	y+=3.;

	//cdouble to value conversion test
	Value v = RichToValue(y);
	v = y;
	int type = v.GetType();

	Vector<cdouble> vc;
	vc.Add(12);

	//Value to cdouble conversion test	
	x = v;

	//Null handling	
	Test(Null);
	x = Null;

	bool b;
	b = (v == x);
	b = (x == v);
	b = (v != x);
	b = (x != v);
}
  • Attachment: comp.svn.patch
    (Size: 0.95KB, Downloaded 371 times)
  • Attachment: Complex.h
    (Size: 1.24KB, Downloaded 421 times)
  • Attachment: Complex.cpp
    (Size: 0.30KB, Downloaded 622 times)

[Updated on: Tue, 05 July 2011 13:34]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33087 is a reply to message #33054] Wed, 06 July 2011 13:17 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
kohait00 wrote on Tue, 05 July 2011 07:28

got sth workin.. i think it would do it. thanks for the hints..

attached are Complex.h and Complex.cpp for Core.
the attached patch is to include them properly...

cdouble is derived from std::complex. i wanted cdouble to have as little code as possible and use native external means, except for where not otherwise possible like Value conversion.

if this could go to Core, the posted plugin/kissfft (see above) is also possible..

test

void Test(const cdouble& c) { RLOG(c); }

CONSOLE_APP_MAIN
{
	cdouble y(1.,5.);
	cdouble x = 12;

	//cdouble handling
	double d = y.real();
	y+=3.;

	//cdouble to value conversion test
	Value v = RichToValue(y);
	v = y;
	int type = v.GetType();

	Vector<cdouble> vc;
	vc.Add(12);

	//Value to cdouble conversion test	
	x = v;

	//Null handling	
	Test(Null);
	x = Null;

	bool b;
	b = (v == x);
	b = (x == v);
	b = (v != x);
	b = (x != v);
}



Would you mind if instead of "cdouble" we use either complex or Complex?

I think integer complex numbers are unlikely and is we later decide to support 'float', we can still use something like complex32 or so...

Mirek
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33091 is a reply to message #33087] Wed, 06 July 2011 14:48 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i dont mind at all.. vote for Complex..complex would probably have issues with std::complex, where users do using namespace std
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33093 is a reply to message #33091] Wed, 06 July 2011 17:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
Thanks, with some minor changes applied.

One question: Should we consider polyequal for Complex vs double? (I mean, number+0i == number)

Or perhaps even type conversions where possible? As I see it, complex could be constructed from any number based Value as well, correct?

Mirek
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33095 is a reply to message #33093] Wed, 06 July 2011 17:50 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
ofcorse...

to complex is probably semantically right.
i'd say: int/bool/double -> complex
what to do with complex -> *?
in case of i0 it's ok, but to raise exception or assert here could prove fatal Smile

cheers and thanks.

PS: what to do with kissfft plugin? will you upload it?
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33096 is a reply to message #33095] Wed, 06 July 2011 19:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 06 July 2011 11:50

ofcorse...

to complex is probably semantically right.
i'd say: int/bool/double -> complex
what to do with complex -> *?
in case of i0 it's ok, but to raise exception or assert here could prove fatal Smile

cheers and thanks.

PS: what to do with kissfft plugin? will you upload it?


I think right now the right place is bazaar. I know it is potentially very usefull package, but by including it to uppsrc I would have to take certain level of responsibility about its maintainace, which I am right now not willing to do...

Mirek
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33097 is a reply to message #33095] Wed, 06 July 2011 19:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 06 July 2011 11:50

ofcorse...

to complex is probably semantically right.
i'd say: int/bool/double -> complex
what to do with complex -> *?
in case of i0 it's ok, but to raise exception or assert here could prove fatal Smile



I think number->complex is fine and easy to do.

I think complex->number is both harder to implement and badly defined, so let us forget about this.

Mirek
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33098 is a reply to message #33097] Wed, 06 July 2011 19:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
Implemented and commited...
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33100 is a reply to message #33098] Wed, 06 July 2011 21:48 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
thank you very much..
should i repost you the kissfft current state?
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33101 is a reply to message #33095] Wed, 06 July 2011 22:19 Go to previous messageGo to next message
Zbych is currently offline  Zbych
Messages: 332
Registered: July 2009
Senior Member
kohait00 wrote on Wed, 06 July 2011 17:50


what to do with complex -> *?


I would suggest modulus (sqrt(r^2+i^2)) for doubles and ints.





Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33102 is a reply to message #33098] Wed, 06 July 2011 23:23 Go to previous messageGo to next message
Anonymous
Hi,

Revision r3624 does not compile under g++, because Complex.h@14:
Complex(const Value& v) : C(IsNumber(v) ? C((double)v) : RichValue<Complex>::Extract(v)) {}

Error: no match for ternary 'operator?:'

Maybe RichValue<Complex>::Extract(v) should be cast to Complex?
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33103 is a reply to message #33102] Wed, 06 July 2011 23:38 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
nope, Extract already returns Complex, but the ternary expects same type in first part as well..

change C to Complex:
Complex.h:14
	Complex(const Value& v) : C(IsNumber(v) ? Complex((double)v) : RichValue<Complex>::Extract(v)) {}


BTW: nice idea with modulus. is it mathematically semantically well placed?

EDIT: i adjusted kissfft, here comes the package for plugin. if it's ok for you...
  • Attachment: kissfft.rar
    (Size: 26.24KB, Downloaded 349 times)

[Updated on: Wed, 06 July 2011 23:55]

Report message to a moderator

Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33106 is a reply to message #33101] Thu, 07 July 2011 08:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
Zbych wrote on Wed, 06 July 2011 16:19

kohait00 wrote on Wed, 06 July 2011 17:50


what to do with complex -> *?


I would suggest modulus (sqrt(r^2+i^2)) for doubles and ints.




I do not think it is a good idea. While there are situations where this is required, it should not happen behind the scene.

It is alike performing "abs" for int -> unsigned conversion... Smile
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33107 is a reply to message #33106] Thu, 07 July 2011 08:23 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i see in this case one-way conversion as the better strategy, just as in real world, the transition to complex world is one-way..
Re: [DISCUSSION] Add 'complex' datatype, to Value too [message #33115 is a reply to message #33107] Thu, 07 July 2011 17:40 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 14291
Registered: November 2005
Ultimate Member
kohait00 wrote on Thu, 07 July 2011 02:23

i see in this case one-way conversion as the better strategy, just as in real world, the transition to complex world is one-way..


Then we are finished now with complex, right?

Good job, kohait Smile

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


Current Time: Wed Sep 09 16:02:47 GMT+2 2026

Total time taken to generate the page: 0.01832 seconds