Re: Bug in pattern parsing?
- To: mathgroup at smc.vnet.net
- Subject: [mg62195] Re: Bug in pattern parsing?
- From: Maxim <ab_def at prontomail.com>
- Date: Mon, 14 Nov 2005 00:38:40 -0500 (EST)
- References: <dkpp0q$rfh$1@smc.vnet.net> <43709561.1090105@dordos.net> <dksdd6$h6c$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
On Wed, 9 Nov 2005 08:52:54 +0000 (UTC), Kristjan Kannike <kkannike at physic.ut.ee> wrote: > On Tue, 8 Nov 2005, Peter Pein wrote: > >> Kristjan Kannike schrieb: >> > 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/> >> > >> >> Hi Kristjan, >> >> the parser can not know what the user has in mind (and vice versa ;-) ). >> Try a space between X_ and the dot or write c_.(X_).Y_ >> >> Peter > > Thanks, Peter. I finally understood by looking at the FullForm of my > > rule1 = c_.*X_.Y_ -> X.Y > > that the Mathematica parser does not consider c_. as part of a dot > product (as I had guessed), but "thinks" that X_. is optional, too. > > If not a bug, it is at best a very ambiguous syntax. > > And intuitively, I would think the parser should consider a dot to be a > dot product, unless explicitly indicated otherwise as in c_.*X_ > > Kristjan Kannike > <http://www.physic.ut.ee/~kkannike/english/> > Some languages use a simple rule which says that the lexical analyzer is greedy. That is, if the input string is "a+++b", the first token is a, the second could be "+", but "++" is a token too, so assume that the user wants "++". "+++" is not a token, and the final result is (a++)+b. Generally Mathematica uses that rule too, except that 'forms' seem to have precedence over operators: _.1 is parsed as (_.)1 because both _. and .1 are 'forms', but 1/.1->2 is interpreted as 1/(.1)->2 because /. is an operator and .1 is a form. So this time the lexeme /. has been split. A greedy analyzer would parse this expression as 1/.(1) -> 2. Maxim Rytin m.r at inbox.ru