Maple 14 Questions and Posts

These are Posts and Questions associated with the product, Maple 14

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.

As I have recently learned, the environment variable 'Digits' controls the working precision and is therefore crucial for avoiding significant impacts of round-off error effects on floating point computations.

Moreover I discovered, that even when I set Digits to say 20, Explore is not affected.

Is there a way to control the working precision of the floating-point computations carried out by the Explore option?

Maple carries out the following solving task without any problems:

X1 := RandomVariable(Geometric(q)):


Anyway, when I add common assumptions (0<q, q<1), then Maple will not carry out the task:

X1 := RandomVariable(Geometric(q)) assuming 0<q, q<1:


Why is that the case?


I am new to Maple and I am interested to know what programming language Maple is written in - I mean the maths part of Maple of course and not the interface which appears to be in Java.

Thanks in advance,



I am tying to compute the wronskian of a set of functions. I loaded the LinearAlgebra package and still Maple won't recognize the following command:

wronskian(x, x^2, x^3)

Can anyone please help?

Thanks in advance,



I am new to Maple and would like to know how to recall the last expression in maple. Say I write "x^2 +2", then press enter and I then want to recall "x^2 +2" without retyping it. How do I do that? (I think I am in math mode using "xmaple".)

Thanks in advance,


Consider the following expression:

sCARA4 := -ln(-(mu/sigma^2)^(mu^2/(mu-sigma^2))*(sigma^2/mu)^(mu^2/(mu-sigma^2))+(sigma^2/mu)^(mu^2/(mu-sigma^2))*((exp(phi)*sigma^2+mu-sigma^2)*exp(-phi)/sigma^2)^(mu^2/(mu-sigma^2))+1)/phi;

Now try to find out whether the first derivative to mu is positive for all positive mu, phi and sigma, except for some rare exceptions (e.g. sigma^2=mu).


Since 'is' is not a satisfying option, I used 'Explore'...

How do I evaluate moments of Q4 in a reasonable time with a reasonable accuracy, i.e. to a few decimal points:
with(Statistics): RV := 'RandomVariable(Geometric(1/3))+1'; R := `$`('RV', 5);

Q4 := 1/(alpha*R[1]+alpha^2*R[2]+alpha^3*R[3]+(1-alpha-alpha^2-alpha^3)*R[4]);

Moment(Q4, 1);

E.g., can I tell maple that replacing infinite series underlying this calculation with sufficiently long partial sums is okay with me? Or maybe there...

To my mind I did all the necessary assumptions, to avoid that the summand will become singular when calculating the expected value.

What did I do wrong?

Here´s the code:

assume(0 < q, q < 1):
X1 := RandomVariable(Geometric(q)):
DARA := t->log(t):

I'm using Maple 14 on 4-way and 6-way AMD 64 hardware running Windows Vista to numerically estimate inverses of a cumulative distribution function at hundreds of points, and am using the Task model to assign each point's inverse computation to a separate task. The cdf is a weighted sum of thousands of simpler functions, and so each task needs the weights. Initially I had set these up as a global variable, but after reading Darin Ohashi's MaplePrime's post ...

In the following code Maple simplifies the last expression different, based on whether assume(mu::real, sigma>0) is set or not.

The point is, that the assumptions got -to my mind- nothing to do with the displayed results.

Why does Maple do such weird things?

Here is the code. The last output is different based on whether the '#' before assume(mu::real,sigma>0): is set or not:

Y9 := RandomVariable(LogNormal(b, c)):

I discovered, that Maple did substitute every single parameter but c!

Anyway, when I isolate the problem and do not assume anything for mu and sigma, the problem does not occur.

Therefore I print here the complete relevant code.

Is there a way to "convince" Maple to do those trivial substitutions of c also, without seperating each problematical expression?


Here is the code:


#Definitions and assumptions

I tried to find out whether the expression



is positive under the given assumptions:

is(signum(g1)=1) assuming mu>0, sigma2>0, phi>0, sigma2<>mu;


Hello Maple wizards,

After reading the mapleprimes post on the hidden complexities of using thread-safe versions of add (Threads:-Add), I have been struggling to correct a problem similar to the "escaped k" problem described by Joel Riel...

First 31 32 33 34 Page 33 of 34