Dear GiNaCers, (1) Once upon a time, not even that long ago, it was possible to browse the GiNaC CVS by clicking on "CVS tree" on the homepage. At the moment this gives the text: "/home/cvs not found! The server on which the CVS tree lives is probably down. Please try again in a few minutes." (2) Could somebody explain why there is a non-trivial method idx::match_same_type? This method makes it impossible to match varidx(mu,4-delta) using the pattern varidx(wild(1),wild(2)), which could be useful sometimes. Best wishes, Chris
Hi guys, First, thanks for all help. But now, I would like to know how GiNaC works with color (non abelian gauge ) field. Supose the object defined below: ex e=color_f(a,b,c)*indexed(A,mu,a)*indexed(A,nu,b)*indexed(A,nu,c); cout<<e<<endl; mu,nu are lorentz indices and a,b,c color indices defined like usual (dimension 8). The output is like this: -f(a,c,b)*A.mu.a*A.nu.b*A.nu.c It only sorts the color_f argument and leaves other objects untouched. My question is: I have to make a struct to order the objects? Is there a " canonicalize()" for color objects? Finally is correct this declaration of color objects or I have to multiply by a color_t($0) each to have a color index? Thanks for all Marco ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
Hi Chris, On Tue, Mar 22, 2005 at 05:31:35PM +0100, Chris Dams wrote:
(2) Could somebody explain why there is a non-trivial method idx::match_same_type? This method makes it impossible to match varidx(mu,4-delta) using the pattern varidx(wild(1),wild(2)), which could be useful sometimes.
the existence of this method makes sense to me, because you don't want to match varidx mu(symbol("mu"), 4-D) with expr.has(varidx(wild(1), 4)) for example. But I see your point. Changing idx::match_same_type() by inserting if (is_a<wildcard>(dim) || is_a<wildcard>(o.dim)) { return true; } before the 'return' statement would give the desired behavior. Then you could match with expr.has(varidx(wild(1), wild(2))) for example. But this is probably just a dirty hack, because you could also match with expr.has(varidx(wild(1), wild(1))) which shouldn't happen. The problem, I think, lies with the design of the wildcard mechanism, but I don't know how to improve it right now. Another (not directly connected) example for what I mean: things like expr.subs(MyFunc(wild(1),wild(2)) == delta_tensor(wild(1), wild(2))) don't work, because 'delta_tensor' checks the arguments to be of class 'idx' and since 'delta_tensor' is an ordinary C++ function with no way to hold back the evaluation ... Regards, Jens
Dear Jens, On Wed, 20 Apr 2005, Jens Vollinga wrote:
The problem, I think, lies with the design of the wildcard mechanism, but I don't know how to improve it right now.
I doubt that it lies there. I think the point is that the index dimension is not really considered an operand of an index in the sense of .nops() and .op(i). IIRC this is even said explicitly somewhere in the comments. The disadvantages that this causes are clear: things like .match, .subs and so on are not always easy to work with. Apparently somebody once upon a time had a reason not to consider index dimension as operands. The question that is bothering me now is what this reason was. Best wishes, Chris
Hi! On Thu, Apr 21, 2005 at 11:07:45AM +0200, Chris Dams wrote:
Apparently somebody once upon a time had a reason not to consider index dimension as operands.
The dimension is an attribute of an index, but not a subexpression (it doesn't even show up in the default output of an index). It just happens to be of type 'ex'... Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/
Dear Christian, On Fri, 22 Apr 2005, Christian Bauer wrote:
Apparently somebody once upon a time had a reason not to consider index dimension as operands.
The dimension is an attribute of an index, but not a subexpression (it doesn't even show up in the default output of an index). It just happens to be of type 'ex'...
This is, besides defamation of index dimensions ("it doesn't even show up!"), saying the same as I did in other words. What I am wondering about is a real reason. Having index dimensions as an operand would be easier sometimes (e.g., in matching and so on one has to know the index dimension and it cannot be a wildcard, resulting in either seperately passing around dimension parameters that are actually present in the expressions or calls to functions with the sole purpose of finding out what the index dimensions are) and I cannot really think of a reason why it would be bad for index dimensions to be operands. Well, at the moment changing it would probably be a bad idea because it would break existing code. Best wishes, Chris
participants (4)
-
Chris Dams
-
Christian Bauer
-
Jens Vollinga
-
mdias＠ift.unesp.br