RE: RE: RE: Re: Compile
- To: mathgroup at smc.vnet.net
- Subject: [mg45547] RE: [mg45488] RE: [mg45446] RE: [mg45430] Re: Compile
- From: "Wolf, Hartmut" <Hartmut.Wolf at t-systems.com>
- Date: Tue, 13 Jan 2004 04:04:01 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Dear Fred, think you'r right. When I had sent my message you'r referring, on my way home, or at home, I saw that my "phantasy" was ridiculous. Then, in fact, I suspected just what you suppose here (but wasn't able to proof it). I only was disturbed by not getting the message "using the uncompiled code", but that applies to a different case, when an error occurs at compilation not at execution, and uncompiled _code_ indeed is used. But here it means switching to a different mode of passing the plot variable. I think now, your explanation not only is correct, but also very consistent. And predictable, BTW. So the recipe for the cautious is simple: if replacement semantics wouldn't work, and you need to compile for what reason ever, compile by yourself, and insert the compiled function into Plot with option Compiled -> False, such using Block semantics. A more precise inspection of the trace reveals that (in Maxim's example as cited by myself) the CompiledFunction is only called three times (whereas y is executed 3 + 2 times), such again whe cannot see the machinery for binding of the plot variable to the "compiled expression", nor the "compiled expression" itself. I now interpret the occurrence of CompiledFunction in the Trace as an indication of "switching back", not to uncompiled code but to the Block semantics (what you called UNCOMPILED MODE, but definitely using the CompiledFunction) -- just as I had proposed above to do by yourself (as to get a predictable result). Hartmut >-----Original Message----- >From: Simons, F.H. [mailto:F.H.Simons at tue.nl] To: mathgroup at smc.vnet.net >Sent: Friday, January 09, 2004 4:28 PM >To: Wolf, Hartmut; mathgroup at smc.vnet.net; m.r at prontomail.com >Cc: Martens, F.J.L.; Simons, F.H. >Subject: [mg45547] RE: [mg45446] RE: [mg45430] Re: Compile > > > >Maxim Retin produced two examples asking to explain why they >behave as they do. As Hartmut Wolf already pointed out, the >first example is completely predictable in the way discussed >earlier. So let us turn to Maxim's second example: > >> -----Original Message----- >> From: Wolf, Hartmut [mailto:Hartmut.Wolf at t-systems.com] To: mathgroup at smc.vnet.net >> Sent: woensdag 7 januari 2004 23:31 >> To: mathgroup at smc.vnet.net >> Subject: [mg45547] [mg45446] RE: [mg45430] Re: Compile >> >...... >> Your new example shows up other "interesting things" (to >those who are >> interested of course). >> >> In[27]:= >> y := (Print[x]; x + If[NumericQ[x], 1, 0]); >> Trace[Plot[y, {x, 0, 1}, Compiled -> True, AspectRatio -> Automatic, >> PlotPoints -> 3], x | y, TraceInternal -> True] // InputForm >> >From In[27]:= x >> >From In[27]:= x >> >From In[27]:= 5.*^-7 >> >From In[27]:= 0.486804 >> >From In[27]:= 1. > >.......... >> What is new, are obviously two (additional) evaluations of y when x has no >> value, before doing the plot. What comes to my phantasy is a compilator in >> desperate search of the variable x to become bound, detecting it when an >> exterior variable becomes evaluated, and now binding it (as in contrary of >> above) in a function call. (y however is not evaluated within the compiled >> expression.) >> >> >Here my phantasy went into a different direction. > >To start with, let us simplify Maxim's example. > >y:= Sin[x] >Plot[y, {x, 0, 3}] > >indeed produces a plot of the sine function, as expected(?!). >But a further reflection shows that this is not obvious. The >option Compiled is True, so Mathematica starts with compiling >y as a function of x. The compiled result contains the symbol >y. Then, since Compiled is set to True, the numerical values >are substituted (not assigned) into the compiled function and >therefore have no effect on the symbol y. This symbol now >evaluates to Sin[x] which is not numerical and therefore the >graph cannot be plotted. However, we do see the graph of the >sine, so my explanation along the lines of my previous message >seems to be incorrect. That is what Maxim's example suggests. > >To see what is going on, have a look at the following commands: > >Clear[y]; >fc = Compile[{{x, _Real}}, y]; > >y:= (Print[x]; Sin[x]); >fc[0.3] > >First the symbol x is printed, then an error message that the >symbol Sin[x] is not numerical, then the message that the >uncompiled code will be used, which results in another >evaluation of y and therefore the printing of x, and the >outcome Sin[x]. > >Now let us look at the Plot command: > >y := (Print[x];Sin[x]); >Plot[y, {x, 0, 3}] > >What happens? First Mathematica compiles y as a function of x. >Then evaluations starts by substituting (not assigning) a >numerical value of x in the compiled function. Then y is >evaluated and x is printed, the evaluation of the compiled >function fails so the uncompiled code will be used, resulting >in another printing of x and a non-numerical value of the >function AND NOW MATHEMATICA SIMPLY SWITCHES TO THE UNCOMPILED >MODE and makes the plot as if the option Compiled was set to >False. Therefore the result of the plot command is what was >hoped that the result would be. Obviously this is not a rigid >mathematical proof that is happening, but it explains what is >going on, including Maxim's examples. > >Two of Maxim's examples now are particularly illustrative: > >y := If[NumericQ[x], 1, 0] >Plot[y, {x,0,1}] > >Evaluation of the compiled argument results in 0, so the >result is the horizontal axis. > >y := x+ If[NumericQ[x], 1, 0] >Plot[y, {x,0,1}] > >Evaluation of the compiled argument results in x, which is not >numerical. So the plotting switches to Compiled->False, and >x+1 is plotted. > >Fred Simons >Eindhoven University of Technology >