complex conjugation

[Jens Vollinga]

Hi.

On Thu, Dec 18, 2003 at 01:38:01PM +0000, Chris Dams wrote:
> 
> Hello,
> 
> On Tue, 16 Dec 2003, Jens Vollinga wrote:
> 
> > The digestion of your contribution took a while, because the complex
> > conjugation of some functions (harmonic and multiple polylog) is a bit more
> > involved, and I wanted to think of a solution to this before integrating
> > the patch.
> >
> > In doing so I recognized the following:
> >   sin(x).conjugate() gives sin(x) ?!
> > or simpler
> >   x.conjugate() gives x ?!
> > if x is symbol.
> 
> This issue is discussed in
> http://www.ginac.de/lists/ginac-list/msg01354.html and follow-ups. An
> alternative to assuming all symbols to be real would be to have a global
> map (perhaps attached to the class symbol) that maps symbols to their
> complex conjugates.
>

Oops. Read the mails once, but forgot about it in the meantime ;-)

> I must say I am totally new to polylogs. Looking at their definition, I
> notice that they have a convergence radius of 1. Also the documentation
> says that they can only be evaluated numerically for arguments x_i with
> |x_i|<1. I only see problems for complex conjugation at branch cuts for
> |x|>1 (and only at the real axis I would guess). This is the same problem
> that was discussed in the aforementioned thread for the log. Therefore I
> still think that complex conjugating arguments would be best for these
> functions, or do you know of other problems with cc-ing these functions?

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.

But I admit that this not a argument in favour of or against any
implementation of cconj. Probably nobody uses these functions at the
moment and there would/will be enough time to think about the
mathematics of those certain functions.

Style and execution speed don't matter either, I think. The crucial
points in my opinion are:

- The basic idea to give the user the obligation to subsitute the
  symbols afterwards is not so good (bad). It is counter-intuitive and
  asks for users to delve into debugging sessions. Functions (C++) with
  input parameters using cconj would have to extent their parameter list
  for cconj-symbols.  What about an expression x+abs(x) if x is a
  symbol?  How to substitute? (maybe this example is not so well
  devised, but it makes you feel that there could appear problems 
  in similar cases...)

- The way you proposed to do the cconj (in patch) is good, because
  every function can care about its cconj for itself. Ginac doesn't need
  to know about every new function a user might want to implement
  (impossible!). 

(Not an important argument: on top of that, with a Ginac-function you
could nicely do cconj(cconj(x)) -> x and have a latex output for
cconj(x) as x^*).

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)


Bye,
Jens