complex conjugation

[chrisd at sci.kun.nl]

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