You haven't shown the full example that demands loading all of VectorCalculus, or using assume instead of say assuming. So it's not possible to properly address subsequent -- but as yet unstated -- issues you may have.

However,

Download VCD.mw

eqs := {a + b + c = 1,
        a^2 + b^2 + c^2 = 2,
        a^3 + b^3 + c^3 = 3}:

a^4 + b^4 + c^4 = eval(R,solve(eqs union {a^4 + b^4 + c^4=R}));

                        4    4    4   25
                       a  + b  + c  = --
                                      6 
a^5 + b^5 + c^5 = eval(R,solve(eqs union {a^5 + b^5 + c^5=R}));

                         5    5    5    
                        a  + b  + c  = 6

I recall having the same questions, when ColorTools first appeared.

At that time I was able to find, in the internal code, a transformation Matrix corresponding to D50 (which confirmed a few empirical tests). In a subsequent release I noticed that had changed to correspond to D65. But there seems to be little or no documentation about that.

And I believe that by "RGB" the ColorTools package means sRGB, not a wider gamut like Adobe RGB. (Some monitors allow one to toggle amongst such. But I have never tested what effect that might have on what the Maple GUI shows. A missing bit of knowledge might be which the Java GUI's renderer is using.)

Another interesting detail might be just how ColorTools makes certains colors (when converted to RGB from, say, Lab or Luv) "displayable". It's not always clear how it may regress back to the displayable gamut, ie. does it regress linearly back to the white point, or what?

Eventually I wrote my own converters (also via XYZ colorspace) because I wanted them to Compile and be fast on datatype=float[8] rtables representing many colors (eg, images). That gives me full control about the mathematical conversion, though details of the GUI's renderer may still be a missing link in the chain, if I want to visualize.

What form do you want for the results?

Download trighsimp.mw

Do you want something like this?

[edit] Originally I used the range 0*Unit(mm)..100*Unit(mm) along with the accomodating x*Unit(mm) in the calls to tau and Q when plotted. But that only works (by accident) in Maple 2017. So below I've changed the range to 0..100 instead, which makes more sense alongside the argument x*Unit(mm) and which seems to work in both Maple 2017 and Maple 2019.[/edit]

Plot_function_with_units_ac3.mw

[edit] How you approach this may well depend on what you start with. If you have the liberty of entering the initial expression passed to exp (or sin and cos) then it is easier since you can use a replacement symbol for Pi. My suggestions below are more for the case that you've already obtained the -1/2+1/2*I*3^(1/2) form. [/edit]

Here are three related ways.

The first two include examples of printing the inert % form of sin and cos calls without getting the gray elements in the output.

The third way simply delays evaluation (and in consequence is fragile because any subsequent full evaluation undoes the effect).

Download inert_rcistheta.mw

You may also use InertForm:-Display to show the %Pi from Carl's Answer without the gray symbol. Eg,

bar:=cos(2*%Pi/3)+I*sin(2*%Pi/3);
InertForm:-Display(bar, inert=false);
value(bar);

But in that case you cannot so easily extend the `print` facility to make that aspect automatic.

It is possible to adjust the underlying code so that it also colors (extended typesetting mode) typeset math.

The following seems to work ok for me in Maple 2016.2 through to Maple 2019.0.

Tabulate_mathcolor_hotedit.mw

I don't think that you are doing anything wrong. It's not easy to handle the (possible) splitting fields always best, in general. But your example shows that there's likely something to improve. (I'm submitting a bug report.)

Download evals_ac.mw

I have previously submitted bug reports for examples such as this where simplify(...,size) does not compress as much as can a judicious collect with simplification of the ensuing coefficients.

In this example that situation occurs for the subexpression within the radical.

I have an oracle that speculatively tries collecting w.r.t. the relevant names in the subexpression (sum), and indicates which compresses well or best. Hence the following suggestions, relating to collect w.r.t. g. These vary a little because more generally you may or may not want other kinds of simplification effects:

Download simplification_under_sqrt_ac.mw

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