@JSalisbury Since solve doesn't produce a useful result when solving s for t, you can instead solve s for thetabn and reflect the plot.

Or you can produce an implicit plot. (This is less efficient, and can sometimes require additional options to get a smooth result. It's usually preferable to produce an explicit plot if you can.)

Download implicit_plot_3.mw

@mehdibaghaee I don't think thay you should be very concerned about floating-point discrepencies between approaches if you can establish that it is small, say on the order of 10^(-Digits+1) or so, and decreases in magnitude as the working precision is increased. And that seems to be the case here. You can still use fnormal as a convenient way to gauge whether the differences are acceptable.

It is interesting that in at least Maple 2016.2 (your version) the kernel is able to pass along Rr -- as well as its indexing function -- to the distributed kernels automatically. It's also interesting that using Grid:-Set on `index/xxx` and RrProc decreases the benefit. Once those Grid:-Set calls are made both the version where Rr is passed as an extra argument, and not, see the decrease is benefit. The speedup obtained through use of Grid:-Seq is almost a factor of four over the use of serial seq. or about a factor of two if the Grid:-Set use is retained here. The kernel magic which figures out what assigned values in the parent kernel session need to be passed along to the child kernel sessions is subtle I believe. I've seen it change from release to release, mostly for the better. In the worksheet below I've commented out the version using Grid:-Set.

But I'd like to focus on what I've previously written about optimizing the serial code first, before parallizing.

In the following attachment I looked at your RrProc procedure. It returns 0 (zero) if its first parameter i is larger than its second parameter m. So quite a few calls to RrProc can be avoided simply by making the add loops for i and k go from m+1..II instead of 0..II . That is done in variant UP1a in the attachment, and improves the timing by about a factor of three.

Now procedure RrProc is not efficient. It creates and populates a Vector, flips it, etc, only to return only one of its entries. It could be made more efficient. But the values that the procedure returns are just 0 (zero) if i-m is even, and just 2*m+1 otherwise. So that whole procedure can be eliminated, and a simple formula used instead. Doing so brings about another factor of three speedup.

So, in summary, that's about a factor of 4 by using Grid:-Seq, and about another factor of 9 by eliminating the overhead of calling RrProc inside the loop.

nb. It's difficult to know whether this is a partially concocted computation for illustration, or part of your actual, broader goal. For example, you call procedure UP with two different values of s. But the first result for s=1 is simply 4/3 the result for s=2. So, as it stands, there no real need for calling the UP procedure for both values of s.

Download soal-1_ac.mw

As exciting as a 2-fold speedup for a sequence of 2 operations goes, this might be a good time to mention that it's often much more important to optimize the serial code first.

For example, if the computation amounts to just adding up pairwise produces of multiples of tau[i](t)*tau[j](t) then perhaps the coefficients could be abstracted away from the symbolic factors, and a purely floating-point scheme devised (which has the potential to be much faster).

What are you trying to accomplish (in words, please).  What do you mean to express by A1 = b where A1 is a 3x3 Matrix and b is a Vector?

@Cavemaann Your latest attachment had the expression f which simplified to -sinh(alpha*L)*sin(alpha*L) = 0 . Are you saying you disagree with roots of that occuring at alpha*L=n*Pi?

Or are you saying that you want some other kind of plot for f=0? And if so, then what kind of plot?

Your example works for me.

display3d_ac.mw

What is inside your custom initialization of Maple? What happens if you launch without it?

@Cavemaann Aren't the roots just multiples of Pi?

K4square_equal_K2square_ac.mw

@tomleslie This is perhaps interesting to someone generally concerned with low- vs high-level parallelization in Maple.

But I fear that it risks muddying the waters for the OP, since the addition of many numeric values, or other arithmetic calls, is not the primary concern. (AFAICT the member vv cooked up the addition of many sin calls just because it is a black box which he could easily make as expensive as wanted.) 

I suspect that there could also be non-negligible differences in comparison of such a variety of approaches according to whether the calculation is exact rational, software floating-point, or hardware floating-point.

The OP (as per usual, and unhelpfully) has not disclosed details of the actual computations performed by his function calls f(x1,x2,x3,...) and g(x1,x2,x3,...). So we cannot tell if they would be susceptible to improvement via low-level multi-threading. We also cannot tell if they are even thread-safe, or call anything which is thread-blocking (like an external, compiled, numeric integration function). In the worse cases, a lack of thread-safety could result in invalid results or even a crash.

I think that your reponse can remind us of an aspect that is sometimes overlooked: In Maple it is often the case that the performance of a serial calculation can be significantly improved, and often it is beneficial to focus on optimizing the serial calculation foremost, before trying to parallelize.

(Hence my suggestion above, to use the Grid package.)

@vv You may compare with Grid:-Seq.

You could also wrap the f(i) calls in evalhf and remove the evalf. Remember table of evalf might play some part.

Also possible is Threads:-Task model

nb. I suspect you deliberately use :-add instead of Threads:-Add because you want an expensive serial `f`. Makes sense.

General control of other worksheets (from within a given worksheet) is not possible.

There are limited tools for querying particular formulas from another Worksheet/Document (if the formula is attached to a GUI Equation Label). And there are limited tools for getting a "return value" from another Worksheet.

But you cannot generally set the state of another worksheet.

I am going to stress that it is unhelpful for you to not describe carefully what your goal is here.

If you simply want to be able to share/get procedures/operators/expressions amongst sessions then Library archives might suffice. Its difficult to know whether you are asking for significantly more than that, because you've given so few details.

@mehdibaghaee Your supposition that computations can generally be "shared" is false. Most cannot. That is true both in Maple and elsewhere.

Suppose that you buy a garage containing 10 cars, each of which can go 100mph.  That won't provide you with a way to go anywhere you want at more than 100mph (and, of course, not at 1000mph either).

What is the justification behind your expectation that a general computation (which may only be computable with some steps done in serial) be able to use 100% of the resources of a multi-core CPU?

@Christopher2222 

Using MS-Word like that also seems to introduce carriage-return into the end-of-line characters on each line. That's a common MS-Windows effect which seems like an unnecessary if mostly harmless alteration.

But I agree, it's nice know that Maple alone can sometimes recover all the Input. Unfortunately we are still seeing the occasional report from a Danish student where either use of Danish language or use of large drawing canvas corrupts the worksheet in such a way that only manual editing can attain the maximal recovery of material.

In fact it's only the last Output that presents the GUI a problem in this case, hence my first upload.

Why didn't you make the free upgrade from Maple 18.00 to 18.02?

@Christopher2222 That was not my point.

Any call like :-diff(...) is always possible as a way to use the global diff command.

My point was that the user may not be expecting the full set of command-name rebindings due to loading the whole Physics package. For most users in most situations, it would be more prudent to either:

• load only the one command via with(Physics, diff) 
• use the export with its full explicit name Physics:-diff(...)