In Mma 9 using CompilationOptions -> {"InlineExternalDefinitions" -> True} inside of Compile inlined the values of the previously defined parameters used in the function to be compiled.

For example:

nPara = 3;
cf = Compile[{{x, _Real, 1}},
  Sum[x[[i]], {i, nPara}], 
  CompilationOptions -> {"InlineExternalDefinitions" -> True}

resultes in:

Output Mma9

and works flawless as expected.

But in Mma 10 the output is:

Output Mma10

And, as now the value of nPara is not known to the compiled function, the comiled function doesn't work anymore.

For such a simple function one can apply Whith as a workaround:

With[{nPara = nPara},
 Compile[{{x, _Real, 1}},
  Sum[x[[i]], {i, nPara}], 
  CompilationOptions -> {"InlineExternalDefinitions" -> True}

However, in bigger notebooks and with more complex functions this undocumented code break (or is a bug or a fix) causes bigger issues.

Does anyone know a more convenient or automated workaround to fix this problem?

  • 2
    $\begingroup$ On the other hand,nPara = 3; cf = Compile[{{x, _Real, 1}}, Total[x[[1 ;; nPara]]], CompilationOptions -> {"InlineExternalDefinitions" -> True}] works ok in v10. Is it the use of the Sum that breaks the compilation? $\endgroup$ Commented Jul 12, 2014 at 22:04
  • $\begingroup$ Sum itself is compilable. Also Compile[{{x, _Real, 1}}, Plus @@ x[[;; nPara]], CompilationOptions -> "InlineExternalDefinitions" -> True}] works fine. The real problem is, that it is not clear, when parameters are inlined and when not. Furthermore it would be nice to know when notebooks that worked in Mma v9 don't anymore in v10. $\endgroup$
    – Karsten7
    Commented Jul 12, 2014 at 22:44
  • $\begingroup$ Not inlined in this case, too: Compile[{{x, _Real, 1}}, Module[{sum = 0.}, Do[sum += x[[i]], {i, nPara}]], CompilationOptions -> {"InlineExternalDefinitions" -> True}] $\endgroup$
    – Michael E2
    Commented Jul 12, 2014 at 23:33
  • 1
    $\begingroup$ The value of the iterator is also not inlined for Table, but strangly is for Range. $\endgroup$
    – Karsten7
    Commented Jul 13, 2014 at 0:03
  • $\begingroup$ Using Compile[{{x, _Real, 1}}, Evaluate@Sum[x[[i]], {i, nPara}], CompilationOptions -> {"InlineExternalDefinitions" -> True}] will give some messages but completely compiles and works as expected. $\endgroup$
    – Karsten7
    Commented Jul 13, 2014 at 0:16

1 Answer 1


It is unfortunate that this no longer works. I like metaprogramming, and I felt that inlining variables is a nice exercise, so I can share some functions with you that make things easier.

Your approach using With seems reasonable. I also saw you test an example using Evaluate, but relying on the fact that x[[i]] evaluates to x[[i]] if i not an integer and x has no value is quite bad.

You say that your approach using With will not work for more complicated cases. If the issue is that you want to use evaluation to determine the values of your parameters, you can use the following.

SetAttributes[inlineEval, HoldAll];
inlineEval[expr_, symbols__] :=
 Unevaluated[expr] /. 
  Thread[Rule[HoldPattern /@ Unevaluated[{symbols}], {symbols}]]

You can use it as follows. Let's set up a situation that is relatively hard to deal with to test it.

b := c[1, 2]
c[x_, y_] := x + y

Now we can do

cfu =
   Compile[{{x, _Integer}}, Sum[1, {i, x + b}]]

If you don't want to use evaluation, you can use the following.

SetAttributes[inlineAll, HoldAll]
inlineAll[expr_, symbols__Symbol] :=
   HoldComplete[expr] //.
    Flatten[Function[Null, {OwnValues@#, DownValues@#}, HoldAll] /@ 

Now you can also this, but note that you have to specify that c has to be inlined as well.

cfu2 =
   Compile[{{x, _Integer}}, Sum[1, {i, x + b}]]
   b, c

Note that both functions also with symbols that have DownValues, which is something I believe "InlineExternalDefinitions" could not deal with to begin with. The previous examples dealt only with constants, but here is an example where we inline a function.

f[x_] := Norm[x];
cfu3 =
   Compile[{{x, _Real, 1}}, f[x] + 3]
cfu3[{1., 1.}] == Sqrt[2] + 3

This technique allows you to make large compiled functions, while maintaining readability. You could imagine that when compiled functions get too large, you simply let one compiled function call another compiled function, and optionally using "InlineCompiledFunctions". But I like this alternative :).

Related (but probably less nice than this)

  • $\begingroup$ This is very cool when defining new CompiledFunctions. Is it possible to automate the procedure of inlining every definition used in the function to be compiled? What are the disadvantages of your approach compared to using "InlineExternalDefinitions"->True? $\endgroup$
    – Karsten7
    Commented Jul 15, 2014 at 0:54
  • $\begingroup$ @Karsten7. it is hard to properly automate this. For example, in the code there is a Sum with iterator i. This iterator should not be replaced, as it is a local variable of the Sum. But there are a lot of functions with local variables. I'd say the main disadvantage of my approach is exactly this, that it's not automatic. $\endgroup$ Commented Jul 15, 2014 at 9:49
  • $\begingroup$ @Karsten7 also we didn't need RuleCondition. I have updated the answer. $\endgroup$ Commented Jul 15, 2014 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.