Hello, On Thu, 18 Dec 2003, Richard B. Kreckel wrote:
On Thu, 18 Dec 2003, Jens Vollinga wrote: [...]
Only harmonic and multiple polylogs take some knowledge to conjugate, the other polylogs could use the default behaviour. Harmonic polylogs can be evaluated everywhere now, so they would need the knowledge of how to cconj themselves.
Now I'm confused. Aren't those harmonic and multiple polylogs analytic?
Me confused too.
Maybe all of this can be taken into account by the following approach: - Every class has a (private) method for cconj and there are macros for the Ginac-function. This is basically your patch. - There exists a Ginac-function cconj (or different name?). It evaluates by calling the (private) cconj methods. If (by a not yet specified way) the method signals, that it could cconj correctly, the Ginac-cconj is replaced by the result, otherwise Ginac-cconj remains unevaluated.
That should give for symbol x("x"); ex a = sin(x) + 3 + 4*I - sin(2/3*I); cout << cconj(a) << endl; something like sin(cconj(x)) + 3 - 4*I - sin(-2/3*I)
Looks good. Those private cconj methods could be elegnatly hooked at compile time, alike to what Cebix did with the print functions, I assume?
Do not know how it is with you, but almost all of the symbols I use are supposed to stand for something real. Having cconj(x) in a result is strange if I know that x is real (and having to do .subs(lst(cconj(x)==x,cconj(y)==y,...)) after a conjugation is at least as awkward as my original proposal of having the user use a list of the form {a==astar,astar==a,etc}). Is there anything wrong with each symbol containing a boolean that says whether it is real? You could then have the evaluation cconj(x) -> x for real symbols. Bye, Chris