My procedure for a dice-sum's distribution is much shorter, much more versatile, and several times faster and more memory efficient:

DiceSumDistr:= (D::list(list(integer)))-> 
   table((degree=icontent)~([op(expand(mul((add@`~`[`^`])~(_x,D))))])) /~ mul(nops~(D))
:

The dice can have any number of sides, the sides can have any integers (positive, negative, zero, or repeated), and any mixture of different dice can be used in a group. Try:

CodeTools:-Usage(DiceSumDistr([[$1..6] $ 1000])): #1000 6-sided dice
Dice:= ['['rand(-6..6)()' $ rand(2..12)()]' $ 100]; #100 randomly sized and spotted dice
CodeTools:-Usage(DiceSumDistr(Dice)):

@Preben Alsholm I'm just guessing again, but I suspect that the GUI/kernel synchronization issue might be more pronounced in document mode or with 2d Input.

@Jodelkoenig Please post a worksheet that exhibits this behavior as an attached file. You can attach files to a post by using the green uparrow on the toolbar of the MaplePrimes editor.

In the meantime, tbis might help (but I'm just guessing):

#First execution group:
restart:

#New execution group:
Threads:-Sleep(2); #Give it a 2-second break to finish the restart.

#New execution group:
interface(imaginaryunit= j);
j^2;

@Matador33 Why do you "have to" use a shooting method and 4th order Runge-Kutta? These are not the best numeric methods in Maple. Shooting methods have been superceded by a dedicated finite-element BVP solver (as used in Tom Leslie's Answer), and 4th-order Runge-Kutta has been superceded by 4th/5th-order Runge-Kutta-Fehlberg. These are the default methods for BVPs and IVPs respectively (that distinction being detected automatically in the vast majority of cases).

Once the BVP solution is obtained, it can be used to obtain the initial conditions needed to recast the the problem as an IVP. Then it can be solved for independent-variable values outside the boundaries of the original BVP.

I am confused by what you say about psi. If psi = C*sqrt(dA(z)), then psi is not a constant, and the system is not linear. Yet you also said psi=100 and that the system is (sometimes) linear.

Maple's numeric ODE solvers can generally handle isolated points of non-differentialability (such as where your dA(z) changes to constant 0), and systems can be input using piecewise to specify what happens at those points.

You'll need to define the variables before I can answer that: Which are scalar, and which are matrices or vectors? And is i just a variable, or is it sqrt(-1)?

@acer I think that your first interpretation of the Question was correct, i.e., reflected the OP's intent. My Reply was in no way intended as a criticism of your original Answer. I was just pointing out an anomalous observation that was tangential to the Question and was meant to cast doubt on the meaningfulness of ProcessClock.

@Ramakrishnan You wrote:

• I understand from your explanation that the PC [ProcessClock] timings are more accurate to nanoseconds.

I think that you misunderstood me. Perhaps they'd be more accurate if they were at all believable. From your timings above, for every case where (Delta ProcessClock) <> 0, we have (Delta time[real]) / (Delta ProcessClock) on the close order of a million (recall that "nano-" means 10^(-9)). For one thing, that degree of consistency is not believable to me^[*1], and for another thing, a million seems way too large. So, I have three problems:

• I can't figure out what ProcessClock is attempting to or supposed to report;
• I can't figure out what it's actually reporting;
• I can't figure out whether it consistently reports anything at all.

^[*1] I mean that if ProcessClock is meaningful, then it's not believable that it would be so consistent with time[real].

@radaar I didn't say that at all. If I thought that there was no way, I wouldn't have mentioned two packages for it. Let's start by looking at your program.

But, yes, there is "no way" to take a program that wasn't explicitly designed or re-designed for multiprocessing and make it run significantly faster by using multiple processors. On the other hand, multiprocessing of garbage collection in Maple is now automatic. If your program uses a significant percentage of its time for garbage collecting (as a great many Maple programs do), then it may be possible to speed things up by increasing the value of kernelopts(gcmaxthreads) and possibly also lowering the value of kernelopts(gcthreadmemorysize). 

A key feature of Maple and other computer algebra systems (CASs) that distinguish them from other mathematical software, including that $2 calculator, is that results are expressed exactly unless an approximation is forced (in this case by evalf or by using a decimal point).

How about providing us with "the" equation that you want to solve?

@acer I am not at all surprised, of course, by the difference between the OP's two timings. On the contrary, I am surprised by a similarity (which may be a coincidence): For the two timings, the ratio (delta time[real]) / (delta ProcessClock) matches to 3 significant digits, those ratios being 1.033e6 and 1.029e6 (and time[real] is only reported to three significant digits anyway). And is nanoseconds the correct unit for ProcessClock? Shouldn't that be microseconds?

I've noticed some other anomalies with ProcessClock that lead me to be skeptical of it.

@Magma The procedure Bases does it:

Bases:= f-> [seq(`if`(g::`^`, op(1,g), g), g= [`if`(f::`*`, op(f), f)])]:

Usage:

Bases(f);

where f is the polynomial, as before.

The complexity of the above code is due to the need to handle the two degenerate cases: factors that don't have an exponent and polynomials that only have a single factor. 
 

@ecterrab But Kitonum does not want to enter any Sum or sum command. I think that you may be confused because he did in fact enter such a command, even though he did not want to. He wants to enter a command akin to

convert((a+b)^n, Sum) assuming n::posint;  #or something similar

and have Maple respond with a summation formula.

Please post your worksheet as an attached file by using green up arrow on the toolbar of the MaplePrimes editor. Please show the execution of the code and be more clear about what you mean by "does not run".

@acer It's a good workaround (for older versions of Maple) that hadn't yet occured to me.