Related
In preparing a response to An unexpected behavior of PatternTest in Mathematica I came across an unexpected Mathematica behavior of my own.
Please consider:
test = (Print[##]; False) &;
MatchQ[{1, 2, 3, 4, 5}, {x__?test, y__}]
During evaluation of In[1]:= 1
During evaluation of In[1]:= 1
During evaluation of In[1]:= 1
During evaluation of In[1]:= 1
False
Since, as Simon's quote of the documentation concisely states:
In a form such as __?test every element in the sequence matched by __
must yield True when test is applied.
I am wondering why Mathematica is testing the first element of the list four separate times. Of course there are four ways to make up the underlying pattern {x__, y__} and if this were a Condition test then all elements that make up the sequence x would need to be tested, but I don't think that is the case here.
Does the logic not hold that if the first element of the list fails PatternTest then given pattern cannot match?
If it does hold, why is Mathematica not making this simple optimization?
Borrowing an example from yoda's answer, here is another example of what appears to be excess evaluation:
In[1]:= test2 = (Print###; Positive###) &;
MatchQ[{1, 2, 3, 4, -5}, {x__?test2, y__?Negative}]
During evaluation of In[1]:= 1
During evaluation of In[1]:= 1
During evaluation of In[1]:= 2
During evaluation of In[1]:= 1
During evaluation of In[1]:= 2
During evaluation of In[1]:= 3
During evaluation of In[1]:= 1
During evaluation of In[1]:= 2
During evaluation of In[1]:= 3
During evaluation of In[1]:= 4
Out[2]= True
I admit to having never explored this aspect of pattern matching before, and I am disturbed by the seeming inefficiency of this. Is this really as bad as it looks, or is some kind of automatic caching taking place? Print appears to indicate against that.
Is there a more efficient pattern based way to write this?
Is this level of redundancy required for correct pattern matching behavior, and why?
I made a false assertion in haste, but I leave it because good answers below address it. Please ignore it in future answers.
It is easy to demonstrate that a similar optimization is made in other
cases:
MatchQ[{-1, 2, 3, 4, 5}, {__?Positive, y__?test}]
(Nothing is printed.)
False
Here Mathematica correctly never even tests any elements for y.
I think everyone is forgetting about the side effects that are possible in test functions. Here is what I think is happening: as Mr.Wizard and others mentioned, there are several ways the pattern may match, just combinatorially. For each combination of {x} and {y}, the x pattern is first tested. By the way, there is no point in defining functions of multiple arguments (##), since, as #Simon explained, the test function is applied separately to each element in the sequence. And this also explains why only the first element (-1) is printed: as soon as the first non-matching element is found, the pattern-matcher stops and goes on to test the next available combination.
Here is a more illustrative example:
In[20]:=
MatchQ[{-1,2,3,4,5},{_,x__?(Function[Print[#];Positive[#]])}]
During evaluation of In[20]:= 2
During evaluation of In[20]:= 3
During evaluation of In[20]:= 4
During evaluation of In[20]:= 5
Out[20]= True
Now it prints all of them, since the function is applied to them one by one, as it has to in this case.
Now to the crux of the matter. Here I set up a test function with a side effect, which decides to change its mind after it tests the very first element:
Module[{flag = False},
ClearAll[test3];
test3[x_] :=
With[{fl = flag},
If[! flag, flag = True];
Print[x];
fl
]
];
The first combination (which is {-1},{2,3,4,5} will be rejected since the function gives False at first. The second one ({-1,2},{3,4,5}) will be accepted however. And this is exactly what we observe:
In[22]:=
MatchQ[{-1,2,3,4,5},{x__?test3,y__}]
During evaluation of In[22]:= -1
During evaluation of In[22]:= -1
During evaluation of In[22]:= 2
Out[22]= True
The printing stopped as soon as the pattern-matcher found a match.
Now, from here it must be obvious that the optimization mentioned in the question and some other answers is not generally possible, since pattern-matcher has no control over the mutable state possibly present in the testing functions.
When thinking about the pattern-matching, we usually view it as a process separate from evaluation, which is largely true, since the pattern-matcher is a built-in component of the system which, once patterns and expressions evaluate, takes over and largely bypasses the main evaluation loop. There are however notable exceptions, which make the pattern-matching more powerful at the price of getting it entangled with the evaluator. These include the uses of Condition and PatternTest, since these two are the "entry points" of the main evaluation process into the otherwise isolated from it pattern-matching process. Once the pattern-matcher hits one of these, it invokes the main evaluator on the condition to be tested, and anything is possible then. Which brings me once again to the observation that the pattern-matcher is most efficient when tests using PatternTest and Condition are absent, and the patterns are completely syntactic - in that case, it can optimize.
Just a quick guess here, but {__?Positive, y__?test} must match the beginning of the list through to the end. So, {-1, 2, 3, 4, 5} fails on the first element, hence no print out. Try replacing Positive with ((Print[##];Positive[#])&), and you'll see it behaves in the same manner as the first pattern.
I think that your premise that Mathematica optimizes the pattern test is incorrect. Consider the pattern {x__, y__}. As you rightly say, there are 4 ways in which {1,2,3,4,5} can fit into this pattern. If you now add a pattern test to this with ?test, MatchQ should return True if any of the 4 ways match the pattern. So it must necessarily test all possible options until a match has been found. So the optimization is only when there are positives, and not when the pattern fails.
Here's a modification of your example with Positive, that shows you that Mathematica does not make the optimization as you claim:
test2 = (Print###; Positive###) &;
MatchQ[{-1, 2, 3, 4, 5}, {x__?test2, y__}]
It prints it 4 times! It terminates correctly with one print if the first element is indeed positive (thereby not having to test the rest). The test for the second element is applied only if the first is True, which is why the test for y was not applied in yours. Here's a different example:
test3 = (Print###; Negative###) &;
MatchQ[{1, 2, 3, 4, -5}, {x__?test2, y__?test3}]
I agree with your logic that if the first fails, then given that every element ought to match, all subsequent possibilities will also fail. My guess is that Mathematica is not that smart yet, and it is simpler to implement identical behaviour for any of _, __, or ___, rather than a different one for each. Implementing a different behaviour depending on whether you use __ or ___ will mask the true nature of the test and make debugging harder.
ok I'll have a go.
MatchQ[{1, 2, 3, 4, 5}, {x__?test, y__}]//Trace
shows that slot sequence is redundant because only one element, in this case the first one in the sequence, is tested. e.g.
MatchQ[{1, 2, 3, 4, 5}, {_, x__?test, y__}] // Trace
Now prints 3 twos. If you change the first pattern to BlankSequence more permutations are generated and some of these have different first elements
MatchQ[{1, 2, 3, 4, 5}, {__, x__?test, y__}] // Trace
In your final example
MatchQ[{-1, 2, 3, 4, 5}, {__?Positive, y__?test}]
the first element always fails the test. If you change this to
MatchQ[{1, 2, -3, 4, 5}, {__?Positive, y__?test}]
you will see something more along the lines of what you expected.
I've been looking at the ways to check arguments of functions. I noticed that
MatrixQ takes 2 arguments, the second is a test to apply to each element.
But ListQ only takes one argument. (also for some reason, ?ListQ does not have a help page, like ?MatrixQ does).
So, for example, to check that an argument to a function is a matrix of numbers, I write
ClearAll[foo]
foo[a_?(MatrixQ[#, NumberQ] &)] := Module[{}, a + 1]
What would be a good way to do the same for a List? This below only checks that the input is a List
ClearAll[foo]
foo[a_?(ListQ[#] &)] := Module[{}, a + 1]
I could do something like this:
ClearAll[foo]
foo[a_?(ListQ[#] && (And ## Map[NumberQ[#] &, # ]) &)] := Module[{}, a + 1]
so that foo[{1, 2, 3}] will work, but foo[{1, 2, x}] will not (assuming x is a symbol). But it seems to me to be someone complicated way to do this.
Question: Do you know a better way to check that an argument is a list and also check the list content to be Numbers (or of any other Head known to Mathematica?)
And a related question: Any major run-time performance issues with adding such checks to each argument? If so, do you recommend these checks be removed after testing and development is completed so that final program runs faster? (for example, have a version of the code with all the checks in, for the development/testing, and a version without for production).
You might use VectorQ in a way completely analogous to MatrixQ. For example,
f[vector_ /; VectorQ[vector, NumericQ]] := ...
Also note two differences between VectorQ and ListQ:
A plain VectorQ (with no second argument) only gives true if no elements of the list are lists themselves (i.e. only for 1D structures)
VectorQ will handle SparseArrays while ListQ will not
I am not sure about the performance impact of using these in practice, I am very curious about that myself.
Here's a naive benchmark. I am comparing two functions: one that only checks the arguments, but does nothing, and one that adds two vectors (this is a very fast built-in operation, i.e. anything faster than this could be considered negligible). I am using NumericQ which is a more complex (therefore potentially slower) check than NumberQ.
In[2]:= add[a_ /; VectorQ[a, NumericQ], b_ /; VectorQ[b, NumericQ]] :=
a + b
In[3]:= nothing[a_ /; VectorQ[a, NumericQ],
b_ /; VectorQ[b, NumericQ]] := Null
Packed array. It can be verified that the check is constant time (not shown here).
In[4]:= rr = RandomReal[1, 10000000];
In[5]:= Do[add[rr, rr], {10}]; // Timing
Out[5]= {1.906, Null}
In[6]:= Do[nothing[rr, rr], {10}]; // Timing
Out[6]= {0., Null}
Homogeneous non-packed array. The check is linear time, but very fast.
In[7]:= rr2 = Developer`FromPackedArray#RandomInteger[10000, 1000000];
In[8]:= Do[add[rr2, rr2], {10}]; // Timing
Out[8]= {1.75, Null}
In[9]:= Do[nothing[rr2, rr2], {10}]; // Timing
Out[9]= {0.204, Null}
Non-homogeneous non-packed array. The check takes the same time as in the previous example.
In[10]:= rr3 = Join[rr2, {Pi, 1.0}];
In[11]:= Do[add[rr3, rr3], {10}]; // Timing
Out[11]= {5.625, Null}
In[12]:= Do[nothing[rr3, rr3], {10}]; // Timing
Out[12]= {0.282, Null}
Conclusion based on this very simple example:
VectorQ is highly optimized, at least when using common second arguments. It's much faster than e.g. adding two vectors, which itself is a well optimized operation.
For packed arrays VectorQ is constant time.
#Leonid's answer is very relevant too, please see it.
Regarding the performance hit (since your first question has been answered already) - by all means, do the checks, but in your top-level functions (which receive data directly from the user of your functionality. The user can also be another independent module, written by you or someone else). Don't put these checks in all your intermediate functions, since such checks will be duplicate and indeed unjustified.
EDIT
To address the problem of errors in intermediate functions, raised by #Nasser in the comments: there is a very simple technique which allows one to switch pattern-checks on and off in "one click". You can store your patterns in variables inside your package, defined prior to your function definitions.
Here is an example, where f is a top-level function, while g and h are "inner functions". We define two patterns: for the main function and for the inner ones, like so:
Clear[nlPatt,innerNLPatt ];
nlPatt= _?(!VectorQ[#,NumericQ]&);
innerNLPatt = nlPatt;
Now, we define our functions:
ClearAll[f,g,h];
f[vector:nlPatt]:=g[vector]+h[vector];
g[nv:innerNLPatt ]:=nv^2;
h[nv:innerNLPatt ]:=nv^3;
Note that the patterns are substituted inside definitions at definition time, not run-time, so this is exactly equivalent to coding those patterns by hand. Once you test, you just have to change one line: from
innerNLPatt = nlPatt
to
innerNLPatt = _
and reload your package.
A final question is - how do you quickly find errors? I answered that here, in sections "Instead of returning $Failed, one can throw an exception, using Throw.", and "Meta-programming and automation".
END EDIT
I included a brief discussion of this issue in my book here. In that example, the performance hit was on the level of 10% increase of running time, which IMO is borderline acceptable. In the case at hand, the check is simpler and the performance penalty is much less. Generally, for a function which is any computationally-intensive, correctly-written type checks cost only a small fraction of the total run-time.
A few tricks which are good to know:
Pattern-matcher can be very fast, when used syntactically (no Condition or PatternTest present in the pattern).
For example:
randomString[]:=FromCharacterCode#RandomInteger[{97,122},5];
rstest = Table[randomString[],{1000000}];
In[102]:= MatchQ[rstest,{__String}]//Timing
Out[102]= {0.047,True}
In[103]:= MatchQ[rstest,{__?StringQ}]//Timing
Out[103]= {0.234,True}
Just because in the latter case the PatternTest was used, the check is much slower, because evaluator is invoked by the pattern-matcher for every element, while in the first case, everything is purely syntactic and all is done inside the pattern-matcher.
The same is true for unpacked numerical lists (the timing difference is similar). However, for packed numerical lists, MatchQ and other pattern-testing functions don't unpack for certain special patterns, moreover, for some of them the check is instantaneous.
Here is an example:
In[113]:=
test = RandomInteger[100000,1000000];
In[114]:= MatchQ[test,{__?IntegerQ}]//Timing
Out[114]= {0.203,True}
In[115]:= MatchQ[test,{__Integer}]//Timing
Out[115]= {0.,True}
In[116]:= Do[MatchQ[test,{__Integer}],{1000}]//Timing
Out[116]= {0.,Null}
The same, apparently, seems to be true for functions like VectorQ, MatrixQ and ArrayQ with certain predicates (NumericQ) - these tests are extremely efficient.
A lot depends on how you write your test, i.e. to what degree you reuse the efficient Mathematica structures.
For example, we want to test that we have a real numeric matrix:
In[143]:= rm = RandomInteger[10000,{1500,1500}];
Here is the most straight-forward and slow way:
In[144]:= MatrixQ[rm,NumericQ[#]&&Im[#]==0&]//Timing
Out[144]= {4.125,True}
This is better, since we reuse the pattern-matcher better:
In[145]:= MatrixQ[rm,NumericQ]&&FreeQ[rm,Complex]//Timing
Out[145]= {0.204,True}
We did not utilize the packed nature of the matrix however. This is still better:
In[146]:= MatrixQ[rm,NumericQ]&&Total[Abs[Flatten[Im[rm]]]]==0//Timing
Out[146]= {0.047,True}
However, this is not the end. The following one is near instantaneous:
In[147]:= MatrixQ[rm,NumericQ]&&Re[rm]==rm//Timing
Out[147]= {0.,True}
Since ListQ just checks that the head is List, the following is a simple solution:
foo[a:{___?NumberQ}] := Module[{}, a + 1]
The main point of this question is the logic behind the operation of the first argument of TraceScan (as well as the associated fourth argument but that is not needed for the problem in question): it sometimes excludes some evaluation steps (which Trace with option TraceOriginal->True gives) but sometimes it includes them as demonstrated in the following examples. I am interested in understanding the logic behind this behavior and how to force TraceScan to give the full set of evaluation steps. This question originally arose in this thread (see my comments to the answer). The general comparison of the behavior of TraceScan as compared to that of Trace was given by WReach here but it does not answer the following questions:
1.) Why doesn't TraceScan give the final expression f[a,1] in this
case while Trace gives:
In[1]:= SetAttributes[traceScan,HoldAll];
traceScan[expr_]:=(list={};TraceScan[AppendTo[list,#]&,expr];list)
In[3]:= ClearAll[f,a];
Trace[f[a,1],TraceOriginal->True]
Out[4]= {f[a,1],{f},{a},{1},f[a,1]}
In[5]:= ClearAll[f,a];
traceScan[f[a,1]]
Out[6]= {f[a,1],f,a,1}
2.) And, in the following case, why do both Trace and TraceScan give the
final expression f[1,a] wheras only Trace gives the intermediate expression
f[a,1] which corresponds to the step of the evaluation before applying the Orderless attribute of f:
In[7]:= ClearAll[f,a];
SetAttributes[f,Orderless]
Trace[f[a,1],TraceOriginal->True]
Out[9]= {f[a,1],{f},{a},{1},f[a,1],f[1,a]}
In[12]:= ClearAll[f,a];
SetAttributes[f,Orderless]
traceScan[f[a,1]]
Out[14]= {f[a,1],f,a,1,f[1,a]}
3.) And why in this last case do both Trace and TraceScan give the final
expression ff[1,b] and the intermediate expression ff[b,1] which corresponds to the step of the evaluation before applying the Orderless attribute of ff:
In[21]:= ClearAll[f,ff,a];
SetAttributes[ff,Orderless];f=ff;a=b;
Trace[f[a,1],TraceOriginal->True]
Out[23]= {f[a,1],{f,ff},{a,b},{1},ff[b,1],ff[1,b]}
In[24]:= ClearAll[f,ff,a];
SetAttributes[ff,Orderless];f=ff;a=b;
traceScan[f[a,1]]
Out[26]= {f[a,1],f,ff,a,b,1,ff[b,1],ff[1,b]}
4.) Is there a way to force TraceScan to always give exhaustive
information about evaluation as Trace does?
In addition
Here is another, more informative version of traceScan which uses the fourth argument:
SetAttributes[traceScan, HoldAll];
traceScan[expr_] := (list1 = list2 = {};
TraceScan[AppendTo[list1, #] &, expr, _,
AppendTo[list2, {##}]&];
Column[{list1, list2}])
Cases 1 and 2. Citing the Documentation:
Normally, ... Trace intercepts expressions only after function
arguments have been evaluated. By setting TraceOriginal->True, you
can get Trace also to look at expressions before function
arguments have been evaluated.
It seems that setting TraceOriginal->True just results in prepending additional information to the default output of Trace. As the result, we see unnecessary additional "intermediate expression" f[a,1] which in really does not appear in the evaluation chains in both cases as it is shown by TraceScan and TracePrint:
In[1]:= ClearAll[f, a];
SetAttributes[f, Orderless]
TracePrint[f[a, 1]]
During evaluation of In[1]:= f[a,1]
During evaluation of In[1]:= f
During evaluation of In[1]:= a
During evaluation of In[1]:= 1
During evaluation of In[1]:= f[1,a]
Out[3]= f[1, a]
So it looks like a bug in Trace.
Case 3. In this case everything works as expected because the intermediate expression ff[b,1] indeed appears in the evaluation chain as the result of applying of the definition associated with f. Nothing unexpected.
Conclusion. Both Trace and TraceScan give exhaustive information about evaluation chain but the output generated by Trace can additionally contain misleading "intermediate expression" which is in fact just the initial expression of the chain.
Suppose I want to construct something like
Array[#1^#2 == 3 &, {3, 3}]
And now I want to replace the "3" with a variable. I can do, for example:
f[x_] := Array[#1^#2 == x &, {x, x}]
The question is: Is there a way using only slots and & as the functional notation?
Not really the answer to the original question, but I noticed that many people got interested in #0 stuff, so here I put a couple of non-trivial examples, hope they will be useful.
Regarding the statement that for nested functions one should use functions with named arguments: while this is generally true, one should always keep in mind that lexical scoping for pure functions (and generally) is emulated in Mathematica, and can be broken. Example:
In[71]:=
Clear[f,g];
f[fun_,val_]:=val/.x_:>fun[x];
g[fn_,val_]:=f[Function[{x},fn[#1^#2==x&,{x,x}]],val];
g[Array,3]
During evaluation of In[71]:= Function::flpar: Parameter specification {3} in
Function[{3},Array[#1^#2==3&,{3,3}]] should be a symbol or a list of symbols. >>
During evaluation of In[71]:= Function::flpar: Parameter specification {3} in
Function[{3},Array[#1^#2==3&,{3,3}]] should be a symbol or a list of symbols. >>
Out[74]= Function[{3},Array[#1^#2==3&,{3,3}]][3]
This behavior has to do with the intrusive nature of rule substitutions - that is, with the fact that Rule and RuleDelayed don't care about possible name collisions between names in scoping constructs which may be present in expressions subject to rule applications, and names of pattern variables in rules. What makes things worse is that g and f work completely fine when taken separately. It is when they are mixed together, that this entanglement happens, and only because we were unlucky to use the same pattern variable x in the body of f, as in a pure function. This makes such bugs very hard to catch, while such situations do happen sometimes in practice, so I'd recommend against passing pure functions with named arguments as parameters into higher-order functions defined through patterns.
Edit:
Expanding a bit on emulation of the lexical scoping. What I mean is that, for example, when I create a pure function (which is a lexical scoping construct that binds the variable names in its body to the values of passed parameters), I expect that I should not be able to alter this binding after I have created a function. This means that, no matter where I use Function[x,body-that-depends-on-x], I should be able to treat it as a black box with input parameters and resulting outputs. But, in Mathematica, Function[x,x^2] (for instance) is also an expression, and as such, can be modified like any other expression. For example:
In[75]:=
x = 5;
Function[Evaluate[x],x^2]
During evaluation of In[75]:= Function::flpar: Parameter specification 5 in Function[5,x^2] should
be a symbol or a list of symbols. >>
Out[76]= Function[5,x^2]
or, even simpler (the essence of my previous warning):
In[79]:= 1/.x_:>Function[x,x^2]
During evaluation of In[79]:= Function::flpar: Parameter specification 1 in Function[1,1^2] should
be a symbol or a list of symbols. >>
Out[79]= Function[1,1^2]
I was bitten by this last behavior a few times pretty painfully. This behavior was also noted by #WReach at the bottom of his post on this page - obviously he had similar experiences. There are other ways of breaking the scope, based on exact knowledge of how Mathematica renames variables during the conflicts, but those are comparatively less harmful in practice. Generally, I don't think these sorts of things can be avoided if one insists on the level of transparency represented by Mathematica expressions. It just seems to be "over-transparent" for pure functions (and lexical scoping constructs generally), but on the other hand this has its uses as well, for example we can forge a pure function at run-time like this:
In[82]:= Block[{x},Function##{x,Integrate[HermiteH[10,y],{y,0,x}]}]
Out[82]= Function[x,-30240 x+100800 x^3-80640 x^5+23040 x^7-2560 x^9+(1024 x^11)/11]
Where the integral is computed only once, at definition-time (could use Evaluate as well). So, this looks like a tradeoff. In this way, the functional abstraction is better integrated into Mathematica, but is leaky, as #WReach noted. Alternatively, it could have been "waterproof", but perhaps for the price of being less exposed. This was clearly a design decision.
How about
Map[Last, #] & /# Array[#1^#2 == #3 &, {#, #, #}] &[3]
Horrendously ugly element extraction, and very interestingly Map[Last, #]& gives me a different result than Last /#. Is this due to the fact that Map has different attributes than &?
I guess you know what the documentation says about nested pure functions.
Use explicit names to set up nested
pure functions (for example):
Function[u, Function[v, f[u, v]]][x]
Anyway, here's the best I could come up with without following the above advice:
f[x_] := Array[#1^#2 == x &, {x, x}]
g = Array[With[{x = #}, #1^#2 == x &], {#, #}] &
g is functionally identical to your original f, but is not really better than the recommended
h = Function[x, Array[#1^#2 == x &, {x, x}]]
How about With[{x = #1}, Array[#1^#2 == x &, {x, x}]] &?
Perhaps
Array[#1^#2 &, {#, #}] /. i_Integer :> i == # &[3]
Or
Thread /# Thread[# == Array[#1^#2 &, {#, #}]] &[3]
The mathematica documentation on Evaluate at possible issues says:
Evaluate works only on the first
level, directly inside a held function
Why does Mathematica have this limitation? So if I have an expression with more than one level take this simplified example:
Hold[Plus[Plus[2, 2], 2]]]
Now suppose I want to see what the answer is to the the second Plus, without evaluating anything on levels below it. I've tried different things such as:
In[290]:= Hold[Plus[Evaluate[Plus[2, 2]], 2]]
Out[290]= Hold[Evaluate[2+2]+2]
In[287]:= Hold[Plus[ReleaseHold[Hold[Plus[2, 2]]], 2]]
Out[287]= Hold[ReleaseHold[Hold[2+2]]+2]
The first Hold keeps everything unevaluated at and beyond the first level in this case.
The goal is to control evaluation of an expression at each stage from the most inner nested function to the outer one using successive Hold, ReleaseHold and Evaluate functions to achieve that. I know I could use trace to see what happens beyond level one in an expression but that is different and sometimes complex to read with longer expressions.
It seems like the only way is to extract and totally dismantle the expression into lists using Extract, Part or Level; evaluate part of the expression that I want; then reconstruct and re-map the expression back together for each stage. Are there any other approaches or functions for achieving this I could consider?
Edit: This might be a better example to look at the approach of releasing the first hold. With the expression:
Hold[Plus[Plus[2, Plus[2,2]], 2]]]
If you release the first hold and place a hold on a higher level in a expression at the third Plus, to look like this:
in = Plus[Plus[2, Hold[Plus[2,2]]], 2]]]
out = Hold[2+2]+4
You find that Mathematica will evaluate lower levels in the background when you really want it to wait.
I can't give the exact reason why Evaluate "works only on the first level, directly inside a held function" but I suspect it's partly efficiency, in that it would be slow if the evaluator had to scan the complete expression tree of held arguments passed to any function with a Hold* attribute for nested Evaluate expressions and evaluate them, and then recurse and look for Evaluate subexpressions in what it just evaluated, all while keeping the rest of the expression unevaluated, especially when this might not always be what you want to happen anyway.
Doing what you want is pretty easy using a combination of Extract and ReplacePart though:
In[51]:= expr = Hold[Plus[Plus[2, 2], 2]];
In[52]:= ReleaseHoldAt[expr_, partspec_] :=
ReplacePart[expr, partspec -> Extract[expr, partspec]]
In[53]:= ReleaseHoldAt[expr, {1, 1}]
Out[53]= Hold[4 + 2]
This lets us illustrate another reason why it might not make sense for Evaluate to work at any level in an expression passed as an argument to a function with a Hold* attribute, considering the following expression involving i:
In[82]:= i = 1;
In[83]:= ReleaseHoldAt[Hold[i = 2; j = Plus[i, i]], {1, 2}]
Out[83]= Hold[i = 2; 2]
Note that the value of j would have been 4 if we had evaluated the first part of that expression before the Plus, but the results are different since we are only doing partial evaluation, and i=2 had not been evaluated when we evaluated the subexpression setting j. Sometimes, this may be what you want to happen, but often it is very likely not.
Keep in mind that even Evaluate in the first level can be defeated by a function that has the attribute HoldAllComplete or by using HoldComplete:
In[62]:= Hold[Evaluate[Plus[2,2]]]
Out[62]= Hold[4]
...versus:
In[63]:= HoldComplete[Evaluate[Plus[2,2]]]
Out[63]= HoldComplete[Evaluate[2+2]]
Finally, the output of Trace can be a little dense, but you can filter out what you want by using patterns or symbols of interest in the second argument:
In[88]:= Trace[Plus[Plus[Plus[1,2],3],4],Plus]
Out[88]= {{{1+2,3},3+3,6},6+4,10}
In[93]:= Trace[Plus[Subtract[Plus[1,2],4],8],_Plus]
Out[93]= {{{1+2}},-1+8}
HTH!
As is so often the case when you want to do something tricky in Mathematica, pattern matching and rule replacement come to the rescue. However, in this instance, you have to do something weird, and you have to use Replace instead of ReplaceAll (the /. operator) so you can take advantage of its optional third argument to give it a level specification. Using the example you offered:
In[1]:= Replace[
Hold[Plus[Plus[2, 2], 2]],
expr_Plus :> With[{eval = expr}, eval /; True],
{2}]
Out[1]= Hold[4 + 2]
The useless-looking
expr_Plus :> With[{eval = expr}, eval /; True]
rule is actually a documented way to share local variables between the test match and the body of the With structre; here you don't do anything with the local variable but force its evaluation in a roundabout way---because less roundabout ways won't work!
EDIT to add: I think you're mis-interpreting the result of Level; the two expressions at level {2} of this expression are 2 and Plus[2, 2]; you can see this by using the optional third argument to level, which does something similar to the optional third argument of Extract:
In[2]:= Level[Hold[Plus[Plus[2, 2], 2]], {2}, Hold]
Out[2]= Hold[2 + 2, 2]
With the {2} level spec, Replace will try to match-and-replace the rule against these two expressions, and it will work on the second one.
A technique which does not involve Extractis to wrap the parts inside Hold in inner Holds, and then release the outer Hold:
expr=Hold[(1+2)+3];
ReleaseHold#Map[Hold,expr,{2}]
Out[2]= Hold[3]+Hold[1+2]
You can play various games in this direction, but since I can't tell what it is you want to do, it is a bit hard to be specific. Something that might be useful is to define your own Hold that descents however you want it to:
SetAttributes[DescentHold,{HoldAll}]
DescentHold[a_Plus]:=ReleaseHold#Map[DescentHold,Hold[a],{2}]
DescentHold[a_]:=Hold[a]
Note that this one approaches the outer Holds once the insides are wrapped, so that for instance the flatness of Plus kicks in:
DescentHold[2*3+(4+5)]
Out[4]= Hold[4]+Hold[5]+Hold[2*3]
Using the idea about ReplacePart and Extract functions from the answer by Michael Pilat, one can write HoldAndEvaluate function, which allows him to evaluate a desired part of the expression without the need to calculate its position (it can be marked with "MyEvaluate").
In[1]:= expr = Hold[MyEvaluate[2 + 2] + 2];
In[2]:= HoldAndEvaluate[expr_] :=
ReplacePart[expr,
# -> Evaluate ## Extract[expr, #] & /#
Position[expr, MyEvaluate[_]] ];
In[3]:= HoldAndEvaluate[expr]
Out[3]= Hold[4 + 2]