|
[Date Index]
[Thread Index]
[Author Index]
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?
|