I have to state that your "problem" is not something to do with simplify specifically. It's to do with evaluation.

And the behavior is completely normal. Your expression that is assigned to T contains the global l1 and l2 names, and if you subsequently assign values to those same names then it should be expected that any full evaluation of T will result in the values of l1,l2 being utilized. Perhaps you know all that, ok.

Yes, you could pass an unevaluated T into a modified version (using the uneval modifier) of your procedure simplify2 and then evaluate the passed argument only 2 levels. Note that any inadvertant full evaluation of the procedure's 2-level evaluated version of the expression would break the effect.

Note that you could also pass a 1-level evaluation eval(T,1) into your original simplify2 and get a simlar result. But again, any inadvertant full evaluation within simplify2 would break the effect. simplify2_orig.mw

You could also robustify the route of using the uneval modifier, by forcibly replacing all the names with generated locals. In the attached I done that, and made a few other edits. It also shows a few other "length" metrics. cost_simplify.mw

But now I come to my main point. Your Question stated: `The variable "l1" stands for "length 1" in a mechanic problem as well as "length of the expression"'.  The core problem is use of the same global name l1 for different purposes! Don't use the name l1 (of the same scope) within an expression to stand for "length 1" (of a beam or whatever) while also using or assigning l1 (at the same scope) to mean "length of the expression". That is wrong programming. Trying strange programming hacks to work around this fundamental programming mistake is not the right way to go.

I realize that you've supplied a smaller example of your full work, to represent this issue. But much better would be to back up and figure out how to use different names for different purposes.

There are examples of plotting multiple expressions on the Help page for Topic plot.

Here is is with f and df as expressions. Notice that in this case the plot command's second argument is x=-5..5 (ie. name=range).

f := ( (x^3) / (2) ) - 5*x + 2;

               1  3          
          f := - x  - 5 x + 2
               2             

eval(f, x=4);

                 14

df := diff(f, x);

                   3  2    
             df := - x  - 5
                   2       

plot([f, df], x=-5..5);

You could also add various options, for example,

plot([f, df], x=-5..5,
     thickness=3,
     color=["Purple", "Green"],
     legend=['f','diff'('f',x)]);

See the Help page for Topic plot,options for more details.

And here it is below with f and df as procedures (arrow operators) instead. The plot will look the same. Notice that in this case the plot command's second argument is just the range -5..5 .

f := x -> ( (x^3) / (2) ) - 5*x + 2;

      f := x -> (1/2)*x^3-5*x+2

f(4);

                 14

df := D(f);

       df := x -> (3/2)*x^2-5

plot([f, df], -5 .. 5);

The very best way to make progress with Maple is to learn the programming language, bit by bit. It will reward you, going forward, and it will allow you to deal with more complicated examples than the purely "clickable"/tutor approaches could ever handle.

Make sure that you are running the latest point-release for your major version, ie. Maple 2019.2 .

The strange floats in your results hint that your license verification might be having trouble (either a cracked version or a rare false positive detection of such). The later point-release may do better.

This works in Maple 11 (as well as later versions):

expr := -(729*beta*(1/2*(-1/9*(-5/27*beta-1/9)*lambda^6-1/9*(1/9*beta^2*TT+
(10/9*TE+2/3*TT)*beta-1/9*TE)*lambda^4+5/27*(2/5*TT*(3/2*TT+TE)*beta+TE*
(TE-2/5*TT))*beta*lambda^2-1/9*TE*beta^2*TT*(-TT+TE))*p1(m,t)^2+(beta*
TT-1/3*lambda^2)^2*(-1/3*lambda^2+TE)^3*((p2(m,t))/(lambda^2-3*TE)+3/2*(
(lambda^2+TE)*p1(m,t)^2)/((lambda^2-3*TE)^3))))/((3*beta*TT-lambda^2)^3*
(3*TE-lambda^2)^2):

collect(expr, [p2,p1], simplify);

                                       2                  2         2
     3 beta p2(m, t)         (-5 lambda  + 3 beta TT) beta  p1(m, t)
   ------------------- + 3/2 ----------------------------------------
                     2                                   2 3
   3 beta TT - lambda                 (3 beta TT - lambda )

The result is very close to your given target expression, up to the leading signs or the two terms. You gave the target as,

-3*beta*p2(m,t)/(lambda^2-3*beta*TT)                                            
+3*beta^2*(5*lambda^2-3*beta*TT)*p1(m,t)^2/(2*(lambda^2-3*beta*TT)^3);

                                  2          2                      2
      3 beta p2(m, t)         beta  (5 lambda  - 3 beta TT) p1(m, t)
  - ------------------- + 3/2 ---------------------------------------
          2                                  2             3
    lambda  - 3 beta TT               (lambda  - 3 beta TT)

Calling simplify(expr) in Maple 2020 produces a result similar to this next result in Maple 11 (in which version the size option of simplify is not enabled by default).

simplify(simplify(expr),size);

     //                2\2                /          2          \               \                                                                  
     ||          lambda |                 |  5 lambda           |         2     |                                                                  
  27 ||beta TT - -------|  p2(m, t) + 1/6 |- --------- + beta TT| p1(m, t)  beta| beta                                                             
     \\             3   /                 \      3              /               /                                                                  
  ------------------------------------------------------------------------------------                                                             
                                               2 3                                                                                            
                            (3 beta TT - lambda )

Here is something from the first file: Beregningsdokument_ac.mw

There seemed to be something mixed up with the XML Font tags and the Code Edit Region. (You had two copies of the TgPakken  source within it -- I deleted the duplicate which had Font irregularities, as well as a misplaced closing </Font> tag. I'm not sure if it related to UTF-8 and strings in the Code Edit Region, or something related to an attempt at marking up a duplicate copy of the source in the C.E.R.) Please check it.

Here is something from the second: Beregningsdokument_2_ac.mw   It was the same issue, so please check this file.

This problem is not the same kind as in the older Question to which you linked, and not fixable by Joe's procedure in that thread. Also, neither Document is recovered (even partially) by opening in Maple 2020.0.

You might want to make regular backup snapshots from now on.

By the way, you seem to be running Maple 17.00, without the (free) point-release update 17.02.

Your version of the procedure has a line,

    z := `mod`(z^((1/4)*p+1/4), p) = 1;

instead of,

    z := `mod`(z^((1/4)*p+1/4), p);

In other words, your procedure is computing the z values differently. The "= 1" is an accidental typo, in your rewrite.

By the way, why did you change some of the &^ calls to ^ calls? Are you aware of the difference? You might want to read the Description of the mod help page, where there is a bullet point on this.

I don't really understand why you've rewritten so much of the procedure. Would you care to explain why you changed it?

If you do not actually need the intermediate results (with base symbol B) then you can do it all in one shot.

varA := [A[1, 0], A[1, 1], A[1, 2], A[1, 3], A[1, 4], A[1, 5],
         A[1, 6], A[1, 7], A[1, 8], A[1, 9], A[2, 0], A[2, 1],
         A[2, 2], A[2, 3], A[2, 4], A[2, 5], A[2, 6], A[2, 7],
         A[2, 8], A[2, 9], A[3, 0], A[3, 1], A[3, 2], A[3, 3],
         A[3, 4], A[3, 5], A[3, 6], A[3, 7], A[3, 8], A[3, 9]]:

T1 := table([2=3,3=2,5=6,6=5,7=9,9=7]):
T2 := table([2=3,3=2]):

map(u->A[`if`(assigned(T2[op(1,u)]),T2[op(1,u)],op(1,u)),
         `if`(assigned(T1[op(2,u)]),T1[op(2,u)],op(2,u))],
    varA);

    [A[1, 0], A[1, 1], A[1, 3], A[1, 2], A[1, 4], A[1, 6], A[1, 5],
     A[1, 9], A[1, 8], A[1, 7], A[3, 0], A[3, 1], A[3, 3], A[3, 2], 
     A[3, 4], A[3, 6], A[3, 5], A[3, 9], A[3, 8], A[3, 7], A[2, 0], 
     A[2, 1], A[2, 3], A[2, 2], A[2, 4], A[2, 6], A[2, 5], A[2, 9], 
     A[2, 8], A[2, 7]]

You didn't mention whether you needed to have it be highly efficient for case of very long input lists (or if you had a great many examples to process). Also, are all the entries simply the name A, indexed by such a small number of possible integer values?

Alternatively, you might have only a modest number of modestly sized examples, and want the simplest kind of code (that you will understand immediately upon looking at it, years from now, etc).

Here is an alternative (which computes comparitively quickly for your given example),

T1 := table([0=0,1=1,4=4,8=8,    2=3,3=2,5=6,6=5,7=9,9=7]):
T2 := table([0=0,1=1,4=4,5=5,6=6,7=7,9=9,8=8,    2=3,3=2]):
map(u->A[T2[op(1,u)],T1[op(2,u)]], varA);

And even there you could easily construct the trivial parts of those tables programmatically.

The problem is due to numeric issues along the boundary.

In Maple 2017, for this example it is much easier to retain the default grid size and simply reduce the plotting domain by a very small value. For example, plot3d_question_M2017.mw

BW_dilog:= proc(x)
  Im(dilog(1-x))+log(abs(x))*argument(1-x)
end proc:
V:= proc(z,t)
  BW_dilog(exp(I*z))-BW_dilog(exp(I*(z+t)))+ BW_dilog(exp(I*t)) 
end proc:

plot3d( [V,0], 1e-9 .. 2*Pi, 1e-9 .. 2*Pi );

You could try to pass the grid option in your Maple 2017 so that it utilized a much greater number of points (in both dimensions). That would push the problematic boundary and look slightly more like you want, but it would be at much greater computational expense. And the GUI gets sluggish if you make that resolution too fine. Also, you would need to use a very high grid resolution. (Note: it would have to be considerably greater than the [100,100] that Tom used -- his result looks very good because he used Maple 2020, and not because he used grid=[100,100] . It would have to be considerably greater than [200,200] which is similar to Kitonum's numpoints=40000 suggestion and which already takes much longer to compute. I suspect that the problem cannot be effectively and practically solved using a finer grid resolution alone.)

For interest's sake, in Maple 2020 this problem is handled automatically through its new adaptmesh option (true by default). Your original attempt produces the following directly (3D plots are also larger by default in Maple 2020) even with the default grid setting of [49,49]. You could also increase the grid resolution here (and/or use parametric form calling sequence of plot3d), to get even better behaviour along the problematic boundary. And, of course, you could still reduce the plotting domain here too.

Your original object was created as an operator (a kind of procedure) whose body contained the active summation using the sum command in 2D Input.

As mentioned, you can use the Sum command instead to get an inert summation which will not produce the Bessel result when the procedure is invoked. If you want inert summation in 2D Input then you can use the command-completion template for Sum. You can get this by invoking (I use the Escape key) command-completion after you have typed in just the letters S u m while in 2D Input mode, and selecting from the popup menu.

You can also use D the functional differentiator and obtain D(X) as a new operator. You could furthermore call that at a point x, also as D(X)(x). That is another (slightly better here, IMO) was that as you had it with the 2D Input form of diff(X(x), x) .

And, naturally, you can apply the value command to turn the inert summation expressions into their Bessel results.

I've put all this in the attached Document:  bessel_ac.mw

I'll mention that there is also an inert differentiator Diff, as in Diff(X(x), x) , which also has a command-completion template for 2D Input.

What about,

ans1 := [alpha[3, 7], alpha[3, 8], alpha[3, 9]]:

map[2](op, 1, ans1);

            [3, 3, 3]

map[2](op, 2, ans1);

            [7, 8, 9]

Or were you looking to form both with a single call? For example,

ans2 := [alpha[3,7], alpha[3,8], alpha[3,9],
         alpha[2,2], alpha[7,19]]:

(A,B) := map(op~,[1,2],ans2)[];

     A, B := [3, 3, 3, 2, 7], [7, 8, 9, 2, 19]

A;

               [3, 3, 3, 2, 7]

B;

               [7, 8, 9, 2, 19]

Your code has this line, which is invalid due to the recursive assignment of the name e in terms that involve function calls to itself. As written, it does not make sense.

e := (beta*(1-u[1])*s(t)*sigma[2]*e(t)+sigma[1]*i[t])/w[3];                         
Error, recursive assignment

There is some similar mixup going on with i and i(t), and in one place you also have i[t] with square brackets.

And you also use these names in max calls that appear in the RHSs.

It's a muddle.

What meaning did you hope for these statements to have?

If I understand it properly then you want to be able to select some group of line segments (in an existing, already displayed plot) so that they are all highlighted together, by performing a single left-click with the mouse pointer.

But you also want to be able to construct these individually using the plottools:-line command. Have I got that right?

Each line segment is formed as its own CURVES plotting substructure. You can group these together by combining all their data values into a single CURVES structure -- yet separated by Float(undefined) values. For example, lineseg_group.mw . You could modify that to retain other properties of the curves, but the end "group" of segments would have to share a single color, linestyle, etc.

There are several other ways to programmatically construct such a group of line segments. You could use the plot command on a list of points that you split up front. That might make it more convenient to set the color, style, etc. For example, lineseg_group_2.mw .

Apologies, if I've misunderstood the goal. If I recall correctly, the GUI will highlight (all of) only a single CURVES structure at once, when left-click selected in an exisiting, displayed 2D plot.

Carl's suggestion to apply simplify to the integral does work here, but his supposition that the cause of the problem is the piecewise (and also of why simplify fixes it) is mistaken.

The problem is due to the floating-point exponent (0.99 in the denominator, ie. a power of -0.99), and not because of the piecewise form.

You can get rid of that problematic float exponent in several ways -- one of which happens to be as a side-effect of applying simplify. Indeed, using simplify will even work if applied to the integrand directly, ie. it does not need to know the integration bounds and resolve the piecewise branches.

There are, in consequence, several other ways to complete the floating-point numeric integration successfully, since there are other ways to obtain an equivalent integrand without that floating-point exponent. They work, even though they still contain a similar kind of piecewise (except that the particular exponent is no longer a float).

NumericInt_acc.mw

Up around 9 lines from the bottom of that file you should see a text line like,

    map(x->assign(SF[x],cat(`SF/`,x)),

Try changing it to,

    map(x->assign('SF'[x],cat(`SF/`,x)),

where the edit is the addition of two right single-quotes (forward quotes).

You can wrap your calls to ModularSquareRoot inside try...catch to trap the error (and then proceed how you prefer.)

For example,

  try
     ModularSquareRoot( blah, blech );
  catch:
     FAIL;
  end try;

Or you could put that into a convenient and reusable procedure, ie.

  TrapMsqrt := procedure( )
    try
       ModularSquareRoot( args );
    catch:
       FAIL;
    end try;
  end proc:

  TrapMsqrt( example1 );
  TrapMsqrt( example2 );

There are several variations on this theme. You could add basic argument checking to the wrapping procedure. You could get fancy and catch some specific kinds of errors (eg, related to invalid input, etc) and rethrow them. You could turn errors (that related to the failed conditions) into an informative message -- which could be optionally emitted using Warning or userinfo. And so on.