Hello, it appears that the GiNaC expressions do not support the complex conjugation... :-( I need it, but I do not know yet how to implement it. Has anybody tried to do this? Clearly conjugation is a function ;-) Ok, i'll try to read the tutorial. Let's see if I get this working... Best regards Andrius Kurtinaitis
Hi Andrius, On Sat, 22 Nov 2003, Andrius Kurtinaitis wrote:
it appears that the GiNaC expressions do not support the complex conjugation... :-( I need it,
It would be helpful (for us and yourself, probably) to quickly whip up a list of what exactly you want to do with the conjugation. On numeric types it's clear. On polynomials, there wouldn't be much you can do, probably, because you cannot just stick assumptions on free symbols. On other functions without any free symbols involved, what would you expect? Would you expect a transformation like this one being performed by the evaluator? conjugate(sin(2)) -> sin(2) Oops! Knowledge about sin() would be needed...
but I do not know yet how to implement it.
Maybe the best approach would be as an ordinary pseudofunction just like abs() or csgn(). If you want transformations like the above you would have to hand up information like "I am real" or "I am purely imaginary" from inner pseudofunctions to their outer wrapping pseudofunction. You would have to implement that as well, since it's not there yet. For simple cases this isn't very difficult.
Has anybody tried to do this? Clearly conjugation is a function ;-) Ok, i'll try to read the tutorial. Let's see if I get this working...
Luck -richy. -- Richard B. Kreckel <Richard.Kreckel@GiNaC.DE> <http://www.ginac.de/~kreckel/>
Hello, On Sat, 22 Nov 2003, Richard B. Kreckel wrote:
It would be helpful (for us and yourself, probably) to quickly whip up a list of what exactly you want to do with the conjugation. On numeric types it's clear. On polynomials, there wouldn't be much you can do, probably, because you cannot just stick assumptions on free symbols.
I would just assume that all symbols are real. If a user then wants complex ones, he can have additionally a list looking like {a==astar,astar==a,b==bstar,bstar==b} and do something like conjugate(x).subs(symbolconjs) if he wants conjugation.
On other functions without any free symbols involved, what would you expect? Would you expect a transformation like this one being performed by the evaluator? conjugate(sin(2)) -> sin(2) Oops! Knowledge about sin() would be needed...
I would say that the default behaviour of functions should be conjugate(f(arg)) --> f(conjugate(arg)). Then there should be a new function option to specify a different behaviour for your particular function. I was wondering a bit about what to do with the log. For that function the default behaviour is okay, except for the real negative axis. I would say that just bluntly using the default behaviour, ignoring possible problems, would be best.
but I do not know yet how to implement it.
Bye, Chris Dams
Hi Chris! On Sun, 23 Nov 2003 chrisd@sci.kun.nl wrote: [...]
I would say that the default behaviour of functions should be conjugate(f(arg)) --> f(conjugate(arg)). Then there should be a new function option to specify a different behaviour for your particular function. I was wondering a bit about what to do with the log. For that function the default behaviour is okay, except for the real negative axis.
Of course, exactly the same problems arise on other (analytic) functions with branch cuts. Take for instance asin(x) for real x where |x| > 1. But that shouldn't stop you.
I would say that just bluntly using the default behaviour, ignoring possible problems, would be best.
I guess that's right. What about non-analytic functions? We don't seem to have many, though, yet (just abs and csgn). Luck -richy. -- Richard B. Kreckel <Richard.Kreckel@GiNaC.DE> <http://www.ginac.de/~kreckel/>
Hello, On Sun, 23 Nov 2003, Richard B. Kreckel wrote:
I would say that just bluntly using the default behaviour, ignoring possible problems, would be best.
I guess that's right. What about non-analytic functions? We don't seem to have many, though, yet (just abs and csgn).
I already wrote the code for that and it looks like static ex abs_conjugate(const ex & x) { return abs(x); } REGISTER_FUNCTION(abs, eval_func(abs_eval). evalf_func(abs_evalf). print_func<print_latex>(abs_print_latex). print_func<print_csrc_float>(abs_print_csrc_float). print_func<print_csrc_double>(abs_print_csrc_float). conjugate_func(abs_conjugate)); static ex csgn_conjugate(const ex&x) { return csgn(x); } REGISTER_FUNCTION(csgn, eval_func(csgn_eval). evalf_func(csgn_evalf). series_func(csgn_series). conjugate_func(csgn_conjugate)); The good news is that this already works fine. Currently I am hunting down a segmentation fault in the complex conjugation of ncmuls. Bye, Chris Dams
Hello, Thanks a lot for the replies. Unfortunately they landed in my Junk mail folder. I noticed them just recently sitting there and now my head is full of other things, not the conjugation. But when it comes back to this topic, i will know where to ask ;-) Andrius
Hi, On Sat, 22 Nov 2003, Andrius Kurtinaitis wrote:
it appears that the GiNaC expressions do not support the complex conjugation... :-(
That's funny. Actually I was just implementing this. At the moment I am mostly getting segmentation faults though, but perhaps if you (and I) are lucky it will appear in GiNaC within not to much time.
I need it, but I do not know yet how to implement it. Has anybody tried to do this?
You could write a costum conjugation function suited for you application. This may look like struct Complexconj : public GiNaC::map_function { public: GiNaC::ex operator()(const GiNaC::ex&); }; Complexconj complexconj; ex Complexconj::operator()(const ex&x) { if(is_a<numeric>(x)) return ex_to<numeric>(x).real()-I*ex_to<numeric>(x).imag(); else if(x.match(vs(wild()))) return vsbar(x.op(0)); else if(x.match(vsbar(wild()))) return vs(x.op(0)); else if(x.match(us(wild()))) return usbar(x.op(0)); else if(x.match(usbar(wild()))) return us(x.op(0)); else if(x==pr) return pl; else if(x==pl) return pr; else if(is_a<power>(x)) return power(operator()(x.op(0)),x.op(1)); else if(is_a<lst>(x)) { lst result; for(int i=x.nops()-1;i>=0;--i) result.append(operator()(x.op(i))); return result; } else if(is_a<add>(x)||is_a<mul>(x)) return x.map(*this); return x; } depending on the application you have. Note that the above will not compile unless you have some more definitions around.
Clearly conjugation is a function ;-)
Well, it is not a GiNaC::function. It is a C++ function.
Ok, i'll try to read the tutorial. Let's see if I get this working...
Good luck, Chris Dams
participants (3)
-
Andrius Kurtinaitis
-
chrisd＠sci.kun.nl
-
Richard B. Kreckel