Re: Bug in pattern parsing?
- To: mathgroup at smc.vnet.net
- Subject: [mg62014] Re: [mg61996] Bug in pattern parsing?
- From: "David Park" <djmp at earthlink.net>
- Date: Wed, 9 Nov 2005 03:45:28 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Kristjan, Look at the FullForm of each of the rules and you will see the problem. It is not c_. that is causing the problem, but the X_. that is taken as ANOTHER optional pattern. Rule1 combines all three factors into a single dot product. Leave a space before the dot. rule3 = c_. X_ .Y_ -> X.Y a.b /. rule3 a.b David Park djmp at earthlink.net http://home.earthlink.net/~djmp/ From: Kristjan Kannike [mailto:kkannike at physic.ut.ee] To: mathgroup at smc.vnet.net Hello, I may have discovered a bug in pattern parsing or applying transformation rules. The following two rules should be equivalent: rule1 = c_.*X_.Y_ -> X.Y with c an optional variable, and rule2 = c_.*Dot[X_, Y_] -> X.Y Yet applying rule1 on a.b as a.b/.rule1 gives 1.a.b (the same result obtains for the optional factor actually present as in const a.b), but a.b/.rule2 gives a.b as it should. I think that it has to do with the dot in c_., but curiously I get the same result when writing the LHS of rule1 as Optional[c]*Y.Z and that confuses me... Any thoughts? Kristjan Kannike <http://www.physic.ut.ee/~kkannike/english/>