I ran the code below on an Intel i7-7700 3.60GHz which has 4 physical cores with hyperthreading (8 threads or logical cores). Since Maple doesn't recognize this as having "new" improved hyperthreading it sets kernelopts(numcpus) to 4 by default. So in some of the examples below I set kernelopts(numcpus) to 7 and kernelopts(gcmaxthreads) to 7 or 8 (which seems optimal on this host for some examples).

I also ran it on an Intel i5-7400 3.00GHz which has 4 physical cores without hyperthreading (4 threads or logical cores). The relative timing behavior amongst the example was generally the same, except timings were not as good. I left kernelopts(numcpus) and kernelopts(gcmaxthreads) alone, at their default value of 4, since raising those resulted in worse performance.

I did all that using 64bit Maple 2019.0 on Linux.

I observed that almost half of the total computation time is spent in memory management (garbage collection). I found that by reducing the setting of kernelopts(gcthreadmemorysize) from its default I could improve the total timing. This benefit seemed to happen across other setting variants.

I made sure that the machines were not otherwise significantly loaded, since the timing measurements are in real (wall clock) time. I made sure that for size nelems=10^7 the machines had at least 2.5GB of free RAM and so would not swap out the computation.

One interesting result is that simple use of Threads:-Seq attained almost as good performance as the more complicated Threads:-Task set up, under the tweaked kernelopts settings.

For the Threads:-Task set up I tried to ensure that few temporary Arrays were created (ie. without concatenation). The exception to that was that I did not find improvement for replacing seq calls with inplace map calls or straight Array construction with initializer.

Download threadthingm.mw

On these Linux machines the best performing variant above was about 3.1 times as fast as the first (unoptimzed) variant. The timings do change slightly upon re-execution, however. It was also faster than other versions posted so far for this Question. It would be interesting to see results for a 4-core (modern) hyperthreaded host on 64bit MS-Windows.

Using Maple versions 17.02 (2013) through to 2019.0,

solve([x^2+y^2+z^2-4*x+6*y-2*z-11 = 0, 2*x+2*y-z = -18],
      [x, y, z], parametric, real);

           [[x = -4/3, y = -19/3, z = 8/3]]

• Widget driven interface (displayed inline in worksheet in Maple GUI or Maple Cloud or Maple Player, created via source or mouse layout):
     Embedded Components, a newer alternative to Maplets
  See Help topics:
     - EmbeddedComponents
     - examples,ProgrammaticContentGeneration
     - DocumentTools,Layout
• "Clickable Math" access to commands applied to 2D output or input (right-click popup menu in Maple 2017 and earlier, and side-panel menu in Maple 2018 and later):
     customized Context-Menu entries
  See Help topics:
     - ContextMenu
     - examples,ContextMenu
  See more ideas:
     - package-specific context-menu additions
     - context-menu additions for "phasor" package (see ModuleLoad)
     - context driven help

Here are a few more workarounds.

restart;
solve({x^2 = 2, x^3 = sqrt(2)^3}, [x,W]):
subs((W=W)=NULL, %);

                         [[     (1/2)]]
                         [[x = 2     ]]

Of course, these next two are restricted to a particular kind of problem or domain.

restart;
SolveTools:-PolynomialSystem({x^2 = 2, x^3 = sqrt(2)^3});

                          /     (1/2)\ 
                         { x = 2      }
                          \          / 

restart;
solve({x^2 = 2, x^3 = sqrt(2)^3}, [x], real);

                         [[     (1/2)]]
                         [[x = 2     ]]

When solve behaves weirdly I usually look at eliminate as well.

Call the randomize command first with the same seed value.

Download collect_example.mw

[edit] That F procedure is only there to get the polynomial terms in r in the form you showed. You may wish to omit it. Ie,

Is this what you want?

OManim.mw

The behavior in this attachment may be what the author of Statistics:-DataSummary had intended.

QuestionDataWeights_acc.mw

A more robust way to discern the position of the weights optional parameter could be devised. I only checked against Maple 2019.0, Maple 2018.0 and Maple 2018.2, but chances are reasonable that weights corresponds to either PARAM(4) or PARAM(5) of the InertForm in earlier versions that have DataSummary.

I use the ToInert/subsop/FromInert to repair what seems like a typo in the source of DataSummary. On the source line of that assigns to w,ww the first argument passed to PreProcessData is edited from X to weights. See showstat(Statistics:-DataSummary) for clarification.

I'll submit a bug report.

The use of nested loops to assign distinct deep copies of a Record to the Array entries seems somewhat unnatural and stilted to me.

The Array command accepts an initializer procedure as an optional argument, which can be used to populate each entry. The distinct Records (and Vectors in their fields) can be created on the fly.

This gets rid of the need for nested loops (as many as there are dimensions) to assign all the entries their Records. It gets rid of the need for copy or deep copying of a Record. The values of the indices (i,j,k) could be passed to the constructing procedure, in the case that some Record field were desired to be set up depending on their values.

The Records could also share some Vector(s), if desired. The copy approach gets in the way of that.

Download Why_initializer.mw

Are you looking for something like this?

GAMMA(3/2);

                      1/2
                    Pi
                    -----
                      2

convert((x)!, GAMMA);

                 GAMMA(x + 1)                                                  
                                                                                                              
convert((1/2)!, GAMMA);

                      1/2
                    Pi
                    -----
                      2

Download solve_example.mw

You can get closer to the exact form you requested.

Be careful about the multiplication signs in the definition of Gc. Notice them in the terms k*(-b*s+1) and s*(t*c+b) .

Download form.mw

The problem seems to be that the backend MapleNet server of this site cannot handle the new default rtablesize="[10, 10]" attribute in the MapleNet-Properties section of the XML format .mw file.

If I execute the interface command using the older form (a single value) then the worksheet gets saved in Maple 2019.0 with that form in the .mw XML file's MapleNet-Properties. A subsequent upload to this site then succeeds.

Download fibon2019_rtablesize.mw

I can even delete that input line (as long as I've executed it). And it still uploads OK here.

Download fibon2019_rtablesize_deleted.mw

I can even put interface(rtablesize=10) inside my personal ~/.mapleinit file on Linux, launch the Maple 2019.0 GUI without the -s option, and save and upload OK here.

Download fibon2019_rtablesize_mapleinit.mw

So for now I suppose that a last step before saving/uploading could be to execute the interface command with the older syntax of a single value for rtablesize. And delete that line if you choose.

It's a bit of an effort, but not nearly as much of an extra effort as having to execute all 2D plots under gridlines=false just so that the back-end server doesn't render with grid-lines by default (another, much older bug here).

I would really like to see the back-end server of this site updated, so that it would handle default 2D plot grid-lines properly, not have this rtablesize issue, and also allow inlining of Task regions as embedded by Explore, PlotBuilder, ImageTools:-Embed, DocumentTools:-Tabulate, etc.

How would applying Grid:-Seq to the call to f (for each M[i,j] ) improve via parallelization? I dont see how the syntax you gave makes any sense.

How about using Grid:-Map to apply f to the Matrix M? There's no guarantee it will always improve performance but that seems like the natural syntax for the job as you've described it.

Or (slightly less direct to code) how about using Grid-Seq to generate the n*m results of f(M[i,j]) but with a range argument supplied to Grid:-Seq itself.

Why don't you show us your f and your Matrix M, in a complete working example as an uploaded worksheet?

Just for fun. If you really want to generate the frames with their own calls to plot with colorscheme then the key is to have the end-points of the curve's parametrization depend on the animating variable and to use the "linear" color scheme.

restart;
N:=75:

S := [seq(plot([t + N/10*(1 + cos(a)), N/10*(1 + sin(a)),
                a = 0 - Pi/2 - t/(N-1)*2*Pi .. 2*Pi - Pi/2 - t/(N-1)*2*Pi],
               thickness=3,
               colorscheme = ["linear", ["Blue", "Yellow"]]),
          t=0..N)]:

plots:-display(S, gridlines=false, size=[700, 200],
               scaling=constrained, insequence=true);