I'm trying to define a function f, such that
f[a_]:=a;
f[f[a__]]:=f[a];
Then, I tried to evaluate f[x,y]. Since f[x,y] satisfies none of these two patterns, it is expected that the result will be just f[x,y]. Nevertheless, in fact, the result is
Hold[f(a,b)]
and I get a error message:
$IterationLimit::itlim: Iteration limit of 4096 exceeded. >>
It seems quite confusing. How could this happen?
Note the following
a=3;
g[a]=2;
g//Definition
g[3]=2
We see that the definition g[3]=2 was stored, rather than g[a]=2. The argument of g, which is a, is evaluated before the definition is made.
The same happens in your code. f[a__] evaluates to a__ before the definition is made.
f//Definition
f[a_]:=a f[a__]:=f[a]
I like the following solution
f4[a_] := a;
f4[HoldPattern@f4[a__]] := f4[a];
Another solution relies on using Unevaluated in a strange and AFAIK undocumented way, like this
f2[a_] := a;
f2[Unevaluated@f2[a__]] := f2[a];
f2 // Definition
f2[f2[a__]]:=f2[a] f2[a_]:=a
I kind of like this too, because it allows you to make the definition you want to make, without HoldPattern.
g was the main case that was focused on in making this decision.
– Jacob Akkerboom
Nov 02 '15 at 15:33
f[a_]=a prior to f[f[a__]]=f[a], because first f[a_] gets "replaced" with a, and then f[f[a__]]=f[a] evaluates to f[a__]=f[a].
– Graumagier
Nov 02 '15 at 15:33
You can get the expected output by defining the functions in reverse order.
f[f[a__]] := f[a]
f[a_] := a
f[x, y]
f[x, y]
f[f[a]] matches both f[a_] and f[f[a__]], you need to change the order they're stored in (cf. DownValues, and the answers). This is most easily effected by changing the order they're declared in. Note, however, there is a notion of specificity, where more specific patterns are tested before more general ones. In this case, though, they're equally general.
– rcollyer
Nov 02 '15 at 16:14
f[f[a__]] is more specific than f[a_], so in this sense the order should not matter. In the example f7[a_] := a; f7[{a__}] := f7[a]; the DownValues are automatically sorted for this reason. The reason for the trouble is that in the other order of evaluation, there is an unexpected evaluation of a pattern. Please see my answer.
– Jacob Akkerboom
Nov 02 '15 at 16:40
DownValues@f, completely missing the transformation.
– rcollyer
Nov 02 '15 at 16:48
Jacob gives a good exposition on different methods that work. But, to avoid any possibility of ambiguity, I would go with something very different
f[a_] := a
f[q_f] := q
which is correctly ordered
DownValues@f
(* {HoldPattern[f[q_f]] :> q, HoldPattern[f[a_]] :> a} *)
It looks like your double uderscore (BlankSequence) in the second definition matches things like x,y. For example:
f[a__] := 10*a;
f[3, 2, 4]
240
f[f[a__]] nor f[a_] should match f[x,y] (and they don't actually). Only in the above combination they do.
– Graumagier
Nov 02 '15 at 14:50
f[x,y] should be returned unevaluated because it is not of the form f[f[a__]] (a function inside a function).
– Graumagier
Nov 02 '15 at 14:58
Flatattribute. – rcollyer Nov 02 '15 at 14:33?f. Another way to achieve the desired result would bef[Hold@f[a__]]:=f[a];. – Graumagier Nov 02 '15 at 14:40Flatdoes what you want to do. Did you tryf[Hold@f[a__]]:=f[a];? Also take care to clear all definitions/restart the kernel. – Graumagier Nov 02 '15 at 15:24