Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2012

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

Search the Archive

Re: Slow plotting of reflected parametric "butterflies"

  • To: mathgroup at smc.vnet.net
  • Subject: [mg124487] Re: Slow plotting of reflected parametric "butterflies"
  • From: Bill Rowe <readnews at sbcglobal.net>
  • Date: Sat, 21 Jan 2012 05:17:39 -0500 (EST)
  • Delivered-to: l-mathgroup@mail-archive0.wolfram.com

On 1/20/12 at 1:52 AM, cy56 at comcast.net (Christopher Young) wrote:

>On Jan 19, 2012, at 11:59 AM, Murray Eisenberg wrote:

>>I don't have any suggestions, at least yet, on speeding up your
>>code.

>However, you should avoid naming things "C" and "D", since those
>names stand for objects already built into Mathematica. In fact,
>didn't you notice that running your code gives Shadowing warning
>messages?

>I know I shouldn't name globals "C" or "D", and I try to avoid it,
>but isn't Mathematica now sophisticated enough to allow localized
>variables "C" and "D" as long as they don't have the same form as
>the functions? I.e., it allows "overloading" of those symbols. At
>any rate, I'll see if avoiding that speeds things up. Meanwhile, my
>guess is that using lists of functions in ParametricPlot3D is the
>main source of the slow-down, so I'm rewriting the curves as regular
>one-item functions.

A few comments:

In most cases, Mathematica is able to get the result you want
using C etc as localized variables. But, this is still bad
coding in my opinion for several reasons.

It makes your code harder to understand.

Clearly, when you overload built-in parameters Mathematica must
do more to select the correct form. That must have some
performance impact.

=46inally, it makes your code more fragile. Any program with the
complexity of Mathematica will always have some bugs or
unintended side effects. These are far more likely to be a
problem for code with potential conflicts such as using C for a
local variable.

Best practice is simply don not use a single uppercase letter as
a variable. Then you are guaranteed no conflicts.

As for your code, you are using FullSimplify every time in the
function CurvedButterfly is called. FullSimply is generally an
expensive function to use in terms of cpu time. But, it looks
like you are supplying machine precision numbers for the values
of A,B,C,D etc. If so, FullSimplify won't do anything. By
default, Mathematica will evaluate your expression to a machine
precision value whenever all values are numeric and at least one
is machine precision. So, if I've understood your code, you will
be feeding FullSimplify a machine number and there is nothing to simplify.

Also, expr//Flatten[#,1]& does exactly the same thing as
expr//Flatten using expr//Flatten will be faster. That is:

In[7]:= d = RandomReal[1, {500, 500, 500}];

In[8]:= Timing[d // Flatten[#, 1] &;]

Out[8]= {0.640754,Null}

In[9]:= Timing[d // Flatten;]

Out[9]= {0.449603,Null}

As a general rule of thumb, using simpler forms is faster.




  • Prev by Date: Re: Daylight savings time in DatePlus.
  • Next by Date: Re: Slow plotting of reflected parametric "butterflies"
  • Previous by thread: Re: Slow plotting of reflected parametric "butterflies"
  • Next by thread: Re: Slow plotting of reflected parametric "butterflies"