You have to use color_ONE() instead of just "1" where appropriate (terms of a sum must all be of the same type): ex g = (color_ONE()+eps*color_T(a)+pow(eps,2)*color_T(b)) * (color_ONE()-eps*color_T(c)+pow(eps,2)*color_T(d)); This will produce the right expression on expand().
Hi Christian, thanks for your reply. This is certainly a workaround, but I'm not too comfortable with it. My original problem occured in a user-defined algebra, I took the colour matrices only as an example. The question is what "expand()" should return for an expression like ( 1 + A ) * B where A and B are in some algebra. You say, that all terms of a sum must be of the same type, so that would involve to define a unit element in the algebra called for example "ONE" and write ( ONE + A ) * B instead. This works. But in this case I would think it's better if ( 1 + A ) * B throws an exception instead of just returning A*B. Otherwise you introduce a possible source of errors which is hard to track in complex programs. Stefan
Hi! On Tue, Jun 26, 2001 at 03:00:42PM +0200, Stefan Weinzierl wrote:
You say, that all terms of a sum must be of the same type, so that would involve to define a unit element in the algebra called for example "ONE" and write
( ONE + A ) * B
instead.
This is how it is intended to be used (and also algebraically most correct).
But in this case I would think it's better if
( 1 + A ) * B
throws an exception instead of just returning A*B.
Maybe add::eval() should throw an exception as soon as it encounters a constant numeric term and a noncommutative object. This would be easy to implement. However, it gets worse when someone writes something like ( m + A ) * B instead of ( m*ONE + A ) * B where "m" is a symbol. In this case you may get totally screwed results because the "*" could end up being a _commutative_ product (this happens if add::return_type() sees the "m" first). To track these kind of errors would require the add class to check whether all terms really are of the same commutativity class, which could cause a severe slowdown (and a totally unnecessary one for people who only use commutative algebra). So it would never be perfect... Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/
participants (2)
-
Christian Bauer
-
Stefan Weinzierl