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