Items tagged with blog blog Tagged Items Feed

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

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.

Inside a procedure, local variables are evaluated only one level. Of what good is this, one might ask?

Well, for one thing it allows you to do checks or manipulations of an unevaluated function call without having that function call be evaluated over again. I mean, for function calls to routines which don't happen to remember earlier results.

This is a revision of an Answer

There have been some recent posts about interpolating data.

Attached below is a worksheet that shows some possibilities, with the functionality centering on the CurveFitting:-ArrayInterpolation command.

This is quick summary of parts of a broader document which covers both 2-d and 3-d methods (for regular grids), where I've left out the higher-efficiency methods and instead roughed in some examples involving integration and differentiation.

I've elected not to follow the 3-d Example from the ArrayInterpolation command's help-page, although using a pre-formed grid is a very fast approach to obtain just an interpolated 3-d plot. I also prefer to use the plots:-surfdata command rather than the plots:-matrixplot command, since the former let's one get the axes' tickmarks correct for the x- and y-data ranges.

The scenario is that you have a grid of data points in two dimensions (x- and y, or P- and T-, or what have you).

For each point (ie, for each 2-d pair of values) you have an associated value (or height in z, say). Hence you actually have data points in 3-d space.

How you obtained the associated (z) values depends on your own particular data collection method, or your own program. How you got the data is irrelevant here. What matters is that you have the finite number of data values, and no other easy way to generate data values at more points (let alone data for arbitrary new points). Below, we'll just create the data (once, at the start) for this example using an entirely made-up formula.

The presumption is that you might wish to plot a smooth surface that connects the 3-d data.

But you might also wish to write some program which requires interpolated (z) values at some new (x,y) 2-d points.  And you do not yet know what these 2-d point pairs are. So a pre-formed Array of points  at which to interpolate may not suffice.

Instead of using a pre-formed Array of output points, we'll contruct a procedure named `B` which can be supplied with a new (x,y) 2-d output point and (if that point lies within the original range) return an interpolated (z) value.

This procedure `B` can also be plotted, using the usual `plot3d` comamnd. It won't plot quite as fast as would a pre-computed and pre-interpolated finer grid of (x,y) values, but it should plot nicely. And the surface can be made quite smooth, by merely increasing the number of plotted points using plot3d's usual numpoints option. (Maple does not currently do "adaptive" 3-d plotting, so there's also no advantage in that respect.) But `B` does solve the secondary task, of being able to compute for any subsequent (x,y) point.

We can even integrate and differentiate `B` numerically. Of course we should keep in mind that this is somewhat error prone, since on top of usual issues with numerical differentiation there is also fact that we make the choice of interpolation method! The entire interpolated surface will differ considerably according to whether a spline, cubic (or other) interpolating scheme is chosen!

We'll use P and T as the x- and y- grid points, below, since "a name is just a name" and our choice of variables is arbitarary.

plot_interp.mw

One useful feature of the `evalf` command is that it remembers previous results. But it also stores the current value of Digits as well as its input argument, to be associated with the remembered result.

There are two reasons for this. The fancier reason is so that, when Digits is reduced from that of an earlier successful computation, `evalf` can simply round off the earlier result to the desired number of decimal digits. The more basic reason is that `evalf` might...

The goal of computing only a select number of eigenvectors of a real symmetric floating-point Matrix comes up now and then. For very large Matrices the memory requirements can be more restrictive than the timing.

The attached worksheet and code computes this, more quickly and with significantly less memory allocation than does the usual task of computing all eigenvectors. By using the supplied Matrix itself as a partial "workspace" the amount of additional workspace and memory allocation for the task is negligible.

For example, having created the very large Matrix in the first place,  essentially no significant further memory allocation is required to compute the largest eigenvalue and its associated eigenvector.

A little about this routine `SelectedEigenvectors` follows.

It only works in hardware double precision. It expects a float[8] datatype Matrix (because you are serious about using minimal memory!). It uses the CLAPACK function dsyevx, using the "wrapperless" version of Maple's external-calling mechanism. It seems to work fine in the systems I've tried so far: Maple 13 and 14 on both 32bit and 64bit Linux and Windows.

Whether it computes and returns the selected eigenvectors (alongside the selected eigenvalues, which are always returned) is controlled by the 'vectors=truefalse' optional argument. By default it uses the Matrix argument as partial workspace and so destroys the original data; but this can be overridden with the 'preserve=true' optional argument. The requested accuracy can be relaxed with the 'epsilon=float' optional argument, which might sometimes speed it up.

The input Matrix is presumed to be symmetric. By default it uses the data in the lower triangle, but this can be changed to be the upper triangle with the 'uplo' optional argument.

The choice of eigenvalues is controlled by the two integer arguments `il` and `iu`. If il=iu=n then only the nth largest eigenvalue is computed. If il=1 and iu=4 then the four smallest eigenvalues are computed.

It returns three things: a Vector of dimension n whose first m entries are the selected eigenvalues, a nxm Matrix whose columns are the m associated eigenvectors, and a Vector of dimension n whose entries indicate whether corresponding eigenvectors failed to converge.

I didn't enable float arguments such as `vl` and `vu` which in principle could allow one to supply a floating-point range in which to find eigenvalues.

I didn't make an optimization of having it do an initial "dummy" external call in which no calculation would be done, but which would instead query for and subsequently utilize the optimal-performance additonal float workspace size.

For reasons mysterious to me, on Windows the 64bit version runs almost exactly half as fast as the 32bit version.

Usually, the workspace for eigen-solving is implemented to be at least O(n^2) for an nxn Matrix. But this routine does only O(m+n) extra workspace allocation to compute the m eigenvectors. And that is linear. Which is the Big Deal.

A 5000x5000 datatype=float[8] (ie. hardware double precision) Matrix takes 200MB of memory. With the preserve=true option, this routine can compute just the largest eigenvector with only about 200MB of additional allocation. And if the original Matrix is no longer required then with the preserve=false option this routine can do that task with less than 1MB further allocation. In comparison, the regular LinearAlgebra:-Eigenvectors command would require about 600MB of additional memory allocation while computing all eigenvectors.

At size 5000x5000 this routine is only about four times faster than LinearAlgebra:-Eigenvectors. I suspect that is because it still has to compute in full the reduction to tridiagonal form.

Download dsyevx.mw

This is just a programmatic twist on Robert Lopez's very nice original post on this topic.

I'd rather be able to control such declarations with code, than to have to manipulate the palettes or context menus in order to get what are -- in essence -- additional programming and authoring tools. Such code can be dynamic and flexible, and could be inserted in Code- or Startup regions.

Download atomicpartials.mw

Introduction to this blog

From time to time, I find some problem with Maple. It is not always Maple's bug, sometimes it is just my mistake.

I am used to use "Submit Software Change Request " form, but I dont know how to trace my requests (and I even dont exactly remember which bugs I posted). Thus, I decided to publish my troubles in this blog.

Unless stated otherwise, all the troubles I specify bellow are obtained on the Mac OS X 10.5 PPC platform using Maple 14.01 ...

While doing some Maple plotting I found myself asking why a high-end scientific computation application like Maple, which is capable of essentially very high ("arbitrary") precision floating-point computation, sometimes makes only crude use of hardware precision plot drivers. I looked around a bit, and found that and related issues are not restricted to Maple.

Let's look first at Maxima. Here's my first example, in Maxima (not Maple) syntax,

since i can't find the answer in F.A.Q or by searching so i started this thread on my curiosity on BLOGGING ...

i want to know is there anyway that common members can promote to a degree that allow them become a BLOG Contributor in mapleprimes ?

what are Qualifications and Requirements ?

thanks a lot for your guides and comments !