Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

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

Search the Archive

Re: Problem with transformation rules in Plot

  • To: mathgroup at smc.vnet.net
  • Subject: [mg48519] Re: [mg48498] Problem with transformation rules in Plot
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Fri, 4 Jun 2004 04:49:36 -0400 (EDT)
  • References: <200406020822.EAA15585@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

On 2 Jun 2004, at 17:22, Alain Cochard wrote:

>
> Hello.  I would be grateful if someone could explain to me the
> following behavior (i.e., is it normal? why?), or point me to a
> relevant part of a manual:
>
> Mathematica 4.0 for Linux
> Copyright 1988-1999 Wolfram Research, Inc.
>  -- Motif graphics initialized --
>
> In[1]:= f[x_]:=a x ; g[x_]:=2 a x ;
>
> In[2]:= Plot[ f[x]/.{a->1} , {x,0,1}]  (* Fine *)
>
> Out[2]= -Graphics-
>
> In[3]:= {f[x],g[x]}/.{a->1}
>
> Out[3]= {x, 2 x}  (* Fine, just checking *)
>
> In[4]:= Plot[{f[x],g[x]}/.{a->1} , {x,0,1}]
>
> Plot::plnr: {f[x], g[x]} /. {a -> 1} is not a machine-size real number 
> at x =
>               -8
>     4.16667 10  .
>
> Plot::plnr: {f[x], g[x]} /. {a -> 1} is not a machine-size real number 
> at x =
>     0.040567.
>
> Plot::plnr: {f[x], g[x]} /. {a -> 1} is not a machine-size real number 
> at x =
>     0.0848088.
>
> General::stop: Further output of Plot::plnr
>      will be suppressed during this calculation.
>
> Out[4]= -Graphics-
>
> (* So the question is: why does it work for f[x] alone, and not for
> f[x] and g[x]? *)
>
> (* The following works fine, but is there a better workaround? *)
>
> In[5]:= data={a->1} ; Plot[{ f[x]/.data , g[x]/.data }, {x,0,1}]
>
>
> Many thanks in advance,
> Alain Cochard
>
>
>
Actually, the correct approach is in all your cases this:

Plot[Evaluate[{f[x], g[x]} /. {a -> 1}], {x, 0, 1}]


The reason why you need Evaluate is that Plot evaluates its arguments 
in a special way, and it generally preferable when your function are 
not defined inline to force pre-evaluation with Evaluate.
There are several reasons for this. Even in cases when Plot works 
without Evaluate as in your first example, you will get better 
performance when you use it. (There are also certain situations when 
pre-evaluation will not work, these are the cases when the functions to 
be plotted can't be evaluated unless supplied a numerical argument).

As for the reason for the difference between the cases of one function 
and several in your examples, it is essentially this. To plot the graph 
of several functions simultaneously Plot has to know that that it has 
to plot several functions, since it to do that it uses a different 
algorithm from the one that it uses to Plot a single function. But how 
does it now when to switch to this code? Well, it has to be able to see 
that the argument supplied is a list of at least two objects, which it 
than takes as the functions to be plotted. So the Head of the 
expression to be plotted has to be List, but in your case:

Plot[{f[x], g[x]} /. {a -> 1}, {x, 0, 1}]

the Head of the expression to be plotted is actually ReplaceAll. You 
can solve this problem, as you yourself noticed, by moving ReplaceAll 
inside List as follows:

Plot[{f[x]/.a->1, g[x]/.a->1} , {x, 0, 1}]

This will now work because Plot can see that it is supposed to plot the 
graphs of two functions enclosed in List. But still it is much better 
to use Evaluate.




Andrzej Kozlowski
Chiba, Japan
http://www.mimuw.edu.pl/~akoz/


  • Prev by Date: Re: Extract substrings using metacharacters
  • Next by Date: Re: how to take quotation marks away ?
  • Previous by thread: Problem with transformation rules in Plot
  • Next by thread: Re: Problem with transformation rules in Plot