RE: Compile
- To: mathgroup at smc.vnet.net
- Subject: [mg44961] RE: [mg44950] Compile
- From: "Wolf, Hartmut" <Hartmut.Wolf at t-systems.com>
- Date: Thu, 11 Dec 2003 05:28:07 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
>-----Original Message----- >From: Maxim [mailto:dontsendhere@.] To: mathgroup at smc.vnet.net >Sent: Wednesday, December 10, 2003 10:02 AM >To: mathgroup at smc.vnet.net >Subject: [mg44961] [mg44950] Compile > > >Consider > >In[1]:= >Compile[{}, > Module[{x=0}, > While[ > x++; > EvenQ[x] > ]; > x > ] >][] > >Out[1]= >3 > >incorrect. The more I think about this wonderful sentence from Compile >reference -- "The number of times and the order in which objects are >evaluated by Compile may be different from ordinary >Mathematica code" -- >the less I understand it. It can mean that if compiled evaluation fails >at some point, Mathematica stops and starts over with the >ordinary code. >But equally well it can be interpreted to mean that Compile may ignore >all the rules of the standard evaluator, including operators precedence >order. > >Of course, in a sense Compile is still in the development stage; for >instance, I don't like the fact that Do[0,{i,1},{j,i,1}] cannot be >compiled because of i in the second iterator, but in this case >Mathematica just gives a message, reverts to uncompiled >evaluation and I >can see what is going on, while if an expression is compiled and >evaluated differently from uncompiled version, I'm at a loss what went >wrong. > >Actually restarting the evaluation can be quite confusing too, >since you >can't tell at which point Mathematica begins the re-evaluation using >uncompiled code, so if the code has side effects then the result is >unpredictable, as in the example below: > >In[1]:= >Module[{L={}}, > Compile[{}, > AppendTo[L,{1}]; > AppendTo[L,{2}]; > Append[L,{3}]; > AppendTo[L,{3}]; > L > ][] >] > >Compile::cpts: The result after evaluating Insert[L$11, {3}, -1] > should be a tensor. Non-tensor lists are not supported at present; >evaluation will > proceed with the uncompiled function. > >CompiledFunction::cfse: Compiled expression {{1}, {2}} should be a >machine-size real number. > >CompiledFunction::cfex: > External evaluation error at instruction 4; proceeding with >uncompiled evaluation. > >Out[1]= {{1}, {2}, {1}, {2}, {3}} > >Maxim Rytin > >m.r at prontomail.com > Compile translates a subset of Mathematica to intermediate code for virtual machine which definitely is different from the Mathematica Interpreter, such unavoidably different results will come up. This is not conceiled from WRI. Instead, run-time will shorten for problems suitable to compilation. Such code to be Compiled has, in a sense, to be regarded as a different language: the syntax is not quite the same, nor the semantics. So code which is interpreted, has yet to be debugged for Compile (which, for shure, often is not quite such easy!). And after it compiles, not not to be forgotten: checked for correctness (in the Range of intented application)! You just can't leave that out, as you cannot for C, Fortran, ..., whatever, and no one would complain. If I do that with your code, I get: In[5]:= Compile[{}, Module[{x = 0}, While[x++; EvenQ[x],]; x]][] Out[5]= 1 and In[26]:= Module[{Llama = {}}, Compile[{{L, _Integer, 2}}, AppendTo[L, {1}]; AppendTo[L, {2}]; Append[L, {3}]; AppendTo[L, {3}]; L][Unevaluated[Llama]]] >From In[26]:= CompiledFunction::"cfta": "Argument \!\(Llama$27\) at position \!\(1\) should \ be a rank \!\(2\) tensor of \!\(\"machine-size integer\"\)s." Out[26]= {{1}, {2}, {3}} Both results are correct, although, the second example is far off the "specification" of Compile! -- Hartmut Wolf