acer

Using techniques previously used for generating color images of logistic maps and complex argument, attached is a first draft of a new Mandelbrot set fractal image applet.

A key motive behind this is the need for a faster fractal generator than is currently available on the Application Center as the older Fractal Fun! and Mandelbrot Mania with Maple entries. Those older apps warn against being run with too high a resolution for the final image, as it would take too long. In fact, even at a modest size such as 800x800 the plain black and white images can take up to 40 seconds to generate on a fast Intel i7 machine when running those older applications.

The attached worksheet can produce the basic 800x800 black and white image in approximately 0.5 seconds on the same machine. I used 64bit Maple 15.01 on Windows 7 for the timings. The attached implementration uses the Maple Compiler to attain that speed, but should fall back to Maple's quick evalhf mode in the case that the Compiler is not properly configured or enabled.

The other main difference is that this new version is more interactive: using sliders and other Components. It also inlines the image directly (using a Label), instead of as a (slow and resource intensive) density plot.

Run the Code Edit region, to begin. Make sure your GUI window is shown large enough for you to see the sides of the GUI Table conveniently.

The update image appearing in the worksheet is stored in a file, the name of which is currently set to whatever the following evaluates to in your Maple,

cat(kernelopts('homedir'),"/mandelbrot.jpg"):

You can copy the current image file aside in your OS while experimenting with the applet, if you want to save it at any step. See the start of the Code Edit region, to change this filename setting.

Here's the attachment. Comments are welcome, as I'd like to make corrections before submitting to the Application Center. Some examples of images (reduced in size for inclusion here) created with the applet are below.

The Locator object is a nice piece of Mathematica's Manipulate command's functionality. Perhaps Maple's Explore command could do something as good.

Here below is a roughly laid out example, as a Worksheet. Of course, this is not...

Here is a short wrapper which automates repeated calls to the DirectSearch 2 curve-fitting routine. It offers both time and repetition (solver restart) limits.

The global optimization package DirectSearch 2 (see Application Center link, and here) has some very nice features. One aspect which I really like is that it can do curve-fitting: to fit an expression using tabular data. By this, I mean that it can find optimal values of parameters present in an expression (formula) such that the residual error between that formula and the tabular data is minimized.

Maple itself has commands from the CurveFitting and Statistics packages for data regression, such as NonlinearFit, etc. But those use local optimization solvers, and quite often for the nonlinear case one may need a global optimizer in order to produce a good fit. The nonlinear problem may have local extrema which are not even close to being globally optimal or provide a close fit.

Maplesoft offers the (commercially available) GlobalOptimization package as an add-on to Maple, but its solvers are not hooked into those mentioned curve-fitting commands. One has to set up the proper residual-based objective function onself in order to use this for curve-fitting, and some of the bells and whistles may be harder to do.

So this is why I really like the fact that the DirectSearch 2 package has its own exported commands to do curve-fitting, integrated with its global solvers.

But as the DirectSearch package's author mentions, the fitting routine may sometimes exit too early. Repeat starts of the solver, for the very same parameter ranges, can produce varying results due to randomization steps performed by the solver. This post is branched off from another thread which involved such a problematic example.

Global optimization is often a dark art. Sometimes one may wish to simply have the engine work for 24 hours, and produce whatever best result it can. That's the basic enhancement this wrapper offers.

Here is the wrapper, and a few illustrative calls to it on the mentioned curve-fitting example that show informative  progress status messages, etc. I've tried to make the wrapper pretty generic. It could be reused for other similar purposes.

Other improvements are possible, but might make it less generic. A target option is possible, where attainment of the target would cause an immediate stop. The wrapper could be made into an appliable module, and the running best result could be stored in a module local so that any error (and ensuing halt) would not wipe out the best result from potentially hours and hours worth of conputation.

restart:
randomize():

repeater:=proc(  funccall::uneval
               , {maxtime::numeric:=60}
               , {maxiter::posint:=10}
               , {access::appliable:=proc(a) SFloat(a[1]); end proc}
               , {initial::anything:=[infinity]}
              )
          local best, current, elapsed, i, starttime;
            starttime:=time[real]();
            elapsed:=time[real]()-starttime;
            i:=1; best:=[infinity];
            while elapsed<maxtime and i<=maxiter do
              userinfo(2,repeater,`iteration `,i);
              try
                timelimit(maxtime-elapsed,assign('current',eval(funccall)));
              catch "time expired":
              end try;
              if is(access(current)<access(best)) then
                best:=current;
                userinfo(1,repeater,`new best `,access(best));
              end if;
              i:=i+1;
              elapsed:=time[real]()-starttime;
              userinfo(2,repeater,`elapsed time `,elapsed);
            end do;
            if best<>initial then
              return best;
            else
              error "time limit exceeded during first attempt";
            end if;
          end proc:


X := Vector([seq(.1*j, j = 0 .. 16), 1.65], datatype = float): 

Y := Vector([2.61, 2.62, 2.62, 2.62, 2.63, 2.63, 2.74, 2.98, 3.66,
             5.04, 7.52, 10.74, 12.62, 10.17, 5, 2.64, 11.5, 35.4],
            datatype = float):

F := a*cosh(b*x^c*sin(d*x^e));

                                    /   c    /   e\\
                         F := a cosh\b x  sin\d x //

infolevel[repeater]:=2: # or 1, or not at all (ie. 0)
interface(warnlevel=0): # disabling warnings. disable if you want.

repeater(DirectSearch:-DataFit(F
                      , [a=0..10, b=-10..10, c=0..100, d=0..7, e=0..4]
                      , X, Y, x
                      , strategy=globalsearch
                      , evaluationlimit=30000
                              ));
repeater: iteration  1
repeater: new best  9.81701944539358706
repeater: elapsed time  15.884
repeater: iteration  2
repeater: new best  2.30718902535293857
repeater: elapsed time  22.354
repeater: iteration  3
repeater: new best  0.627585701120743822e-4
repeater: elapsed time  30.777
repeater: iteration  4
repeater: elapsed time  47.959
repeater: iteration  5
repeater: new best  0.627585700905294148e-4
repeater: elapsed time  55.221
repeater: iteration  6
repeater: elapsed time  60.009
 [0.0000627585700905294, [a = 2.61748237902808, b = 1.71949329097179, 

   c = 2.30924401405164, d = 1.50333106110324, e = 1.84597267458055], 4333]


# without userinfo messages printed
infolevel[repeater]:=0:
repeater(DirectSearch:-DataFit(F
                      , [a=0..10, b=-10..10, c=0..100, d=0..7, e=0..4]
                      , X, Y, x
                      , strategy=globalsearch
                      , evaluationlimit=30000
                              ));

 [0.0000627585701341043, [a = 2.61748226209478, b = 1.71949332125427, 

   c = 2.30924369227236, d = 1.50333090706676, e = 1.84597294290477], 6050]


# illustrating early timeout
infolevel[repeater]:=2:
repeater(DirectSearch:-DataFit(F
                      , [a=0..10, b=-10..10, c=0..100, d=0..7, e=0..4]
                      , X, Y, x
                      , strategy=globalsearch
                      , evaluationlimit=30000
                              ),
         maxtime=2);

repeater: iteration  1
repeater: elapsed time  2.002
Error, (in repeater) time limit exceeded during first attempt

# illustrating iteration limit cutoff
infolevel[repeater]:=2:
repeater(DirectSearch:-DataFit(F
                      , [a=0..10, b=-10..10, c=0..100, d=0..7, e=0..4]
                      , X, Y, x
                      , strategy=globalsearch
                      , evaluationlimit=30000
                              ),
         maxiter=1);

repeater: iteration  1
repeater: new best  5.68594272127419575
repeater: elapsed time  7.084
 [5.68594272127420, [a = 3.51723075672918, b = -1.48456068506828, 

   c = 1.60544055207338, d = 6.99999999983179, e = 3.72070034285212], 2793]


# giving it a large total time limit, with reduced userinfo messages
infolevel[repeater]:=1:
Digits:=15:
repeater(DirectSearch:-DataFit(F
                      , [a=0..10, b=-10..10, c=0..100, d=0..7, e=0..4]
                      , X, Y, x
                      , strategy=globalsearch
                      , evaluationlimit=30000
                              ),
         maxtime=2000, maxiter=1000);

repeater: new best  3.10971990123465947
repeater: new best  0.627585701270853103e-4
repeater: new best  0.627585700896181428e-4
repeater: new best  0.627585700896051324e-4
repeater: new best  0.627585700895833535e-4
repeater: new best  0.627585700895607885e-4
 [0.0000627585700895608, [a = 2.61748239185387, b = -1.71949328487160, 

   c = 2.30924398692221, d = 1.50333104262348, e = 1.84597270535142], 6502]

Suppose that you wish to animate the whole view of a plot. By whole view, I mean that it includes the axes and is not just a rotation of a plotted object such as a surface.

One simple way to do this is to call plots:-animate (or plots:-display on a list of plots supplied in a list, with its `insequence=true` option). The option `orientation` would contain the parameter that governs the animation (or generates the sequence).

But that entails recreating the same plot each time. The plot data might not even change. The key thing that changes is the ORIENTATION() descriptor within each 3d plot object in the reulting data structure. So this is inefficient in two key ways, in the worst case scenario.

1) It may even compute the plot's numeric results, as many times as there are frames in the resulting animation.

2) It stores as many instances of the grid of computed numeric data as there are frames.

We'd like to do better, if possible, reducing down to a single computation of the data, and a single instance of storage of a grid of data.

To keep this understandable, I'll consider the simple case of plotting a single 3d surface. More complicated cases can be handled with revisions to the techniques.

Avoiding problem 1) can be done in more than one way. Instead of plotting an expression, a procedure could be plotted, where that procedure has `option remember` so that it automatically stores computed results an immediately returns precomputed stored result when the arguments (x and y values) have been used already.

Another way to avoid problem 1) is to generate the unrotated plot once, and then to use plottools:-rotate to generate the other grids without necessitating recomputation of the surface. But this rotates only objects in the plot, and does alter the view of the axes.

But both 1) and 2) can be solved together by simply re-using the grid of computed data from an initial plot3d call, and then constructing each frame's plot data structure component "manually". The only thing that has to change, in each, is the ORIENTATION(...) subobject.

At 300 frames, the difference in the following example (Intel i7, Windows 7 Pro 64bit, Maple 15.01) is a 10-fold speedup and a seven-fold reduction is memory allocation, for the creation of the animation structure. I'm not inlining all the plots into this post, as they all look the same.

restart:
P:=1+x+1*x^2-1*y+1*y^2+1*x*y:

st,ba:=time(),kernelopts(bytesalloc):

plots:-animate(plot3d,[P,x=-5..5,y=-5..5,orientation=[A,45,45],
                       axes=normal,labels=[x,y,z]],
               A=0..360,frames=300);

time()-st,kernelopts(bytesalloc)-ba;

                                1.217, 25685408

restart:
P:=1+x+1*x^2-1*y+1*y^2+1*x*y:

st,ba:=time(),kernelopts(bytesalloc):

g:=plot3d(P,x=-5..5,y=-5..5,orientation=[-47,666,-47],
          axes=normal,labels=[x,y,z]):

plots:-display([seq(PLOT3D(GRID(op([1,1..2],g),op([1,3],g)),
                           remove(type,[op(g)],
                                  specfunc(anything,{GRID,ORIENTATION}))[],
                           ORIENTATION(A,45,45)),
                    A=0..360,360.0/300)],
               insequence=true);

time()-st,kernelopts(bytesalloc)-ba;

                                0.125, 3538296

By creating the entire animation data structure manually, we can get a further factor of 3 improvement in speed and a further factor of 3 reduction in memory allocation.

restart:
P:=1+x+1*x^2-1*y+1*y^2+1*x*y:

st,ba:=time(),kernelopts(bytesalloc):

g:=plot3d(P,x=-5..5,y=-5..5,orientation=[-47,666,-47],
          axes=normal,labels=[x,y,z]):

PLOT3D(ANIMATE(seq([GRID(op([1,1..2],g),op([1,3],g)),
                           remove(type,[op(g)],
                                  specfunc(anything,{GRID,ORIENTATION}))[],
                           ORIENTATION(A,45,45)],
                    A=0..360,360.0/300)));

time()-st,kernelopts(bytesalloc)-ba;

                                0.046, 1179432                            

Unfortunately, control over the orientation is missing from Plot Components, otherwise such an "animation" could be programmed into a Button. That might be a nice functionality improvement, although it wouldn't be very nice unless accompanied by a way to export all a Plot Component's views to GIF (or mpeg!).

The above example produces animations each of 300 frames. Here's a 60-frame version:

I wanted to set the background color of a plot to black (without axes shown) and figured I could add this to the PLOT structure: POLYGONS([[10,0],[0,0],[0,10],[10,10]],COLOUR(RGB, 0., 0., 0.))

And that worked fine. But I feel that it ought to be easier.

It is possible to thicken the axes of 2D plots by adjusting the underlying data structure, since the appropriately placed THICKNESS() call within the PLOT() data structure is recognized by the Standard GUI. This does not seem to be recognized for PLOT3D structures, however.

The issue of obtaining thicker axes for 2D plots can then be resolved by first creating a plot, and then subsequently modifying the PLOT structure.

The same techniques could be used to thin...

I was recently looking at rotating a 3D plot, using plottools:-rotate, and noticed something inefficient.

In the past few releases of Maple, efficient float[8] datatype rtables (Arrays or hfarrays) can be used inside the plot data structure. This can save time and memory, both in terms of the users' creation and manipulation of them as well as in terms of the GUI's ability to use them for graphic rendering.

What I noticed is that, if one starts with a 3D plot data structure containing a float[8] Array in the MESH portion, then following application of plottools:-rotate a much less efficient list-of-lists is produced in the resulting structure.

Likewise, an effiecient float[8] Array or hfarray in the GRID portion of a 3D plot structure gets transformed by plottools:-rotate into an inefficient list-of-lists object in the MESH portion of the result. For example,

restart:

p:=plot3d(sin(x),x=-6..6,y=-6..6,numpoints=5000,style=patchnogrid,
          axes=box,labels=[x,y,z],view=[-6..6,-6..6,-6..6]):

seq(whattype(op(3,zz)), zz in indets(p,specfunc(anything,GRID)));
                            hfarray

pnew:=plottools:-rotate(p,Pi/3,0,0):

seq(whattype(op(1,zz)), zz in indets(pnew,specfunc(anything,MESH)));
                              list

The efficiency concern is not just a matter of the occupying space in memory. It also relates to the optimal attainable methods for subsequent manipulation of the data.

It may be nice and convenient for plottools to get as much mileage as it can out of plottools:-transform, internally. But it's suboptimal. And plotting is a topic where dedicated, optimized helper routines for some particular data format is justified and of merit. If we want plot manipulation to be fast, then both Library-side as well as GUI-side operations need more case-by-case-optimizated.

Here's an illustrative worksheet, using and comparing memory performance with a (new, alternative) procedure that does inplace rotation of a 3D MESH. plot3drotate.mw

The goal here is to produce plots for inclusion inside Worksheets or Documents of the Standard GUI at specific sizes.

When manually resizing an existing plot, using the mouse pointer, there is no visual cue as to what pixel size has been attained. Hence any worksheet author who wishes to produce a plot of size 600x600 is presented with two barriers. The first is that resizing must be done manually, and the second is that there is no convenient mechanism showing the actual size attained.

The `Resize` package attempts to address these barriers by allowing construction of a plot, inside a worksheet, with programmatically specified width and height in pixels.

The default behaviour of the package is to produce the plot inside a new Worksheet, from whence it may be selected and copied. An optional behaviour is to show the constructed plot inside a Task Template (a form of help-page), where it may be previewed for correctness and inserted into the current Worksheet or Document at the press of a single button.

It appears to function for both 2D and 3D single plots.

It won't work for so-called Array plots, which are collections of multiple plots displayed side-by-side inside a worksheet table.

This first version is a bit rough. The plot is currently being inserted as input, which is why it isn't centered on the page. I suspect that it would be best to insert the first argument (eg. a `plot` call) as input to an execution group, and then have the plot be the output. That would look, and hopefully act, just as usual. And with the plot call inserted as input, the original `Resize` call could be neatly deleted if desired.

To install this thing, use the File->Open from the Standard GUI's menubar. Choose this .mla file as the thing to open. (You may have to slide a scrollbar, and select a view of "All Files", in order to see it in the pop-up File Manager.) Double-clicking on the file, to launch it, should ideally also open it but it looks like that functionality broke for Maple 15.

Resize_installer.mla

Alternatively, you could run the command,

march( 'open', "...full...path...to...Resize_installer.mla");

The attached .mla archive is a (graphically) self-unpacking installer, when opened in this way.

The bundled materials include a pre_built .mla containing the package itself, the source code and a worksheet that rebuilds it from source if desired, a short example worksheet, and a worksheet that rebuilds the whole installer (and re-bundles all those files into it). I used the `InstallerBuilder` to make the self-unpacking .mla installer, as I think it's a handy tool that is under-appreciated (and, alas, under documented!).

It's supposed to work without the usual hassle of having to set `libname`. This is an automatic consequence of the place in which it gets installed.

It seems to work in Maple 12, 14, and 15, on Windows 7. Let me know if you have problems with it.

acer

I saw an image yesterday of some math done similar to how one can write on paper, with each new reformulation shown on the next line, with a down-arrow between each such line. In other words, operations and output moving down the sheet rather than along it to the right.

The first thing that came to mind was: can this be done in Maple with context-menus?

Here is an attempt,

    cm_downwards.mw

Most programs will not produce and assign to a large number of global "top-level" names. But it is interesting that the cost associated with such global name assignment is related to the number of entries in libname.

A possible cause of this cost is the need to check whether the name is protected, before assigning.

The following timings were made on 32bit Maple 15 running on Windows 7, on an Intel i7. The set of four timings is...

It may be of interest to this community that the original Maple Project at the University of Waterloo was awarded the ACM SIGSAM Richard Dimick Jenks Memorial Prize in June, at the joint ISSAC/SNC 2011 conference (overlap with FCRC 2011).

See here for the announcement.

The complexplot3d command can color by using (complex) argument for the hue, and compute height z by magnitude. So, when rotated to view the x-y plane straight on, it can provide a nice coloring of the argument of whatever complex-valued expression is being plotted.

Another way to obtain a similar plot is to use densityplot (with appropriate values for its scaletorange option) and apply argument to the expression or function being plotted. For some kinds of complex-valued...

The ability to color a 3D plot using a color function is geared more for functions of x and y only.

But quite often, the surface or pointwise 3D position of the plot is itself being specified as a height z which is a function of x and y. For the plot3d comand, that's pretty much the way it works (whether using an expression or a procedure).

So, of course, the very same rule that...

A Plot Component (on the right below) can act as a kind of 2-dimensional "slider" for inputing values of two parameters at once.

The polar plot (on the left below) makes use of both values.

If you click in the right Plot, and drag around the mouse cursor for a while, then the left Plot will be continuously updated.

Make sure to execute the collapsed code-edit region, to initialize it. (Just click on it, to execute. Or expand, look, and right-click on it.)

Download plotslider1.mw

This is in response to a Question about the speed and memory use of an animated DEplot. The problems are that the example's animation was slow to create, and prohibitively expensive to save in a Document.

An alternative approach is to combine multiple calls to plots:-odeplot with a call to plots:-fieldplot to supply the background flow arrows. This is a lot faster. It takes less memory to create and run, but the GUI may still consume too much resources saving it. The good news is that it's so much faster that it's not inconvenient to re-run the entire thing from scratch. And so it's quite feasible to remove all the expensive output from the Document prior to saving and thus avoid the whole resources problem.

The original questioner also wanted to visualize with resect to two varying parameters. So I've also done an implementation of that using Embedded Components and two Sliders.

Here is the old DEplot animation. It takes about 40 sec to create it animation on an Intel i7.

Here is the new combined odeplot+fieldplot animation. It takes a second or two to create its animation on an Intel i7.

Here is the DEplot in Embedded Components. It's very slow, and the image doesn't change smoothly with the sliders.

Here is the new combined odeplot+fieldplot in Embedded Components. Its image changes pretty smoothly with the sliders.

I encourage completely quitting the GUI (not just restart, or close Document and re-Open) between comparison runs of these implementations, of you want to get a really good feel for the effects of both running them as well as saving them (with and without all output).

For the Embedded Component documents, the functioning code resides inside the "initialize" button. (right-click, go to Component Properties, Action When Clicked, only if you want to inspect it.) To run those two  Documents, execute all the commands (use the triple-exclam from the menubar if you like), and then press the "initialize" button, and then move the sliders.

The difference in performance is related partly to the use of hardware datatype Arrays in the PLOT structures generated by odeplot and fieldplot. (But an `arrow` primitive would help even more!)

And (I think) there is improvement by virtue of using dsolve/numeric/parameters in the use of `odeplot`. That saves overhead from repeated cold invocations of dsolve/numeric. And DEplot doesn't support that, since it expects as argument the system of DEs and ICs. The newer `odeplot` command accepts the procedure returned by dsolve/numeric, and thus allows for efficient repeated setting of parameter values. The `fieldplot` command doesn't need the solution of the DE system at all: it just needs the DEs.

I would have considered wrapping the whole combined approach up into a single command, but it might have to accept separate options for the view ranges, in order to always look its best. A smart version might be able to deduce the computed ranges from the odeplot output, and then create the background fieldplot based on that.