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

MathGroup Archive 1997

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

Search the Archive

Re: Flat: Problems & Workarounds

  • To: mathgroup at smc.vnet.net
  • Subject: [mg8476] Re: [mg8451] Flat: Problems & Workarounds
  • From: David Withoff <withoff>
  • Date: Tue, 2 Sep 1997 16:15:13 -0400
  • Sender: owner-wri-mathgroup at wolfram.com

> In[3]:= SetAttributes[h,{Flat,OneIdentity}]
> h[x_,y_?NumericQ] := f[y,x]
> h[x_?NumericQ,y_] := f[x,y]
> h[x_] := x
> h[] = 1
> 
> In[9]:= h[a,b]
> $IterationLimit::"itlim": "Iteration limit of \!\(20\) exceeded."
> Out[9]= Hold[h[a,b]]
> 
> This result is reasonable since none of the binary definitions match in this
> case and we therefore get an infinite loop from the rule h[x_]:=x
> since the Flat attribute makes h[h[a,b]] equal to h[a,b]. To call this
> a longstanding bug might be wrong, even though this is certainly a problem.

Yes, this is reasonable behavior, for exactly the reason that you
described, so it isn't really a bug, but I agree that this is sort of
disappointing.  It's not clear what can or should be done about it.

> Surprisingly enough it seems that by putting the SetAttributes at the end
> makes the attributes inactive. Is this the correct behavior?

Yes.  See for example the documentation for the Attributes function.

> Note that the condition must be placed outside the list of arguments.
> The reason for this is exemplified by the following.
> 
> In[34]:=SetAttributes[test,{HoldAll}]
> test[___] := False
> 
> In[36]:= SetAttributes[g,{Flat,OneIdentity}]
> g[args__] /; test[args] := foo[args]
> 
> In[38]:= Trace[g[a,b,c],test[___]]
> 
> Out[38]= {{test[a,b,c]}}
> 
> In the case above the condition is outside the arguments
> and the pattern matcher try once with all the arguments.
> If we place the condition inside we get
> 
> In[39]:= ClearAll[g]
> SetAttributes[g,{Flat,OneIdentity}]
> g[args__ /; test[args]] := foo[args]
> 
> In[42]:= Trace[g[a,b,c],test[___]]
> 
> Out[42]={{test[a,b,c]},{test[a,b]},{test[b,c]},{test[a]},{test[b]},{test[c]}}
> 
> which shows that all combinations of the arguments are tested. This is not
> only giving bad performance. It is also a completely different behavior of the
> pattern matcher.
> 
> Is this a feature or a bug?

This is an ambiguous pattern, since, with the Flat attribute, it isn't
clear if the match between g[args__] and g[a, b, c] should match with
args bound to Sequence[a, b, c] or to g[a, b, c].  Either match falls
within the nominal logic of the pattern matcher.  Your example shows
that the ambiguity is resolved in different ways depending on how you
set up the pattern.  Maybe that makes it a bug, or maybe not.

> Is it possible to make a nice design of an associative function?

Certainly.  I didn't follow exactly what you want to do, but if all
else fails you don't even need to use the Flat attribute.  The Flat
attribute is in a sense just a convenience to save you the trouble
of writing out the corresponding transformations in terms of other
patterns.  I wouldn't expect the extra rules to be terribly difficult.

Dave Withoff
Wolfram Research


  • Prev by Date: programing: reduce list to cycle
  • Next by Date: Re: Mma Package Style Question
  • Previous by thread: Re: Re: programing: reduce list to cycle
  • Next by thread: Re: Mma Package Style Question