There are two pieces of extended functionality that I quite often want from the Maple Compiler. The first (task A) is to be able to link in and use an arbitrary function from some other external ("3rd party") shared library, within my Compile'd Maple procedure. The second (task B) is to directly call the compiled Maple procedure from within some computational routine in a 3rd party shared library (which I would then access using define_external). This post is about the first of those, task A.

A user recently asked how to find the set of indices corresponding to a given value of a two-dimensional Array.

There are several ways to handle this problem.  For  a single value, a simple scan through the Array suffices:

FindIndices1 := proc(A :: Array, val)
local i,j,irng,jrng;
    (irng,jrng) := rtable_dims(A);
    {seq(seq(`if`(A[i,j]=val, [i,j], NULL), i=irng), j=jrng)};
end proc:

With a multi-core machine, the ...

Jacques' post on the maple.vim project spurred this post.  Vim users cannot have all the fun.

About a year ago I wrote an Emacs front-end for the Maple debugger.  I've used it since---it is now my primary debugging tool for Maple code.  What it does is allow stepping through interpreted Maple code in an Emacs buffer.  That is, rather than being presented with a single line of...

There is a probem in the Optimization package's (nonlinear programming problem) NLPSolve routine which affects multivariate problems given in so-called Operator form. That is, when the objective and constraints are not provided as expressions. Below is a workaround for this.

Usually, an objective (or constraint) gets processed by Optimization using automatic differentiation tools ...

The greatest benefits from bringing Maple into the classroom are realized when the static pedagogy of a printed textbook is enlivened by the interplay of symbolic, graphic, and numeric calculations made possible by technology.  It is not enough merely to compute or check answers with Maple.  To stop after noting that indeed, Maple can compute the correct answer is not a pedagogical breakthrough.

It has been a while since my last post, mostly because of a combination of getting Maple 14 ready to ship and a lack of meaty topics to write about. I am trying to get back into the habit of posting more regularly. You can help me achieve my goal by posting questions about parallel programming. I'll do my best to answer. However for now, I'll give a brief overview of the new parallel programming features in Maple 14.

A new function has been added to the Task Programming Model. The Threads:-Task:-Return function allows a parallel algorithm implemented on top of the Task Programming Model to perform an early bail out. Lets imagine that you have implemented a parallel search. You are looking for a particular element in a large set of data. Using the Task Programming Model, you've created a bunch of tasks, each searching a particular subset of the data. However one of the first tasks to execute finds the element you are looking for. In Maple 13, there was no built in way of telling the other tasks that the result have been found and they they should not execute. In Maple 14, the Return function allows one task to specify a return value (which will be returned from Threads:-Task:-Start) and signal the other tasks that the algorithm is complete and that additional tasks should not be executed. Tasks that are already running will still run to completion, but tasks that have not started executing will not be started.

You may have noticed that there is a race condition with Return. What happens if two tasks both call Return in parallel? Only one of the values will become the value that is passed to Threads:-Task:-Start. I suppose I could say the "first" value is the one that is used, but really, what does that mean? If you call Return, then the value passed to Return should be an acceptable result for the algorithm.  If you call Return more than once, any of those values should be valid, thus it shouldn't matter which one becomes the return value.  That said, the Return function does give some feedback. In the task that succeeds in having its value accepted, Return will return true. In all other tasks that call Return, it will return false. This allows the code to know if a particular result was or was not accepted.

Maple 14 also adds the Task Programming Model to the C External Calling API. This means that you can write your algorithms in C and make use of the Task Programming Model. The C API is similar to the Maple API, with a few differences. In particular, you need to create each child task individually, instead of as a single call to Continue, as you would in Maple. As well, because it is C code, you need to worry about a few details like memory management that are handled automatically in Maple.  Using External Call is fairly advanced, so I won't go into too much detail here.  If you'd like to see more details of using the Task Programming Model in External Calling, I can write a seperated post dedicated to that.

As with every release of Maple, we spent some time trying to make our existing functionality faster and more stable. For parallel programming, we reduced the overhead of using the Task Programming Model, as well as reducing the locking in the kernel (which should help improve parallelism). Of course many bugs have been fixed, which should make parallel programming more reliable in Maple 14.

Here is yet another finesse (new to me) in getting better performance for some floating-point computation involving the Statistics package.

> restart:

> X:=Statistics:-RandomVariable('Normal'(0,1)):

st:=time():
seq(Statistics:-Quantile(X,1/i,numeric),i=2..10000):
time()-st;[%%][-1];
                                    6.786
                                -3.719016485

> restart:

> X:=Statistics:-Distribution(Normal(0,1)):

  restart; interface(version); Digits:=14;

    Classic Worksheet Interface, Maple 12.02, Windows, Dec 10 2008 Build ID 377066

  f:= x -> (x+1)^(x+1);
  simplify(int(f(x),x)): 
  F:=unapply(%,x);
                                        (x + 1)

Christopher2222's recent post reminded me of a new plot feature that inadvertently (and through my own fault) got left out of the new-features help pages. The 'filled' option now takes a true/false value or a list of suboptions. The suboptions apply to the polygons that make up the filled region under the curve.

plot(x^2, x=0..1, color="NavyBlue", thickness=3, filled=[color="Blue", transparency=0.7]);

In a recent blog post, I pointed out that Maple did not have a built-in functionality for drawing graphs that arise in computing volumes by slices. However, I did provide several examples of ad-hoc visualizations that one could build with the graphing tools in Maple.

Recently, a user called attention to a weakness in the Student Calculus 1 command, VolumeOfRevolution. This command (and the tutor built on it) will draw a surface of revolution bounded by the surfaces generated by revolving the graph of one or two functions.

Here's an assume vs assuming difference worth keeping in mind

> restart:
> is(x^2>=0) assuming x::real;
                                     true
 
> restart:
> f := proc() is(x^2>=0); end proc:
> assume(x::real):
> f();
                                     true
 
> restart:
> f := proc() is(x^2>=0); end proc:
> f() assuming x::real;
                                     false

I am using Maple 14 in Windows xp.

If you enter an equation, or expression into a table the screen display shows more than adequate amount of blank space remaining in that particular table row.  However, when you look at the document in print preview or after printing it out you find that the free space in the row is not correctly displayed.  This is by no means subtle.  For example, I enter an equation into a table and it looks like at...

A long while ago, I wrote a couple posts (part1 and part2) about mining data from the US SSA website.  I subsequently adapted the code from those blog posts into a visual application with sliders and interactive plots.  If you have played with the new ?MapleCloud functionality in Maple 14, you may have seen it posted already.

Amdahl's Law is a formula for determining the theoretical speed up when parallelizing a function. For example, imagine we wanted to parallelize a function that spends 90% of its time in one algorithm. If there is a parallel version of that algorithm, how much faster would the entire function run with 2, 4 or more cores?

In the book Introduction to Maple by Andre Heck books.google.co.uk/books  the author manage to plot the canadian flag
in maple by using the following code:
 

restart:
with(plots):
with(plottools):

X := proc (cc) local S, R, mapleleaf, rectangles, border:

S := proc (t) options operator, arrow; 100/(100+(t-(1/2)*Pi)^8) end proc:
R := proc (t) options operator, arrow; S(t)*(2-sin(7*t)-(1/2)*cos(30*t)) end proc:
mapleleaf := plot([R, proc (t) options operator, arrow; t end proc, -(1/2)*Pi .. (3/2)*Pi], coords = polar, axes = none, color = cc, numpoints = 1000):
mapleleaf := subs(CURVES = POLYGONS, mapleleaf):
rectangles := rectangle([-5, -1], [-3, 4], color = cc), rectangle([3, -1], [5, 4], color = cc); border := plot({-1, 4}, -3 .. 3, color = black):

display([mapleleaf, rectangles, border], view = [-5 .. 5, -1 .. 4]) ;

end proc:

Ap := Array(1 .. 2, 1 .. 2):   

Ap[1, 1] := X(red):         Ap[1, 2] := X(blue):    
Ap[2, 1] := X("green"):    Ap[2, 2] := X("Orchid"):

display(Ap);