Re: Compile
- To: mathgroup at smc.vnet.net
- Subject: [mg45032] Re: Compile
- From: Maxim <dontsendhere@.>
- Date: Sat, 13 Dec 2003 06:06:34 -0500 (EST)
- References: <br9hbr$cut$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
"Wolf, Hartmut" wrote: > >-----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: [mg45032] 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 "run-time will shorten"? As in an old joke, "allows you to get incorrect results faster"? (Incorrect in the sense of the uncompiled While semantics, of course). Actually if you do run some tests, you will see that one-argument While can take more time compiled than uncompiled: In[1]:= Module[{cnt}, Do[cnt = 0; While[cnt++; cnt < 1], {10^5}]; 0 ] // Timing Out[1]= {1.813 Second, 0} In[2]:= Compile[{}, Module[{cnt}, Do[cnt = 0; While[cnt++; cnt < 1], {10^5}]; 0 ]][] // Timing Out[2]= {10.015 Second, 0} What is really important is this: suppose I give you two examples and ask you how they'll work: Compile[{}, Module[{cnt = 0}, While[cnt++; cnt < 1]; cnt ] ][] and Compile[{}, Module[{cnt = -1}, While[cnt++; cnt < 1]; cnt ] ][] It's impossible to answer without running both examples and learning about this quirk in the While evaluation. I don't know what you mean in your message by "debugged for Compile" and "checked for correctness", but are you sure that's how you're supposed to learn a programming language? "I know that While[cond] will evaluate this way when compiled and While[cond,body] will evaluate that way because I tried it"? Sorry, that's ridiculous. Try looking at the bigger picture -- suppose you have to develop a large application (and then have to locate such glitches in thousands lines of code). How can you be sure that something else but similar won't come up? As to the second example, I'm saying that in case of side effects result will be unpredictable and you give me an example without side effects. Okay...I guess. Maxim Rytin m.r at prontomail.com