MathGroup Archive 2004

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

Search the Archive

Re: Re: Compile

  • To: mathgroup at smc.vnet.net
  • Subject: [mg45519] Re: [mg45511] Re: Compile
  • From: Selwyn Hollis <sh2.7183 at misspelled.erthlink.net>
  • Date: Sun, 11 Jan 2004 03:20:21 -0500 (EST)
  • References: <bto1j0$2ip$1@smc.vnet.net> <200401102143.QAA11555@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

I've been following this thread, and I just have one question: If you 
think Mathematica is such a a piece of crap, why don't you use 
something else? Life is short.

-----
Selwyn Hollis
http://www.math.armstrong.edu/faculty/hollis
(edit reply-to to reply)


On Jan 10, 2004, at 4:43 PM, Maxim wrote:

>
>
> "Simons, F.H." wrote:
>
>> 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
> To: mathgroup at smc.vnet.net
>>> Sent: woensdag 7 januari 2004 23:31
>>> To: mathgroup at smc.vnet.net
>>> Subject: [mg45519] [mg45511]  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 lin
> es 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
>
> If we use Trace, we can see that Mathematica evaluates a 
> CompiledFunction for several values of x:
>
> Trace[
>   Module[
>     {y := x + If[NumericQ[x], 1, 0]},
>     Plot[y, {x, 0, 1}, Compiled -> True,
>       PlotPoints -> 3, PlotDivision -> 1]
>   ],
>   TraceInternal -> True, TraceOff -> Show
> ]
>
> So it cannot be equivalent to using Compiled->False. In fact, the 
> situation is the opposite of what you describe: CompiledFunction 
> appears in the second example (shown above), but not in the first one 
> (with y := If[NumericQ[x], 1, 0]).
>
> How does this CompiledFunction give a numeric result then? You forget 
> that Plot works like Block, so effectively we have a CompiledFunction 
> inside of a Block:
>
> In[1]:=
> Module[
>   {y := x, cf},
>   cf = Compile[{x}, y];
>   Block[{x = 1},
>     cf[2]
> ]]
>
> Out[1]=
> 1.
>
> The argument of CompiledFunction isn't plugged in anywhere, but x is 
> evaluated in the context set up by Block. Actually this was already 
> explained by Hartmut Wolf.
>
> Besides, what is "evaluation of the compiled argument"? Without 
> assigning any value to the iterator variable? Then, according to your 
> theory, when Mathematica needs to execute Plot[x,{x,0,1}] it evaluates 
> the expression to be plotted, which evaluates to x, which isn't 
> numerical, so Mathematica switches to Compiled->False. Evidently, it 
> doesn't work that way.
>
> At the very least, please get my name right the next time...
>
> Maxim Rytin
> m.r at prontomail.com
>
>
>


  • Prev by Date: RE: Many Functions Into One
  • Next by Date: Re: Compile
  • Previous by thread: Re: Compile
  • Next by thread: Re: Re: Compile