Re: Bug in pattern parsing?

• To: mathgroup at smc.vnet.net
• Subject: [mg62029] Re: [mg61996] Bug in pattern parsing?
• From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
• Date: Wed, 9 Nov 2005 03:46:11 -0500 (EST)
• References: <200511080841.DAA27924@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

```On 8 Nov 2005, at 17:41, Kristjan Kannike 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/>
>

You can see that the rules are not equivalent by comparing FullForm
[rule1] with FullForm[rule2]. The general principle is: if in doubt
insert parentheses. Thus

rule1 = (c_.)*(X_).(Y_) -> X.Y

is exacly equivalent to rule2.

Andrzej Kozlowski

```

• Prev by Date: Re: Following Help Links with the Keyboard
• Next by Date: Re: mathematica expressions in Compile
• Previous by thread: Bug in pattern parsing?
• Next by thread: Re: Bug in pattern parsing?