MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

RE: RE: RE: Re: Compile

  • To: mathgroup at
  • Subject: [mg45547] RE: [mg45488] RE: [mg45446] RE: [mg45430] Re: Compile
  • From: "Wolf, Hartmut" <Hartmut.Wolf at>
  • Date: Tue, 13 Jan 2004 04:04:01 -0500 (EST)
  • Sender: owner-wri-mathgroup at

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).


>-----Original Message-----
>From: Simons, F.H. [mailto:F.H.Simons at]
To: mathgroup at
>Sent: Friday, January 09, 2004 4:28 PM
>To: Wolf, Hartmut; mathgroup at; m.r at
>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]
To: mathgroup at
>> Sent: woensdag 7 januari 2004 23:31
>> To: mathgroup at
>> 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
>> value, before doing the plot. What comes to my phantasy is a  compilator
>> desperate search of the variable x to become bound, detecting it when an
>> exterior variable becomes evaluated, and now binding it (as in contrary
>> above) in a function call. (y however is not evaluated within the
>> 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:
>fc = Compile[{{x, _Real}}, y];
>y:= (Print[x]; Sin[x]);
>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 
>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

  • Prev by Date: Re: Re: Compile
  • Next by Date: Univers font
  • Previous by thread: Re: Compile
  • Next by thread: Re: Compile