Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2000
*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 2000

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

Search the Archive

Re: Flat, OneIdentity Again

  • To: mathgroup at smc.vnet.net
  • Subject: [mg21669] Re: [mg21637] Flat, OneIdentity Again
  • From: Hartmut Wolf <hwolf at debis.com>
  • Date: Fri, 21 Jan 2000 04:00:25 -0500 (EST)
  • Organization: debis Systemhaus
  • References: <200001180735.CAA20333@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Ersek, Ted R schrieb:
> 
> Thanks to all who answered my question on Flat and OneIdentity.
> I have more strange behavior on this subject.
> 
> At http://support.wolfram.com/Kernel/Symbols/System/Flat.html
> it says in so many words ....
> If (f) has the Flat attribute you better not have a definition like
>   f[p_]:=p
> because if you do, then an attempt to evaluate f[1,2] will not work and the
> kernel will have to quit when the infinite iteration limit is exceeded.
> 
> In addition I found that you can't even evaluate f[2] in the above case, and
> it doesn't help if (f) also has the OneIdentity attribute!
> 
> I wanted to understand just what the kernel is doing to exceed the iteration
> limit when we try to evaluate f[1,2] or f[2] above.  The lines below offer
> some clues, but also add to the mystery. I wonder if any of you have an
> explanation.
> 
> In[1]:=
> ClearAll[f];
> Attributes[f]={Flat};
> 
> After the input above (f) has the Flat attribute and no definitions.
> f[1,2] as f[f[1,2]].
> 
> In[3]:=
> f[1,2]/.f[p_]:>{p}
> Out[3]=
> {f[1,2]}
> 
> The idea that the pattern matcher treats
> f[1,2] as f[f[1,2]] is sort of verified
> at Out[4] below.
> 
> In[4]:=
> MatchQ[f[1,2],f[_f]]
> Out[4]=
> True
> 
> But if the pattern matcher treats f[1,2] as f[f[1,2]]
> why doesn't MatchQ return True in Out[4] below ?
> 
> In[5]:=
> MatchQ[f[1,2],HoldPattern[f[f[_Integer,_Integer]]]]
> Out[5]=
> False
> 
> Even stranger is the next line where the pattern is much more general!
> Notice that is a triple blank inside (f).
> 
> In[6]:=
> MatchQ[f[1,2],HoldPattern[f[f[___]]]]
> Out[6]=
> False
> 
> All the results above come out the same if (f) has the attributes Flat,
> OneIdentity.
> 
> I have a hunch what may be going on here. Perhaps this is a bug. Could it be
> that the part of the pattern matcher that handles Flat is oblivious to
> HoldPattern and checks for a match with the patterns f[_Integer,_Integer]
> and  f[___]
> when it should check for a match with f[f[_Integer,_Integer]] and  f[f[___]]
> 
> respectively in the lines above?
> 
> I did all this using Version 4.
> 
> --------------------
> Regards,
> Ted Ersek
> 
> On 12-18-99 Mathematica tips, tricks at
> http://www.dot.net.au/~elisha/ersek/Tricks.html
> had a major update

Hello Ted,

first, again a citation from The Book. In section 2.3.8 it says:

Notice that with flat functions such as Plus and Times, Mathematica
automatically handles variable numbers of arguments, so you do not
explicitly need to use double or triple blanks, as discussed in Section
2.3.7. 

...to me "you do not explicitly need to use" reads plain "don't"


Now to your obvservations I'd like to add:

In[1]:= ClearAll[f]; Attributes[f] = {Flat};
 
In[2]:= MatchQ[f[f[1, 2]], f[x : _f]]
Out[2]= True

In[3]:= MatchQ[f[f[1, 2]], f[x : f[_]]]
Out[3]= False

Something hard to digest! (It doesn't matter whether you use Blank[] or
BlankSequence[], see quotation above.)

However 

In[4]:= MatchQ[f[f[1, 2]], f[f[_]]]
Out[4]= True

In[5]:= MatchQ[f[f[1, 2]], HoldPattern[f[f[_]]]]
Out[5]= False


Now it is informative to trace these examples.

In[8]:= MatchQ[f[f[1, 2]], f[f[_]]] // Trace
Out[8]=
{{f[f[1, 2]], f[1, 2]}, {f[f[_]], f[_]}, MatchQ[f[1, 2], f[_]], True}

Things are brought to a 'normal form' first, and such f[f[_]] is
converted to f[_] first, before matching begins.  Now the idea, that the
pattern matcher converts the lhs (of MatchQ, ReplaceAll, etc.) to
f[f[1,2]] and then uses the 'normal' matching algorithm is nowhere
stated in The Book (being our *only* source of documentation). It's an
idea we gain and might use as a catch rule, yet understood literally and
procedurally this might be an illusion!

So the pattern matcher might very well use it's own procedures when he
receives its input for a Flat function (in 'normal form'). And now the
presence of the name x in f[x : f[_]]] as well as HoldPattern hinders
the evaluator to generate the appropriate 'normal form' the pattern
matcher needs to go throught its special Flat or Flat & OneIdentity
algorithm. 

Yet, Ted, this might be another illusion, and I'm telling fairy tales.

Kind regards, Hartmut


  • Prev by Date: Re: Flat, OneIdentity Again
  • Next by Date: Re: Flat, OneIdentity Again
  • Previous by thread: Flat, OneIdentity Again
  • Next by thread: Re: Flat, OneIdentity Again