@Ahmed111 With the name d assigned the determinant of that Matrix, I just looked at the typeset 2D Math output of the following statement in my Maple 2018, and observed the common subexpressions I used for R1,..,R4.

simplify(simplify(collect(d,[rho,chi],u->simplify(u,size))),size);

And then I cut & pasted.

But if you are interested in common subexpressions, for the purpose of easier viewing or greater insight into the structure of your expression, then you might consider using an older output labelling mechanism. (I do not mean the equation labelling that one can see along the right edge of a worksheet. I mean an older mechanism, for prettyprint=1, that represents common subexpressions and makes output terse.)

For this current example it just so happens that the default "maximal label expression size" allows for automatic labelling of exactly the particular common subexpressions I used above (originally, by cut&paste) for R1 and R2. So below I happen to be able to construct that R1 and R2 programatically, which I find neat.

Download some_labelling.mw

I think that the automatic labelling of common subexpressions was one of the best features of the old Classic GUI. It's a great loss that the newer Standard Java GUI doesn't have it for typeset 2D Output and enabled by default (and with as clever an automatic mechanism as Classic had for deciding on the labels by size). The loss is made even more severe since one of the greatest instabilities remaining in the Standard GUI is in it locking up when trying to render very large expressions close to the default length-limit. There are a lot of examples where the common subexpression labelling mechanism can greatly reduce the total output display.

@itsme Thanks.

I suppose one might also replace the conjugate(K3)+K3 by 2*Re(K3) , but maybe we're already in territory where beauty is in the eye of the beholder.

@vv Yes, I was wondering whether a fortuitous Change and Split might allow resolution of the `abs`, which might make it more tractable.

@mschneider Let me know if this handles at least some of your other problematic examples.

Download parsedelay.mw

@digerdiga The Cuhre method of the Cuba library (an external link to which evalf/Int calls) is documented as being a deterministic and not a Monte Carlo approach. It implements a globally adaptive subdivision scheme.

@tomleslie DirectSearch:-SolveEquations has its own depressing bugs and faults.

@Christopher2222 Then why did you name this Post as "Maple 2019 wishlist"??

Now might be a suitable time to make suggestions for Maple 2020.

@Annonymouse The size option of the Explore command can be used to specify the dimensions of the plot (Plot Component).  But there is also functionality to specify the dimensions of the entire assembly, using the width and widthmode options.

Explore(plot(sin(a*x)),a=1.0..10.0, size=[500,300]);

Explore(plot(sin(a*x)),parameters=[a=1.0..10.0],size=[500,300],
        widthmode=pixels, width=700);

Explore(plot(sin(a*x)),parameters=[a=1.0..10.0],size=[500,300],
        widthmode=percentage, width=100);

The dimensions of the entire assembly constrain the dimensions of the Plot Component.

See the help page for topic Explore for more details.

@Joe Riel 

Here is Maple 6.01,

kernelopts(version);

     Maple 6.01, SUN SPARC SOLARIS, June 9 2000 Build ID 79514

g:=rand(1..100):
(a,b)(g());

                      a(82), b(82)

restart;
g:=proc()
  global c;
  if not c::integer then c:=0;
  else c:=c+1; end if;
  args;
end proc:
Op:= (R,F)-> F(['R()'$2]):
c:=0:
Op(g@rand(1..9), [f,f]);

               [f([4, 9]), f([4, 9])]

c;

                         2

restart;       
Op := proc(R,F)
 local a;
 a := R, R;
 F(a());
end:

Op2 := proc(R,F)
 local a;
 a := R, R;
 a := a();
 F(a);
end:

([Op] = [Op2])(rand(1 .. 9), [f, f]);

          [[f(4, 9), f(4, 9)]] = [[f(1, 6), f(1, 6)]]

restart;
g:=rand(1..100):
trace(evalapply):
(a,b)(g());
{--> enter evalapply, args = a, b, [82]
{--> enter evalapply, args = [a, b], [82]
<-- exit evalapply (now in evalapply) = [a(82), b(82)]}
<-- exit evalapply (now at top level) = a(82), b(82)}

                      a(82), b(82)

And here is Maple 7.00,

kernelopts(version);

     Maple 7.00, SUN SPARC SOLARIS, May 28 2001 Build ID 102934

g:=rand(1..100):
(a,b)(g());

                      a(82), b(71)

restart;
g:=proc()
  global c;
  if not c::integer then c:=0;
  else c:=c+1; end if;
  args;
end proc:
Op:= (R,F)-> F(['R()'$2]):
c:=0:
Op(g@rand(1..9), [f,f]);

               [f([4, 9]), f([1, 6])]

c;

                         4

restart;       
Op := proc(R,F)
 local a;
 a := R, R;
 F(a());
end:

Op2 := proc(R,F)
 local a;
 a := R, R;
 a := a();
 F(a);
end:

([Op] = [Op2])(rand(1 .. 9), [f, f]);

          [[f(4, 9), f(1, 6)]] = [[f(2, 6), f(2, 6)]]

restart;
g:=rand(1..100):
trace(evalapply):
(a,b)(g());

                      a(82), b(71)

There was also a Maple 6.1, but I don't have access to it.

@Carl Love I disagree with this, "...I can look at it and immediately say Surely Op and Op2 ought to produce equivalent output for any input for which they both produce output. I mean ought in the moral sense."

I suspect that you are allowing the obfuscation of the example to cloud your moral judgement. Just because the formal parameter (eg, F) appears as merely a name in the body of a procedure should not convince us that it ought to behave like a name or scalar. We must not forget that its appearance is merely a placeholder. That is central here.

Having two instances of R in a sequence is just more obfuscation that doesn't help us. Separating R from its application is yet more obfuscation that abstracts away from the central issue. Having the whole business within a procedure like Op or Op2 gets in the way of coming to grips with the central issue. There's a reason why my first Reply above contains the example it does. The principal focus should be only whether application ought to follow or precede distribution amongst a non-scalar expression of appliable types.

If we pull Christian's example apart, and rework it at the top level, then the key issue persists and is no more than that in the example of my first Reply. The moral standing should not change just because of obfuscating details.

Download distrib_eval_top.mw

I tend toward the notion that application (and hence evaluation) must follow distribution (to whatever is "appliable") in the second argument passed to Op -- because before each individual functional-application there is not yet knowledge of whether evaluation is legitimately to be done.

Stating that evaluation of procedure call arguments is "only done once" should mean that there is only one full evaluation per application call, rather than say two or more full evaluations per individual application call. In the above examples there happen to be more than one application call (after distribution).

There are at least two ways that this can make life awkward:
1) Shorthand functional programming examples like plot([Re,Im](expr)) are conveniently terse but not efficient.
2) Side-effects (which are evil in their own right) can be more insidious. RNGs are big, evil side-effect engines.

You've probably already looked for brief workarounds. If you want only one evaluation of the expression generated from the first argument passed to Op then I suggest doing that separately. A procedure local seems a reasonable place to store the intermediate. Does the first example below serve? I suspect that merely examining the number of distinct integers in the final result is not necessarily a robust check against unwanted extra evaluations, so I've thrown in a global counter for good measure.

Download distrib_eval.mw

I'm not sure I understand your thrust.

Does this seem wrong?

restart;                  
g:=rand(1..100):          

(a,b)(g());     
             a(93), b(45)

@Carl Love Thanks for the feedback. I'll adjust. And %minimize could be added.

I suppose that it could also stack the domain details, for the multivariate case.

I was playing with support for x=RealRange(Open(a),Open(b)) etc, but then realized that there's not much point if maximize doesn't support it.  That's the only reason why I had var as a separate local, since I was looking at handling the domain with mfenced and its open and close bracketing attributes.

Of course this is not support for parsing typeset 2D Input of this form. But from the view of documenting math work, it is somewhat nice to be able to pretty-print an optimization problem in a standard way, and be able to tie that to a computable result via value.

I suppose one could even do it %Minimize in the Optimization:-Minimize way, in which case open braces could correspond to strict inequality.

[edited] I've replaced the code in the Answer. An inert Limit call gets the "lim" displayed with `#909090` gray which I find difficult to read. Above I've used `#606060` gray for "max" and "mix", but of course one can change it.

You might also be interested in the iterated exponentiation  z^z , z^(z^z) , z^(z^(z^z)),  etc.  There is an application which explores plots of such sequences here.  See also this walkingrandomly post.

If you are interested in plotting (only) the values of a single powering then you can also produce some 3D plots which take height and shading by using magnitude and complex argument. Eg,

plots:-densityplot(argument((a+b*I)^(a)),a=-4..4,b=-100..100,
                   colorstyle=HUE,style=surface,grid=[201,201]);

# The option `restricttoranges` may flip x and y.
Explore(plots:-densityplot(argument((x+y*I)^(a+b*I)),x=-4..4,y=-4..4,
                   restricttoranges,
                   colorstyle=HUE,style=surface,grid=[71,71]),
        parameters=[a=-2.0..2.0,b=-2.0..2.0]);

Explore(plot3d((x,y)->abs((x+y*I)^(a+b*I)),-4..4,-4..4,
                   color=((x,y)->argument((x+y*I)^(a+b*I))),
                   style=surface,grid=[71,71]),
        parameters=[a=0.0..2.0,b=-2.0..2.0]);