Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

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