Hi! GiNaC and libxloops are now put into their own namespaces ("GiNaC" and "xloops", respectively). If you're using GiNaC/libxloops in your own programs, it should be enough to add using namespace GiNaC; using namespace xloops; after the #include <ginac/ginac.h> or #include <lib/xloops.h> to make things compile again. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/
normal(q10^2-q10^4*(q10^2-q21^2)^(-1)+q21^2*q10^2*(q10^2-q21^2)^(-1));
Hi all, Consider this: When one types in ginsh: power::eval(): division by zero The result, however, should be zero. Maybe the next bug is related to the above one:
normal(q10^2*(I*Pi^2*(q10^2-q21^2)^(-1/2)*q10^2*(-(1/2)*(q10^2-q21^2)^(-1/2)*q10^2+(1/2)*q21^2*(q10^2-q21^2)^(-1/2))+1/2*I*Pi^2*q10^2)); q10^2*(1/2*I*Pi^2*q21^2*(q10^2-q21^2)^(-1)*q10^2-1/2*I*Pi^2*(q10^2-q21^2)^(-1)*q10^4+1/2*I*Pi^2*q10^2)
normal("); 0
The result is correct, but it should already found it after the first line. Son.
Hi! On Fri, 19 Nov 1999, Do Hoang Son wrote:
normal(q10^2-q10^4*(q10^2-q21^2)^(-1)+q21^2*q10^2*(q10^2-q21^2)^(-1)); power::eval(): division by zero
Fixed.
Maybe the next bug is related to the above one:
No.
normal(q10^2*(I*Pi^2*(q10^2-q21^2)^(-1/2)*q10^2*(-(1/2)*(q10^2-q21^2)^(-1/2)*q10^2+(1/2)*q21^2*(q10^2-q21^2)^(-1/2))+1/2*I*Pi^2*q10^2)); q10^2*(1/2*I*Pi^2*q21^2*(q10^2-q21^2)^(-1)*q10^2-1/2*I*Pi^2*(q10^2-q21^2)^(-1)*q10^4+1/2*I*Pi^2*q10^2)
normal("); 0
This is caused by (x^(1/2))^2 being treated (during normal()) as foobar^2 and not being further evaluated until foobar gets re-inserted in the very end. A workaround is to call expand() before normal(). Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/
On Mon, 22 Nov 1999, Christian Bauer wrote:
normal(q10^2*(I*Pi^2*(q10^2-q21^2)^(-1/2)*q10^2*(-(1/2)*(q10^2-q21^2)^(-1/2)*q10^2+(1/2)*q21^2*(q10^2-q21^2)^(-1/2))+1/2*I*Pi^2*q10^2)); q10^2*(1/2*I*Pi^2*q21^2*(q10^2-q21^2)^(-1)*q10^2-1/2*I*Pi^2*(q10^2-q21^2)^(-1)*q10^4+1/2*I*Pi^2*q10^2)
normal("); 0
This is caused by (x^(1/2))^2 being treated (during normal()) as foobar^2 and not being further evaluated until foobar gets re-inserted in the very end. A workaround is to call expand() before normal().
Hmm, not very transparent. Since contrary to (x^2)^(1/2), (x^(1/2))^2 can be safely transformed into x maybe something like this should be done internally by normal()? On the other hand, maybe this will become too complex. I don't know... What are we gonna do? Bye -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
Salut,
This is caused by (x^(1/2))^2 being treated (during normal()) as foobar^2 and not being further evaluated until foobar gets re-inserted in the very end. A workaround is to call expand() before normal().
Hmm, not very transparent. Since contrary to (x^2)^(1/2), (x^(1/2))^2 can be safely transformed into x maybe something like this should be done internally by normal()? On the other hand, maybe this will become too complex. I don't know... What are we gonna do?
Call expression.normal().normal() could be easiest way. if one calls expand() then normal(), it will take long time in case his/her expression is long. Son.
On Tue, 23 Nov 1999, Do Hoang Son wrote:
Call expression.normal().normal() could be easiest way. if one calls expand() then normal(), it will take long time in case his/her expression is long.
Probably one can construct an example where it would be necessary to call .normal().normal().normal() (and worse) to end up with the desired result. Also .expand().normal() will probably fail sometimes. So this looks like a more serious issue... -- Alexander Frink E-Mail: Alexander.Frink@Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-393391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany
participants (4)
-
Alexander Frink
-
Christian Bauer
-
Do Hoang Son
-
Richard B. Kreckel