17
$\begingroup$

Today I noticed something, I think for the first time.

When used inside Compile variable values within Module (and Block) are sequentially shared:

Compile[{}, Module[{a = 7, b = a}, b + 1] ][]
8

Compare the behavior outside of Compile:

Module[{a = 7, b = a}, b + 1]
1 + a
  • Is this documented behavior or just a happy accident?

  • If undocumented can it be relied upon or should this "trick" be avoided?

$\endgroup$
3
  • 1
    $\begingroup$ Well, the Mathematica documentation does say "Compiled code does not handle numerical precision and local variables in the same way as ordinary Mathematica code. ". Module and Block still behave as you have observed in V9.0.1, so I guess it has some stability. $\endgroup$
    – m_goldberg
    Commented Feb 18, 2013 at 7:10
  • 4
    $\begingroup$ @m_goldberg given that the VM and the top-level interpreter have very little in common, that statement can be viewed something of a platitude... most of the VM behavior surely has to be considered as undocumented, and for the documentation simply to state that there are differences is hardly any help. $\endgroup$ Commented Feb 18, 2013 at 11:58
  • $\begingroup$ @OleksandrR. It may be a platitude, but its WRI's official platitude. :) $\endgroup$
    – m_goldberg
    Commented Feb 18, 2013 at 18:06

1 Answer 1

18
$\begingroup$

If you look at the generated code (CompilePrint, for example), the procedure is as follows:

  • All the program's constants are placed into separate registers (regardless of their location in the program, they can be in the r.h.s.of variable initialization in scoping constructs, or they can be statements in their bodies. Actually, same constants found in different part of a program share the same register).
  • The variables initialized by Module are placed into separate registers, one by one. This seems quite natural. There is no real need for Compile to actually implement nested scoping where one and the same variable can be shadowed and take another value in some inner block of code. So, it simply assigns different registers for different Module variables - which mimics what Module is doing in the top-level code where it does not really implement nested scoping a-la C, but generates unique symbols, which emulate it.
  • The binding semantics for nested scoping seems to be the same as for the top-level, in that the variables in code are bound to the smallest (innermost) scope containing that piece of code.
  • It looks like, for the purposes of Compile, Block and Module are the same (this refers to cases where the code can be fully compiled without callbacks to MainEvaluate. If such callbacks are present, Block may behave differently from Module, if it is a part of the top-level code executed in a callback). In other words, Compile does not implement dynamic scoping (except via callbacks to the main evaluator), and Block variables are also bound lexically.

Here is what CompilePrint gives for your example:

cmp = Compile[{}, Module[{a = 7, b = a}, b + 1]];
Needs["CompiledFunctionTools`"];

CompilePrint[cmp]
      No argument
      5 Integer registers
      Underflow checking off
      Overflow checking off
      Integer overflow checking on
      RuntimeAttributes -> {}

      I0 = 7
      I3 = 1
      Result = I4

     1    I1 = I0
     2  I2 = I1
     3  I4 = I2 + I3
     4  Return

and here is a more complicated example including nested Module-s and local variable naming conflicts:

cmp3 = 
  Compile[{},
    Module[{a = 7, b = a},
       b = a + b;
       Module[{b = b, a = b + 2}, a + b + 1]]];
CompilePrint[cmp3]


    No argument
    8 Integer registers
    Underflow checking off
    Overflow checking off
    Integer overflow checking on
    RuntimeAttributes -> {}

    I4 = 2
    I0 = 7
    I6 = 1
    Result = I7

1   I1 = I0
2   I2 = I1
3   I3 = I1 + I2
4   I2 = I3
5   I3 = I2
6   I5 = I3 + I4
7   I7 = I5 + I3 + I6
8   Return

Analyzing the register allocations in these examples confirms the procedure I suggested above. Given this, it looks like the effect you have noticed can be relied upon (but this has a status of an educated guess only).

$\endgroup$
2
  • $\begingroup$ Leonid, thanks as always for your analysis. One thing though: I don't think "for the purposes of Compile, Block and Module are the same" is quite correct. For example, try: list = {aa, bb, cc}; Compile[{}, Module[{aa = 5}, Print@list;]][] and then replace Module with Block. Perhaps that is not within the intended scope of your statement. $\endgroup$
    – Mr.Wizard
    Commented Feb 18, 2013 at 8:51
  • 3
    $\begingroup$ @Mr.Wizard The difference is because there is a call to MainEvaluate, and Block in this case is considered a part of that call, since that call is the top-level code. In my answer, I implied the fully compiled code. I will add a sentence to mention this, thanks. $\endgroup$ Commented Feb 18, 2013 at 8:55

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.