@Mariusz Iwaniuk Ingenious.

Paraphrasing, and using Maple 2021.2,

integral_ac.mw

Since the OP seems to have used Maple 18 (in which Sum doesn't take formal as an option),

Download integral_ac_1802.mw

@C_R For your following example I wan't sure whether you wanted to 1) turn either expression into the other, or 2) show that they are equivalent. All under an assumption, of course.

Here's both, under the wider assumption r>=-1.

Download some_simp_ex.mw 

On the chance the you were actually trying to make ee1 turn into ee2, here's a more ad hoc and step-by-step explanation of what I did above. I say "ad hoc" because it contains assumptions placed manually on r+1 and r-1, whereas in the above worksheet I tried to make it more programmatic, deriving those assumptions on terms r+1 and r-1 (multiplicands in the factored radical) from assumptions like r>=-1 or r>=1 say. A wholly ad hoc solution to a problem like this no better than merely writing out the desired form by hand.

The idea is that simplify can pull out factors from the radical (under suitable assumptions). But collapse of the factored form back to r^2-1 gets in the way. So an approach is to replace factors by their frozen names, and place the corresponding assumptions of positivity on such (if appropriate). Making that replacement more automatic and less ad hoc is icing.

Download some_simp_ex_notes.mw

@C_R You may use any of the following.

Download Simplify_exp_with_roots_02_ac.mw

I prefer not to use the 2D Input that looks like,
   0<r<1
because it gets parsed as  0<r and r<1   and I prefer to avoid lowercase and here.

sidebar: I have seen instances where calling is((rhs-lhs)(eqn)=0) does better than is(eqn) for eqn some equation. That step may not always have been done automatically (at least historically), and simplification-to-zero is sometimes easier than reduction to a pair of forms accepted as equivalent.

Duplicates threads about this code will be flagged as such (and may be deleted).

If you have additional problems with correcting the code then you could describe those here, in Reply/Comments, instead of adding wholly separate and unconnected additional discussion threads.

@Ronan It looks as if you might have accidentally saved your own packages to that DirectSearch.mla file at some time in the past.

One way that could happen is if you used `savelib`, and it was writable and first in `libname`. 

This is one reason why I prefer to store to .mla files only by using LibraryTools:-Save (not savelib) and specifiy the library file destination explicitly.

You may wish to (remove and) reinstall a clean instance of DirectSearch v.2.

@tomleslie I could get around that abs error by a slight adjustment to Carl's code (but without having to raise Digits or set UseHardwareFloats=false, etc).

Eg,

restart:
ABS:= (a,b,c)-> [a-b*c <= k*c, a-b*c >= -k*c]:
(L,M,U):= seq([cat](x, __, 1..3), x= [l,m,u]):
Cons:= 
    (op@ABS)~(
        map(op@index, [L,M,U], [1,1,2]),
        [.67, 2.5, 1.5, 1, 3, 2, 1.5, 3.5, 2.5],
        map(op@index, [U,M,L], [2,3,3])
    )[],
    add(L) + 4*add(M) + add(U) = 6,
    (L <=~ M)[], (M <=~ U)[]
:
Sol:= Optimization:-NLPSolve(k, {Cons}, assume= nonnegative)[2]:
evalf[5](Sol);

    [k = 0.23607, l__1 = 0.40747, l__2 = 0.31246, l__3 = 0.16437, 

     m__1 = 0.45430, m__2 = 0.36753, m__3 = 0.16437, u__1 = 0.54121, 

     u__2 = 0.44972, u__3 = 0.17998]

@C_R You might be interested to know that there are some common terms for some of these things.

Your examples may be considered as functional programming (in Maple). Good examples are scarce in the Help pages, eg. 1, 2. Basically, Maple allows for a quite useful functional syntax.

Sometimes elements of this are called functional operators but that's a slight misnomer here since functional programming can cover a broader flavour of procedure than just an operator -- in Maple's technical sense.)

I too am a fan of using an anonymous procedure (or some concoction from a functional algebra) when I want to make convenient multiple references to the same thing, from within a single statement.

Depending on who you're talking to, you might hear some comparison of such anonymous procedure use in Maple with pure functions in Mma.

@C_R You're welcome. Here it is again, and below a slightly more involved alternative, for your information:

Download expr_equals_evalexpr_acc.mw

@tomleslie My Maple 2021.2 and Maple 2021.1 for Linux both have this command result,

interface(typesetting);

              standard

Curiously, the GUI's menubar's Tools->Options/Display shows "Extended" for the "Typesetting level" item.

I have previously noted that, and found it a weirdly confusing state of affairs in Maple 2021, and supposed that it was an intentional change (whose ramifications I don't really grok). I have not changed the GUI's setting away from default, on installation. And I launch Maple without any initialization file.

Anyway... if I manually make the call,

   interface(typesetting=extended):

then I can reproduce the undesired rendering that you showed. But by default I get it as I showed it.

@mmcdara Suppose that one has a preassigned list of strings L of length m*n (not all entries the same, say).

Then there are a variety of other ways in which one could construct m-by-n Matrix without having to manually enter the columns or rows (ie. as individual lists). And one could place the entries column-wise or row-wise, without having to transpose.

For amusement, here are some examples. (Not an exhaustive collection...)

restart;
interface(rtablesize=100):
with(ListTools,LengthSplit):
(m,n):=4,6;
L:=[$"a".."z"][1..m*n];
Matrix([LengthSplit(L,2)]);
Matrix([LengthSplit(L,m)]);
ArrayTools:-Reshape(Vector(L),[m,n]);
Matrix([seq(L[(i-1)*m+1..i*m],i=1..iquo(nops(L),m))]);
Matrix([seq(L[[seq((i-1)*m+j,i=1..iquo(nops(L),m))]],j=1..m)]);

The OP has also mentioned,
   Matrix(m, n, (i, j)-> L[j+n*(i-1)])
for one of the flavours laying down entries row-wise, ie. like my,
   Matrix([LengthSplit(L,n)])
Both are easy, and fine. (I sometimes have an internal resistance to using a user-defined procedure which might get called many times, if I can get by with seq and indexing. That's just me. It doesn't matter here, and it avoids production of collectible garbage sublists.)

@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.