@janhardo 

If you actually intended z(phi)=exp(I*phi) then note that is not what you wrote. Your earlier text did not have phi in the exponent because it lacked any bracketing. If it were then I might guess that you want to differentiate with respect to phi. I shouldn't have to read your cited Dutch article to get such a basic detail as the actual syntax of the example.

other_diff_2c.mw

@janhardo How am I supposed to guess what you mean by the following?

   z= e^i. phi

What is the variable with which to differentiate?

How does it appear (suppressed?) in the terms on the right-hand-side?

As for a re-usable procedure, well, it can be constructed to do all kinds of things. But guessing the intended scope is inefficient. If you care to carefully and completely describe your full goals then progress could be meaningful.

The purpose of combine(...,power) was previously made clear. It is to handle the following kind of simplification (which may or may not always be relevant, depending on what further examples you concoct...)

I really hope that you understand that it is impossible for anyone to create a procedure that will produce your as-yet-unstated, desired form of output for all future examples which are not yet known. That is not a Maple thing; it is a logical consequence.

A simple re-usable procedure that prints both the equation and its derivative, for those standard Calculus examples. This is merely to keep the input short and clean looking.

You could even hide the code that defines procedure B, eg. in the worksheet's Startup Region.

Download other_diff_2.mw

@Preben Alsholm Yes, that is the point: the second behaves differently due to automatic simplification, which occurs in the Maple kernel between parsing and normal evaluation.

note: I plan on submitting a bug report about the fact that the mouse-copying action of 2D Output in the GUI utilizes the "wrong" one. (I might even have done so sometime in the past. I have a hazy recollection about all this.)

When we see the following output (including the case of 2D Output, which is merely fancier pretty-printing) the underlying expression is a product of two reciprocals. It is not a reciprocal of a product, despite how it may get pretty-printed.

> 1/4*1/(x-2);
                                          1
                                      ---------
                                      4 (x - 2)

> dismantle(%);

SUM(3)
   PROD(3)
      SUM(5)
         NAME(4): x
         INTPOS(2): 1
         INTNEG(2): -2
         INTPOS(2): 1
      INTNEG(2): -1
   RATIONAL(3): 1/4
      INTPOS(2): 1
      INTPOS(2): 4

The unintended automatic simplification occurs in the case that the input is pasted in as (mistakenly) the reciprocal of a product.

@janhardo You can use a consistent approach so that all these examples are handled.

Download other_diff.mw

If you wanted you could make a simple re-usable procedure that printed both the eq and its derivative for those standard Calculus examples. That's just to keep the input terser.

@janhardo I have difficulty understanding some of your sentences, which gets in the way of my understanding your goals.

Perhaps you are trying to achieve something more like one of these, in your followup.

Download some_diff.mw

@janhardo For the sake of formatting...

Download some_int3.mw

@janhardo 

@janhardo Man is the measure of all things. Of things that are, that they are. And of things that are not, that they are not.

Of course  (z-s)^(-1-n)  is the same as  1/(z-s)^(n+1) .

Also,  1/I  is the same as  -I  , and Maple converts the former the latter as part of its automatic simplification.

I don't have much interest in fiddling around to get the output in exactly the right format as you seem to need. Of course it can be done, programmatically. But I don't have time for that minor difference.

The key aspect of answering your query lay in attaining the general derivative, by making the differentiation actually happen for general, unspecified n.

I did that.

I also showed how the result (which came here in pochammer form) could be converted to factorial form.

Formatting exponents and positions of multiplicands in the result is a relatively minor aesthetic. 

@C_R The name `≟` that you found is derived from an HTML entity. I didn't use it because in my Maple 2020.1 for Linux the question mark portion is rendered unusefully small. By happenstance the leading ampersand in that name allowed you to utilize it as an infix operator.

You asked about my use of single left-ticks (aka back-ticks) above. Those are often called name quotes in Maple, because when they wrap some characters the result is a Maple name (aka variable).

The Maple GUI's 2D Math printing mechanisms know that certain special forms of name are to be rendered specially. The first example in my Answer is an example of such a special name. The form (between the left-ticks and the # and semicolor) looks somewhat like MathML.

There is also a special functional form that produces similar renderings. Both the special names and the functional form involve unevaluated returns, ie. they don't evaluate to anything else. The GUI just knows how to render them as marked up math.

`#mover(mo("="),mo("?"));`;
lprint(%);

Typesetting:-mover(Typesetting:-mo("="),Typesetting:-mo("?"));
lprint(%);

The second of those is easier to programmatically generate. I used it in my Answer's example, with a procedure as a special print-extension, so that I could make function calls which rendered as wanted.

Neither of these two typesetting approaches is documented, despite being quite powerful and useful. They've been used many times to get decent solutions to requests on this forum.

I also described using "Over" item from the Layout palette to place an ampersand over a question mark, while in 2D Input mode. When I do that I got a good rendering, and the thing that it actually creates is one of those special names:

   `#mover(mo("="),mo("?"))`

But that can't be used as an infix operator and so is not ok for executable Math (...I padded with spaces, to get multiplication implicitly).

Using the handwriting palette is a dead-end approach, IMO.

@Delali Accolley What values of tau_l are possible?

Setting Digits=11 (up front, except for that problematic final fsolve attempt) works in my Maple 2021.1 for tau_l=0.6 as well as tau_l=0.8.

But what other values of that parameter are you needing? Another approach might be required, but we don't know what is your full set of candidates values.

Also, how large are you willing to accept as the residuals?

Also, what are the valid ranges for the variables?

It may well be better to tackle this as an optimization problem, using either Tom's approach or the DirectSearch (version2) 3rd party add-on from the Application Center.

We can deduce sigma__2 >0 from eq1, given that both d and P__2 are greater than zero.

And if we explicitly utilize that further assumption sigma_2>0 then a closer form can be attained:

Download suggestion_ac.mw

We can also get that same closer form by passing both d>0 as well as eq1 (the original equation for sigma__2) as additional assumptions, since altogether that allows Maple to figure out that sigma__2>0.

So here we're using only the stated original assumptions as well as the original equation:

I sometimes see that message, but I don't recall it ever being accompanied by being bumped out of the current procedure level. I utilize "into" far more than "next", however.

@nm The return value L is most certainly not discarded by map, contrary to your claim! That's the whole point. The return values of f are passed to `+`, since the original expression r (on which map is called) also has `+` as its zeroth operand.

These various claims you wrote are all untrue:

 "Since in the map, the output of the proc f() is not used at all." 

 "...so each time f() is called, the return list (which happened to
  be current value of L) is discarded by map."

 "Return value from f() is not used inside map."

Each of those is statements is wrong.

@Claybourne If I reexecute your whole document (eg, using the !!! triple-exclam button from the Maple 2021 GUI's main menubar) then I get the same output that Tom showed, as expected.