Re: Bug in pattern parsing?
- To: mathgroup at smc.vnet.net
- Subject: [mg62024] Re: [mg61996] Bug in pattern parsing?
- From: <bsyehuda at gmail.com>
- Date: Wed, 9 Nov 2005 03:45:51 -0500 (EST)
- References: <200511080841.DAA27924@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
This is the same "bug" as 1+2*3 not equal to 9 If you type rule1//Fullform you will find out how your expression is parsed by Mathematica. A parsing order is not a bug, and you shoud be aware if that the same as /. 1 is parsed as /0.1 and you need a space between the . and / for correct parsing yehuda On 11/8/05, Kristjan Kannike <kkannike at physic.ut.ee> wrote: > > 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/> > >
- References:
- Bug in pattern parsing?
- From: Kristjan Kannike <kkannike@physic.ut.ee>
- Bug in pattern parsing?