Even if you use 2D Input mode the methodology of assigning a procedure with the syntax f(x) := ... is a bad idea, not least because it is ambiguous syntax that can easily lead to problems.

There are a variety of ways to accomplish the substitution for s2 within the procedure body.

First, in 2D Input,

Download subs_proc_2D.mw

And now in 1D Maple Notation,

Download subs_proc.mw

In the case that you have already assigned to s2 then you can use the unapply command directly. Eg,

s2 := 9:

f := unapply(x^2*s2+x+1+s2, x);

                   2
      f := x -> 9 x  + x + 10

f(2);

                48

As for how the body of the procedure gets pretty-printed (formatted as 2D Math), or not, you have a few alternatives.

restart;

s2 := 9:

f := unapply(x^2*s2+x+1+s2, x);

                   2
      f := x -> 9 x  + x + 10

lprint(eval(f));    # line-printing

  x -> 9*x^2+x+10

sprintf("%a", eval(f));    # as a string

           "x -> 9*x^2+x+10"

sprintf("%-P", eval(f));  # Maple 2019.0

         "x -> 9*x^2 + x + 10"

showstat(f);

  f := proc(x)
     1   9*x^2+x+10
  end proc

You could also set interface(prettyprint=1) (or 0) but keep in mind that would affect display of other expressions as well.

Why not scale down the 1014x1024 pixel image before using it? That should reduce the memory allocation by the kernel. (I chose 50x50, but you could experiment.)

Download smile_acc.mw

Also, here is a way to animate it as a 2D plot. (I used parts of a method from this old post, where the data of an image can be used as the color data of a densityplot structure.) I made it with 22 frames and displayed it with size=[500,500], but you could change those.

Download smile_acer.mw

Do you mean custom tickmarks along the axis?  If so then try searching the Maple Help for tickmarks.

You might try making sure that you have the latest point-release update for Maple 2016. That is a free download if you already have a valid installation of Maple 2016. (You can also check for updates within Maple's main menubar.)

The update to Maple 2016.2 is available here. It includes changes in the point-release(s) before it, eg. Maple 2016.1.

(One reason I mention this is that the update Maple 2016.1 release notes specifically mentions some "Enhancements to Maple's context-sensitive menus" to right-click context-menus. So perhaps that might address some of your performance issues.)

If the problems persist, then more details might help diagnose the problem. What packages, if any, do you have loaded when the context-menu is slow to generate and display? Is it only slow the first time in a session, including following any restart? Is it slow for a particular kind of expression? And, as Carl queried, do you have the language set to something other then English?

Maple has its own 3rd-party installer and uninstaller. While Maple itself (once installed) is 64-bit, its installer has some 32-bit runtime components.

So to install Maple 2018 or 2019 for Debian it is necessary to have some 32-bit compatibility packages installed. See this Maplesoft Tech Support page for a list (which includes a Debian note).

Yes, in principle it's possible to run Maple on Debian.

You can map the expand command over a matrix or Matrix.

The simplify command will map automatically over those, in modern Maple.

Download map_expand_matrix.mw

Yes. Your last paragraph describes what's happening.

It's not specific to the simplify command.

Why are you so surprised by this?

What would be your comprehensive delineation between circumstances where NULL inside an expression sequence should get flattened out and circumstances where it should not?

It doesn't seem like a very good idea to have an application that relies on the initial state of currentdir().

But cannot your application's startup code set currentdir to something relative to, say, kernelopts(':-homedir') ?

What sort of i/o do you intend on trying within the MaplePlayer? (There's a possibility that the MaplePlayer would have to look into a temp directory in the FileTools sense.)

Right, an Execution Group or Document Block can only have a sole Task region, which can have worksheet content embedded into it. So each call to Tabulate (or Explore, or InsertContent, or ImageTools:-Embed, etc) executed within the same Execution Group simply replaces the content in that sole Task Region.

Here are two approaches to getting what you've described.

The first way involves keeping a running Matrix that accumulates the various results. It simply replaces the embedded tabulation each time that additional results are added to the bottom of that Matrix. This is easy if the tabulations all have the same number of columns.  Tab1.mw

The second way involves keeping a running copy of the XML representations of separate Tabulate calls, stored separately as, say, entries of a Vector. At each iteration it embeds all the tabulations accumulated so far (in order) as separate Tables. This is more suitable if the various tabulations are quite different from each other, eg. different number of columns. Tab2.mw 

The Tabulate command is really just a convenient way to build -- and, normally -- embed the XML representing a GUI Table. The undocumented option output=XML allows the Tabulate command to return the XML for the constructed Table without actually embedding it. So the second approach simply stores them, allowing you to replace the sole Task region for an Execution Group or Document Block with whatever combination of such previously constructed Tables as you see fit.

Hopefully you can adjust one of the two approaches to your purpose. I used Maple 2018.0.

You already had them combined by using plots[display], but their curves are so close that they overlap and you can only see the one on top.

One alternative is to plot one of them as a line and the other as a point-plot.

I increased h for Runge while plotting List as a point-plot, since otherwise the point symbols overlap and don't look so good. But you could also use the smaller h and just plot every 2nd (or 10th, or whatever) entry of List generated using the smaller h.

I also added a legend entry to each.

Another alternative is to plot them side by side.

question_ac.mws

It'd be helpful if you told us what exactly you wanted the final combined plot to look like.

I often find that it's more convenient to use so-called 2-argument eval than to use assign on the fsolve result, because the former allows you to immediately do further symbolic computations with the original variables.

But if you do the assign then you'd have to call unassign if you wanted to do further symbolic work with the original variable names.

The appeal of using assign is that formulas involving the names will get the numeric values directly.

Which approach you choose is up to you. Neither is incorrect. Which one is more convenient for you depends on what kind of further work you intend on doing.

restart;
eqs := [c + d = 520.9447091, c - b = 0.04148708484,
        d*a + c + b = 0.04147082666, b - c - d*a = -0.04148773634]:

res := fsolve(eqs);

                                                    -5                                      -8
     res := {c = 0.04147863000, b = -0.8454840000 10  , d = 520.9032305, a = 0.1250712151 10  }

assign(res);

sin(d) + c/b;

                     -4906.469192

cos(d) + b/a;

                     -6759.195990

unassign('a','b','c','d');

# Now you can do further work with the names as symbols.
fsolve( sin(d) = d - 0.5 );

                      1.497300389

# But now the formula doesn't immediately produce a numeric result.
cos(d) + b/a;

                     cos(d) + b/a

eval( cos(d) + b/a, res);

                     -6759.195990

And here is an alternate approach.

restart;

eqs := [c + d = 520.9447091, c - b = 0.04148708484,
        d*a + c + b = 0.04147082666, b - c - d*a = -0.04148773634]:

res := fsolve(eqs);

                                -8                                                          -5
     res := {a = 0.1250712151 10  , c = 0.04147863000, d = 520.9032305, b = -0.8454840000 10  }

eval( sin(d) + c/b, res );

                     -4906.469192

eval( cos(d) + b/a, res );

                     -6759.195990

fsolve( sin(d) = d - 0.5 );

                      1.497300389

cos(d) + b/a;

                      cos(d) + b/a

eval( cos(d) + b/a, res);

                      -6759.195990

You can approach this using operators and D, or expressions and diff. But note that neither will produce ten correct significant digits in the answer if you just use the default working precision of Digits=10.

Increasing the working precision can produce the desired result. But it's not any kind of proof.

restart;

f := 2*sin(x^2/2)-sin(1*x/2)^2:
df := diff(f,x):
dff := diff(f,x,x):

Digits := 20;
                          Digits := 20

r := fsolve(df, x=1..2);
                   r := 1.6870521236466276364

a := eval(dff, x=r);
                  a := -5.2779215898752826466

ans := evalf[10](a);
                      ans := -5.277921590

That may be adequate for you. Using Maple to try and prove correctness of an answer to this question is an interesting task, though it might be out of scope for you.

Two interesting aspects are: how accurate does r have to be such that substitution into the second derivative can robustly produce a result correct to ten significant digits, and what working precision might be needed for that substitution.

Even considering alone the second of those aspects is not basic.

restart;
f := 2*sin(x^2/2)-sin(1*x/2)^2:
df := diff(f,x):
dff := diff(f,x,x):
Digits := 40;
                          Digits := 40

r := fsolve(df, x=1..2);
         r := 1.687052123646627636437294496471862263832

for d from 10 to 20 do
  forget(evalf);
  Digits := d;
  s := shake(subs(x=r, dff));
  a := evalf[2*d]((op([1,2],s) + op([1,1],s))/2);
  t := evalf[2*d](op([1,2],s) - op([1,1],s));
  g := length(trunc(abs(a))) + floor(abs((log10(frac(abs(t))))));
  print(evalf[10](a), t);
  if g >= 10 then
    ans := evalf[10](a);
    break;
  end if;
end do:
                                          -8
                    -5.277921592, 2.255 10  
                                          -9
                    -5.277921589, 2.256 10  
                                         -10
                   -5.277921590, 2.257 10   

ans;
                          -5.277921590

Another way to consider the aspects I mentioned might be to successively compute r accurate to d digits, and then construct an INTERVAL(r-10^(-d), r+10^(-d)) and examine what could be done with that.

Note that simply using default Digits=10 working precision need not produce the answer correct to ten significant digits, whether done using operators or expressions. But both approaches could be used to find the answer correct to ten significant digits.

# Kitonum's suggestion
restart;
f := x->2*sin(x^2/2)-sin(x/2)^2:
x0:=fsolve(D(f)(x)=0, x=1..2);
                   x0 := 1.687052124
(D@@2)(f)(x0);
                      -5.277921591

restart;
f := 2*sin(x^2/2)-sin(x/2)^2:
r:=fsolve(diff(f,x), x=1..2);
                    r := 1.687052124
eval(diff(f,x,x), x=r);
                      -5.277921591

restart;
Digits:=20:
f := x->2*sin(x^2/2)-sin(x/2)^2:
x0:=fsolve(D(f)(x)=0, x=1..2);
                x0 := 1.6870521236466276364
(D@@2)(f)(x0);
                  -5.2779215898752826466
evalf[10](%);
                      -5.277921590
restart;
Digits:=20:
f := 2*sin(x^2/2)-sin(x/2)^2:
r:=fsolve(diff(f,x), x=1..2);
                r := 1.6870521236466276364
eval(diff(f,x,x), x=r);
                  -5.2779215898752826466
evalf[10](%);
                      -5.277921590

One way to do it is by using the plots:-densityplot command. But that can make the Maple GUI behave badly if the grid size is too large. And that allows you to shade the hue by the argument, but doesn't provide any nice mechanism for controlling the intensity or saturation layers.

Instead you can create a color image directly as a 3-dimensional Array.

The following can be made faster, but here I'm focusing on the process.

If you want to get fancy you could try and implement a piecewise structured adjustment to the intensity or saturation layers of the Array (as representing HSV format).

If you increase the grid size (m and n) a great deal then you'll be better off visualizing it with ImageTools:-Embed than with plot and its background option.

argument_plot.mw

See also this very old post. But ignore the followup Comments where I added plot axes, since that is done better and more easily in modern Maple by using the background option of the plot command (as I did above).

See also the MathApp accessible in the Help system under the topic ArgumentShading .

For comparison's sake, here is plots:-densityplot on the same example,

density_arg.mw

I could also mention that the color shading data can be pulled out of the plot structure returned by plots:-densityplot, as discussed in this old post.

The keystroke pair Ctl-t switches from math entry mode to text entry mode. That text will appear in black by default.

From text entry mode you can use Ctl-r to switch to active math entry mode, or you can use Shift-F5 to switch to inactive math entry mode.

You can switch back and forth, in order to produce 2D typeset math appearing inlined within a paragraph of text. The active math will get executed (when you hit the !!! icon on the menubar, say) while the inactive math won't get executed.

What you saw in red was 1D Maple Notation (plaintext) math, and not text.

You could put the values in a Matrix and then export using commands like ExportMatrix or ExcelTools:-Export . No need to copy & paste.

Dummy_5_ac.mw