The LinearSolve command in the LinearAlgebra package can handle this.

Let's write out the coefficients (of x) for your polynomials, as column Vectors. Form a Matrix of the ones from S.

Then call LinearSolve.

Download LS_ex2.mw

note: You wrote, "corresponding linear system", which indicates that you recognize that this problem can be expressed as a linear system. Using LinearSolve might then not be unexpected. Reformulating the polynomial relationships as a linear system, programmatically, might then be useful for you.

Notice that you were using the %d format code for this item, in printf. That's for integers. But you mentioned wanting them as 1.0,1.2,...2.0, which are floats. So you could use the %2.1f format, in printf.

Now, you already have the float values you mentioned wanting, available directly via t[i] .

If you didn't already have them using t[i] then you could also get n values evenly spaced between a and b by using the formula,
   a + (b-a)*(i-1)/(n-1)
which for this example would be,
   1 + (2-1)*(i-1)/(n-1)
which can be shortened to,
   1 + (i-1)/(n-1)

Download frm.mw

For future programming, you might also care to think about how the following work. These kinds of construction occur pretty often in programming. It can be a useful thing to get familiar with.

<seq(1.0..2.0,0.2)>;
n:=6:
<seq(1.0..2.0,numelems=n)>;
<seq(1.0..2.0,(2-1)/(n-1))>;
<seq(1.0+(i-1)/(n-1),i=1..n)>;
Vector(n,i->1.0+(i-1)/(n-1));

You are using module locals like Chevron2A as the keys of some of your tables.

That will prevent you from accessing table entries if you subsequently try and use (say) the global names like Chevron2A as the key, trying that access outside the module.

You could, instead, use global name :-Chevron2A as the table key when creating the entry. Then you can use that as key, for access elsewhere. [edit] I would prefer this, over a module export. Using strings is also a good possibility, as Carl has mentioned after I posted this Answer. If you use the global name as key then you ought to quote it (and protect from evaluation), in case it is also assigned some value, eg. ':-Chevon2A'.

Or you could instead declare Chevron2A as an export of the module. Then, later, you could use it as key in its long-form (fully qualified name),  calculateblahcubitblah:-Chevron2A. Or you could make the module a package, so after doing with(calculateblahcubitblah) its exports become the new bindings for reference via the short-form Chevron2A. [edit] This is not my favorite choice, and I can only think of convoluted scenarios in which it'd provide extra contextual usefulness.

The code snippets that you showed above indicate that this problem that I've described occurs in your code. I cannot tell whether you also have other issues, eg. last-name-eval of tables assigned to names. I suggest using eval(nameoftable) when putting into lists or if returning them straight from procedures.

Some of your procedures will throw an error for certains ranges of inputs alpha and delta.

The plots:-inequal command appears to get slightly confused by that situation, and in consequence can misrepresent the feasible region..

Below and use short wrappers for those three procedures, so that when failing to produce a result (throwing an error) they instead return either a large positive or large negative value. Those can be used appropriately for the inequality tests, so that a more clear/robust representation of the feasible region is attained.

Double check, for correctness.

Download ConflcitInequal_acc.mw

These results for n=2..15 are computed exactly.

Download hg_ex.mw

@RaySierra 

Your worksheet's code is missing `+` as the first argument passed to Continue.

If I simply add that missing argument then your worksheet runs ok in my Maple 2019.2.

Download failed_plot_ac.mw

I don't understand what that Matlab colormap is doing, so I'm not sure how to reproduce that exact coloring.

But you could look at this old Post, and adjust the formula for generating the hue component.

Less fast and a bit more clunky are results from complexplot3d, or densityplot (of argument). Eg,

plots:-complexplot3d(ln((exp(1/z))), z=-0.5-0.5*I..0.5+0.5*I,
                     style=surface, orientation=[-90,0,0], grid=[501,501],
                     lightmodel=none, size=[600,600]);
plots:-densityplot(argument(exp(1/(x+I*y))), x=-0.5..0.5, y=-0.5..0.5,
                   axes=boxed, colorbar=false, grid=[301,301],
                   #colorstyle=HUE
                   colorscheme=["zgradient",["Yellow","Blue"],colorspace="HSV"]
                 );

You might compute the derivatives by using the D operator.

When plotted, evalf of such D calls may go through fdiff to perform numeric differentiation. Such approximation of a derivative -- by a finite difference scheme -- of a pde solution numerically approximated via finite difference methods, may need care. I would not expect high accuracy, even if you do try and adjust the step-size(s).

Double-check everything, and adjust as required.

Download badPDE_ac.mw

Try,

   X := Sample(roll,[n,n]):

For Maple 2023 you could use the new colorbar option for 2D contour plots, as well as colorscheme to get that spread of hue values.

For Maple 2022 you could use one of the following approaches:

1) Use DocumentTools:-Tabluate, like in this old response of mine. Adjust weights and dimensions and borders, to taste. You could use the colorscheme option with densityplot, to get the exact colorbar you want, eg. blue to red in hue, etc.

2) Use this old Post of mine, for getting a colored legend along with contourplot (and densityplot too if you want that kind of graded filled effect), or use a specialized form of the legend option with the contourplot command.

3) Do something like the following, using polygons for that filled legend effect. Naturally, you could also merge/display the following with added contour lines.

Download M2022_colorbar_fun.mw

I don't know the full details of your example (all ranges, etc), but here's another:

restart;
with(plots): with(plottools,polygon): with(ColorTools,Color):
f := cos(t)*sin(x)-sin(x)+(1/2)*sin(x)*t^2-(1/24)*sin(x)*t^4:
(a,b,c,d) := -Pi,0,-4,1:
Q := plot3d(f, x=a..b, t=c..d):
(zmin,zmax) := (min,max)(op([1,3],Q)):
display(densityplot(f, x=a..b, t=c..d, 'style'=':-surface',
                        'colorscheme'=["zgradient",["Blue","Red"],
                                       'colorspace'="HSV"]),
  seq(polygon([[0,0],[0,0]],'thickness'=0.3, 'legend'=sprintf("%5.3f",z),
              'color'=Color("HSV",[:-Hue(Color("Blue"))*(zmax-z)/(zmax-zmin),1,1])),
      z=zmax..zmin, 'numelems'=24),
  'legendstyle'=['location'=':-right'], 'size'=[580,500], labels=["",""],
  'axis[2]'=['location'=':-high','tickmarks'=[],'color'="White"],
  'axis[1]'=['location'=':-low','tickmarks'=[],'color'="White"]);

I found it by looking at the list of extra options on the ?dsolve,numeric,DAE Help page's Description section.

Near a mention of the differential option, that page had a cross-reference link to the ?dsolve,numeric,DAE_extension Help page, which contains the details of these extension methods for the numeric DAE solvers.

The default extent of the axis view comes from the data points themselves (or a fitted curve).

You can override it by using the usual view option for plotting commands.

For example,

restart; with(Statistics):
N:=200: U:=Sample(Normal(0,1),N):
X,Y:=<seq(1..N)>,<seq(sin(2*Pi*i/N)+U[i]/5,i=1..N)>:
ScatterPlot(X,Y,view=[-20..220,-2..2]);
ScatterPlot(X,Y,view=[-20..220,default]);
ScatterPlot(X,Y,view=[default,-2..2]);

The first sentence in the Options section of the ScatterPlot Help page (Maple 2018) states, with a cross-reference link to the Help page for plot options, "The options argument can contain one or more of the options shown below. All unrecognized options will be passed to the plots[display] command. See plot[options] for details."

What that means is that most of the 2D plotting command common options can be simply passed straight into calls to the ScatterPlot command.

Download OverflowError_ac.mw

An alternative to dharr's nice idea, for this example, is to selectively utilize limit.

Naturally, it's not as fast as dharr's switch. But I didn't have to consider the form.

Download Discontinuous_contours_ac.mw

ps. for implicitplot this use of gridrefine=3 above seems to produce a slightly nicer result that the original gridrefine=4 does there.

Your other set of contour values is also improved: