@Carl Love Upon deeper analysis, it looks like your character is equivalent to the ASCII ≔, which leads me to believe that you got it from a palette. I'd recommend that those palette symbols be reserved for display purposes and that only keyboard characters be used for coding purposes. While this recommendation is not strictly required, it does help keep one out of trouble.

I think that most of the readers here are having trouble understanding your Question. Would you please elaborate, rephrase, and include an attached worksheet? Do you mean that you want to use the TAB key to change the selection of multiple-choice answers?

@sand15 This Reply is not directly related to your question from two Replies above, but I wonder what you hope to achieve by setting UseHardwareFloats:= true. Do you believe that if you don't do this then it's equivalent to setting it to false? That's not the case: There's a middle value between true and false named deduced, which is the default value and the one most useful for most purposes.

@Carl Love After seeing a Reply by Acer above, I realize that of course doing 2 substitutions is better than doing n indexing operations, so I change the above to

n:= 10: 
cat(seq(subs([0= "T", 1= "H"], rtable(1..n, random(0..1)))));

Note that even 0 is a pointer in Maple (as can be seen by addressof(0)), so the substitution of 0 only occurs once rather than at every array position that contains 0 (likewise for 1, of course).

Something that Daniel just said makes me think that maybe there's a possibility that you want to share RAM memory across some open worksheets, so that when a variable is changed in one, it's also changed in the other (because they're literally the same variable, with the same memory address). This is easy to do in Maple if you accept these conditions:

• It's all or nothing: To do this, you must share all memory: Anything that can be seen in one worksheet can be seen in the other, including the countless global variables that are deeply hidden in the Maple library code that you probably don't know about.
• It's totally up to you to avoid the crazy conflicts that can occur if the two worksheets write to the same memory.

If this is what you want, let me know. It's trivial to set this up, and it works decently if you're not actively executing code in both worksheets at the same time. This kind of link between worksheets is broken when they're closed; it's not like a workbook.

@sand15 You wrote:

• It's rather difficult to compare the results produced by Q3 with the true ones. 

I knew that the limitations of hardware-float arithmetic would kick in at some point, so I was already suspicious. To check the results, I simply summed them. The command add can be applied to any list or rtable without needing an index, as in add(L). For NumberOfDice > 22, the sums are different from 1, although they're close. For NumberOfDice > 394, the sums are undefined, which indicates that you not only overflowed the mantissas (the exact part of an hfloat), but you also overflowed the exponents.

• I suppose your observation definitely discredits Q3?

It's hard to argue for undefined as a credible answer.  :-)

A procedure to do convolutions in Maple's default exact rational arithmetic could be written in 3-5 lines. It wouldn't be as fast as hfloat, but you'd probably be surprised how fast it is.

Another alternative is to use LinearAlgebra:-Modular, doing the convolutions for a set of prime moduli (all less than 2^25) whose product exceeds the product of the number of sides of the dice, and reconstructing the exact result with LinearAlgebra:-Modular:-ChineseRemainder. You could use ArrayTools:-FlipDimension to express each entry of the convolution as a dot product of two vectors. It sounds complicated, but it may possibly be worth it because Modular is amazingly, blindingly fast when used in hfloat mode with moduli < 2^25. I think it could be done in 20-30 lines.

@mmcdara It's a good try, and I do believe that there's a good solution to this problem using convolutions. However, your procedure Q3 has several shortcomings, and one very serious error that will be difficult to fix: SignalProcessing:-Convolution uses hardware-float arithmetic, where the largest integer that can be represented exactly is (IIRC) 2^53 - 1 (I'm sure that it's some number close to that). Because of this, Q3 returns incorrect results for NumberOfDice > 22 and total nonsense for NumberOfDice > 394 (using the "default" initial die [1,2,3,4,5,6], with similar cutoffs for other initial dice).

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