[Date Index] [Thread Index] [Author Index]
RE: Flat: Problems & Workarounds Sweden.
Thanks for the response. First, I agree that my function was not specified enough. I'm working on a package for symbolic manipulations of matrices. In this I have an own function for Dot named SymbDot, which works as Dot exept that it can treat symbols like A and B as representatives of matrices. The latter is possible with my command DefineMatrix[A,B], which adds predicates to the symbols saying that these are symbolic matrices. The reordering of the arguments to SymbDot comes from that I want to pull out everything that are scalars (non matrix) from the SymbDot to get something more canonic, e.g., SymbDot[A,4,B,c] gives Times[4,c,SymbDot] I agree that there is not necessary to have the Flat attribute to achieve this. BUT! I still think that Flat will make it easier to write transformation rules that behaves according to the corresponding algebra, e.g., the rules SymbDot[x_,x_] := x^2 SymbDot[x_,(x_)^(n_)] := x^(n+1) SymbDot[(x_)^(n_),x_] := x^(n+1) will be enough to get the following transformation SymbDot[A,B,A,B,A,B] => Power[SymbDot[A,B],3] This type of transformation can of course be made without the Flat, but I think the Flat will make the rules simpler (and prettier) in this case. At least when the tricky things about pulling out scalars have a workaround. Secondly, You have not comment on the feature: h = 1 is not the same as h /; True =1 as well as h[arg__ /; test[arg] ] := ... is not the same as h[arg__ ] /; test[arg] := ... when h has the Flat attribute. This feature was a surprise to me, but also the key to find a workaround for the problem discussed in my previous message. Sincerely, /Johan Gunnarsson _____________________________________________________ Johan Gunnarsson Division of Automatic Control Dept. of EE, Linkoping University S-581 83 Linkoping, Sweden Tel: +46 13 282913 Fax: +46 13 282622 Email: johan at isy.liu.se WWW: http://control.isy.liu.se/~johan