I was thinking of the HPC-Grid toolbox.

I figure that there are very clever people working on Maple who have likely thought already of most of what you or I have independently imagined, and that goes especially for such simple concepts as mentioned here. It's hubris to think otherwise. Absence of publically broadcasted technical plans and innovations in advance of fruition doesn't mean such don't exist, because there are obvious business strategies that pertain.

I suspect that you would find, were you to test it, that the default generator of RandomMatrix (given merely a float range) produces uniformly distributed random numbers.

You could either use Robert's excellent suggestion to Reshape (or Alias) the results of Statistics:-Sample, and wrap the result in a Matrix (...,shape=hermitian) call.

Or, you could use RandomTools:-Generator with its makeproc option as the Matrix intializer procedure. For example

Matrix(3,3,
       RandomTools:-Generate('distribution(Normal(0,1))
                              +I*distribution(Normal(0,1))',
                             makeproc=true),
       shape=hermitian);

I suspect that you would find, were you to test it, that the default generator of RandomMatrix (given merely a float range) produces uniformly distributed random numbers.

You could either use Robert's excellent suggestion to Reshape (or Alias) the results of Statistics:-Sample, and wrap the result in a Matrix (...,shape=hermitian) call.

Or, you could use RandomTools:-Generator with its makeproc option as the Matrix intializer procedure. For example

Matrix(3,3,
       RandomTools:-Generate('distribution(Normal(0,1))
                              +I*distribution(Normal(0,1))',
                             makeproc=true),
       shape=hermitian);

A name is but a name. You could call it a competition, if you want.

For competing `int` methods, some timelimit seems desirable (else how long is each allowed?). And you don't need Threads to implement the wholly separate multi-kernel idea -- you could do it with Sockets alone. (I'm surprised, that nobody in "user space" has implemented their own grid-Maple.)

And the chances are that lots of other people have already considered all these ideas.

Now, given limited research and development resources, which do you choose? The short term high level competition approach (which as noted twice, separately, above) can bring only so much benefit as there are cores by itself. Or do you invest your resources into long term low level Threading capabilities which will hopefully scale well long term?

View 8331_cmsubdoc.mw on MapleNet or Download 8331_cmsubdoc.mw
View file details

View 8331_cmsubdoc.mw on MapleNet or Download 8331_cmsubdoc.mw
View file details

The problem is that an indexed name can be confusingly like its base name, if you use tools like `op` and `map` and such in programs. In Maple, such structural tools are common and fundamental, and so a lot of Maple's own code doesn't handle the presence of both a name, and that same name indexed, in the same expression.

Patrick is right, this comes up a lot. It comes up so much more now, because subscripted names are (by default) implemented as indexed names in 2D Math. And it's not unnatural to want to use a name and its subscripted form at the same time.

Alternative are to use subliterals from the Layout palette or to convert an indexed name to an atomic identifier. Those are ways to make a subscripted name in 2D Math be totally different from an indexed version of the apparent base name. Unfortunatey that can be tiresome.

The problem is that an indexed name can be confusingly like its base name, if you use tools like `op` and `map` and such in programs. In Maple, such structural tools are common and fundamental, and so a lot of Maple's own code doesn't handle the presence of both a name, and that same name indexed, in the same expression.

Patrick is right, this comes up a lot. It comes up so much more now, because subscripted names are (by default) implemented as indexed names in 2D Math. And it's not unnatural to want to use a name and its subscripted form at the same time.

Alternative are to use subliterals from the Layout palette or to convert an indexed name to an atomic identifier. Those are ways to make a subscripted name in 2D Math be totally different from an indexed version of the apparent base name. Unfortunatey that can be tiresome.

There is also kernelopts(assertlevel) which may be useful is tracking down problems.

There is also kernelopts(assertlevel) which may be useful is tracking down problems.

Would you be content with using `load -ascii` in Matlab, or do you want its default behaviour which is to read from binary format?

If you're ok with ascii, then it's pretty easy to write out the data in the right format. You could just use fprintf inside a double do-loop in Maple, for example (with a \n printed for a newline, whenever the inner loop ends).

Would you be content with using `load -ascii` in Matlab, or do you want its default behaviour which is to read from binary format?

If you're ok with ascii, then it's pretty easy to write out the data in the right format. You could just use fprintf inside a double do-loop in Maple, for example (with a \n printed for a newline, whenever the inner loop ends).

Pick a large value of the parameter of interest. Let's say it is value n some numeric value. Evaluate your algorithm at that value, and time it. T1:=time(f(n))

Now do the same at 2*n. T2:=time(f(2*n))

Now look at the log (base 2) of the ratio of T2 to T1.  log[2](T2/T1)

If you are fortunate enough for the asymptotic behaviour of f to have manifested itself by size n, then that last value will tell you something.

Let's put it another way. Suppose your algorithm has O(n^3) behavior. If you double the input parameter then you expect to see an 8 times increase in the computation time (if you are lucky enough, if n is already large enough). And log[2](8)=3.

Pick a large value of the parameter of interest. Let's say it is value n some numeric value. Evaluate your algorithm at that value, and time it. T1:=time(f(n))

Now do the same at 2*n. T2:=time(f(2*n))

Now look at the log (base 2) of the ratio of T2 to T1.  log[2](T2/T1)

If you are fortunate enough for the asymptotic behaviour of f to have manifested itself by size n, then that last value will tell you something.

Let's put it another way. Suppose your algorithm has O(n^3) behavior. If you double the input parameter then you expect to see an 8 times increase in the computation time (if you are lucky enough, if n is already large enough). And log[2](8)=3.

Have you seen the annotated context menu actions? By that I mean what happens when you right-click on an input and then select from the popup menu of action choices. What you end up with is the input-->output with a brief description above the arrow. You can chain several of those in one line. (Whether the annotations appear above the arrows, or not, is a preference that can be set in Maple's Standard graphical interface.)

And those menus can be customized with new types of action (w/descriptions). Hence, I'm pretty sure that Maple can be customized to do something closer to what you've described. The ``() and the expand() could be hidden automatically in this way (ie. "inside the arrow action"). A new action could also be implemented which substitutes into a formula with the values of the variables, while inserting the hidden ``() calls so that it doesn't fully evaluate/expand right away.

So you'd end up with a bunch of lines showing the "assignents" (equations showing values for the variables). And then on a single, new line you could have a chain of arrow actions. First would be the formula without values, then next with the simple substitutions, then next with the combination of units, then next (if you had exact input values) with the floating-point equivalent. And above each arrow could be nice terse words annotating each action. And of course, you'd just have to hide all the (reusable!) setup code.

Does that sound closer?