Items tagged with blog blog Tagged Items Feed

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

This should be a blog post but there is no option for ordinary mapleprimers. 

If you have a gmail account you can access the data on google insights (what people search for on google and where in the world is that keyword searched the most).  Actually you don't need gmail but you don't get access to the full data and your limited to a few searches.  Using Maples internet connectivity commands I'm sure could prove to create some interesting apps.

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:

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

Yesterday I wrote a post that began,

"I realized recently that, while 64bit Maple 15 on Windows (XP64, 7) is now using accelerated BLAS from Intel's MKL, the Operating System environment variable OMP_NUM_THREADS is not being set automatically."

But that first sentence is about where it stopped being correct, as far as how I was interpreting the performance on 64bit Maple on Windows. So I've rewritten the whole post, and this is the revision.

I concluded that, by setting the Windows operating system environment variable OMP_NUM_THREADS to 4, performance would double on a quad core i7. I even showed timings to help establish that. And since I know that memory management and dynamic linking can cause extra overhead, I re-ran all my examples in freshly launched GUI sessions, with the user-interface completely closed between examples. But I got caught out in a mistake, nonetheless. The problem was that there is extra real-time cost to having my machine's Windows operating system dynamically open the MKL dll the very first time after bootup.

So my examples done first after bootup were at a disadvantage. I knew that I could not look just at measured cpu time, since for such threaded applications that reports as some kind of sum of cycles for all threads. But I failed to notice the real-time measurements were being distorted by the cost of loading the dlls the first time. And that penalty is not necessarily paid for each freshly launched, completely new Maple session. So my measurements were not fair.

Here is some illustration of the extra real-time cost, which I was not taking into account. I'll do Matrix-Matrix multiplication for a 1x1 example, to try and show just how much this extra cost is unrelated to the actual computation. In these examples below, I've done a full reboot on Windows 7 where so annotated. The extra time cost for the very first load of the dynamic MKL libraries can be from 1 to over 3 seconds. That's about the same as the cpu time this i7 takes to do the full 3000x3000 Matrix multiplication! Hence the confusion.

Roman brought up hyperthreading in his comment on the original post. So part of redoing all these examples, with full restarts between them, is testing each case both with and without hyperthreading enabled (in the BIOS).

Quad core Intel i7. (four physical cores)

Hyperthreading disabled in BIOS
-------------------------------

> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);   # NULL, unset in OS

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.18KiB, alloc change=127.98KiB, cpu time=219.00ms, real time=3.10s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns


> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);
                              "4"

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.91KiB, alloc change=127.98KiB, cpu time=140.00ms, real time=2.81s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns


Hyperthreading enabled in BIOS
------------------------------

> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);    # NULL, unset in OS

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.00KiB, alloc change=127.98KiB, cpu time=202.00ms, real time=2.84s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns


> restart: # actual OS reboot
> getenv(OMP_NUM_THREADS);
                              "4"

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=215.56KiB, alloc change=127.98KiB, cpu time=187.00ms, real time=1.12s

> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ):
memory used=9.46KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns


Having established that the first use after reboot was incurring a real time penalty of a few seconds, I redid the timings in order to gauge the benefit of having OMP_NUM_THREADS set appropriately. These too were done with and without hyperthreading enabled. The timings below appear to indicate that slightly bettern performance can be had for this example in the case that hyperthreading is disabled. The timings also appear to indicate that having OMP_NUM_THREADS unset results in performance competitive with having it set to the number of physical cores.

Hyperthreading disabled in BIOS
-------------------------------

> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.84KiB, alloc change=127.98KiB, cpu time=141.00ms, real time=142.00ms

> getenv(OMP_NUM_THREADS);  # NULL, unset in OS

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.50s, real time=1.92s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.84KiB, alloc change=127.98KiB, cpu time=141.00ms, real time=141.00ms

> getenv(OMP_NUM_THREADS);
                              "1"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.38s, real time=7.38s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=217.11KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);
                              "4"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.57s, real time=1.94s



Hyperthreading enabled in BIOS
------------------------------

> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.57KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);  # NULL, unset in OS

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=8.46s, real time=2.15s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.80KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);
                              "1"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=7.35s, real time=7.35s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.80KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);  # NULL, unset in OS
                              "4"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=8.56s, real time=2.15s


> restart:
> CodeTools:-Usage( Matrix([[3.]]) . Matrix([[3.]]) ): # initialize external libs
memory used=216.80KiB, alloc change=127.98KiB, cpu time=125.00ms, real time=125.00ms

> getenv(OMP_NUM_THREADS);
                              "8"

> M:=LinearAlgebra:-RandomMatrix(3000,datatype=float[8]):
> CodeTools:-Usage( M . M ):
memory used=68.67MiB, alloc change=68.74MiB, cpu time=8.69s, real time=2.23s

With all those new timing measurements it appears that having to set the global environment variable OMP_NUM_THREADS to the number of physical cores may not be necessary. The performance is comparable, when that variable is left unset. So, while this post is now a non-story, it's interesting to know.

And the lesson about comparitive timings is also useful. Sometimes, even complete GUI/kernel relaunch is not enough to get a level and fair field for comparison.

Maple 15, Windows7x64, Standard v. Classic

I have noticed that, on my system, the smoothness of some INLINE plots is better in Classic than in Standard. Is this some regression or some installation-specific quirck I wonder?

In Tools->Options, I have plot anti-aliasing enabled (whatever that is).

This looks alright in Classic

plots:-implicitplot(
  [ x^2 + y^2 = 1, x^2 + y^2 = 2 ]
  , x = -2 .. 2
  , y = -2 .. 2

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

pre-sized plots

September 24 2011 by acer 6926 Maple

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

Maplesoft Employee

Paper Models of 3D Plots

September 09 2011 by Paul 290 Maple

 

                

3D Paper Physical Model

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

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

A short remark. This would be a blog entry if those still existed.

I am comparing plot,options.

The style=point option has versatile options for symbols, their sizes, the number of points:

  , 'style' = point
  , 'numpoints' = 50
  , 'symbol' = solidcircle
  , 'symbolsize' = 8

 

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

 

 

 

Click any point above, & Drag

 

Download plotslider1.mw

 

1 2 3 4 5 6 7 Page 1 of 7