@digerdiga I agree with your formula for D(f^k), except that Maple syntax would require ln(f) to be ln@f. 

There seems to be some deeper problem with D applied to any `^` expression whose exponent (2nd operand) is not of type complexcons (explicit complex constant).

@rlopez The effects of bad typography are often subconscious: longer time to read, agitation, irritation, tiredness, eyestrain, reduced comprehension. The reader may not be aware of the cause of these symptoms.

@hojat I think that after changing Gamma to GAMMA, you are not re-executing the code from the restart command. If I execute your modified code, I get 

Error, (in Optimization:-NLPSolve) no improved point could be found

This new error is much different from the prior. It is not due to a simple syntax issue. It is due to a more-fundamental mathematical issue with solving the problem.

Here's a synopsis: Your objective function I1 is a function of 20 variables. Your call to NLPSolve is essentially equivalent to

"minimize I1 subject to gradient of I1 = <0, ..., 0> (vector of 20 zeros)"

with no other constraints. I suspect that type of thing is slightly outside the designed scope of NLPSolve. The more-usual solution technique is

1. Find via numeric solution techniques the values of the 20 variables that make the gradient 0. This step looks only at the gradient, not the objective.
2. Evaluate the objective at the hopefully finite number of points found in 1.
3. Find the minimum of the evaluations from 2.

I'm not saying that this is computationally feasible (given the large number of variables)! My first choice for attempting it would be the freely downloadable 3rd-party package DirectSearch.

@sursumCorda You misunderstand the purpose of RealDomain:-solve. Its purpose is NOT to return all complex solutions that are also real. RealDomain is correct to return only one solution for this problem. 

Good catch. I confirm that these examples also don't work in Maple 2023, even though the help page ?D clearly says that ... assuming x::constant or ... assuming k::constant should work.

@hojat You need to post the new code for which you claim to have changed Gamma to GAMMA. I see 32 Gammas in the code above.

@ecterrab The MathML operator mn does it correctly, printing an unary negation symbol at about half the width of the binary:

`#mn("-1");`;

So, since the functionality to print the correct symbol already exists in Maple, I'd think that this would be fairly easy to fix.

Your worksheet works for me without any changes. Use the !!! on the toolbar to execute the worksheet in order, from the beginning, starting with restart. I get this plot:

The determinant is large, but Maple can easily handle it.

@ecterrab Here it is. While I do think the unary minus sign is too long, I would not say that this is "absurdly" long. That may have been corrected, and it may have been only a problem of the MaplePrimes rendering rather than the Maple GUI.
 

Download UnaryNegation.mw

@acer Doesn't there exist some somewhat user-friendly menu- / Maplet-based tools for fine-tuning the typesettings? Perhaps they are limited to functions though, just like the older `print/...` mechanism.

@Greenwaldian If you also want the axes themselves to be thicker, then include the option 

'axis'= ['thickness'= 2]  #Note: 'axIs', not 'axEs'

in the setoptions3d or directly in the plotting command. The 2 can be adjusted larger or smaller, as needed, and isn't limited to integer values.

I don't understand the probability split (1/7, 8/21). I think that you made a typo, and that that was meant to be (3/11, 8/11). So, you could improve the code by including an automatic check that the sum at each node is 1.

@C_R I'm not sure here, but I think that the problem that you're describing is that plots as a whole appear too small on very high resolution displays (such as QHD). But I think that the OP's problem is only that the fonts in the plots appear too small.

I've noticed for years that the symbol for unary negation in prettyprinted output is often (but not always) absurdly long and sticks out like a sore thumb. I'd also prefer it to be moved to the right, closer to its operand. When I read these, for a fraction of a second I mistake it for a binary operator with a missing (or NULL) left operand.

What do you think the height of the unary negation operator should be? I think somewhere between 1/4 to 1/3 of a line-space down from the top line would be best. Currently it's halfway down, which also contributes to it looking like a binary rather than an unary operator. 

@Carl Love The comments and expository introductory text of my originally posted worksheet above incorrectly used the graph-theory term minimal dominating set where I should've used minimum dominating set. Although it offends my sense of English grammar---which says that minimal is nothing more than the adjectival form of the noun minimum---the usage of these as distinct terms in graph theory is apparently well established. A minimum dominating set of a graph G is a dominating set of the smallest size of any dominating set of G. A minimal dominating set is one no proper subset of which is a dominating set of G. (Thus, a minimum dominating set is necessarily minimal, but not the converse.)

This error was only in my text and comments; there was no error in the code.

I also added a proof of the fundamental proposition that makes my algorithm work.