[Date Index]
[Thread Index]
[Author Index]
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
Prev by Date:
**Re: Re: Timing runs for the last part of my previous post**
Next by Date:
**Re: Types in Mathematica**
Previous by thread:
**Re: Bug in pattern parsing?**
Next by thread:
**mathematica expressions in Compile**
| |