Your two expressions are not always equal.

restart;

kernelopts(version);

    Maple 2021.0, X86 64 LINUX, Mar 5 2021, Build ID 1523359

f__1 := sqrt(4*a^2 + lambda__g^2)*c/(2*lambda__g*a):

f__2 := c*sqrt(1/lambda__g^2 + 1/(4*a^2)):

simplify(f__1-f__2) assuming lambda__g>0, a>0;

                  0

simplify(f__1-f__2) assuming lambda__g<0, a<0;

                  0

combine(simplify(f__1-f__2)) assuming real, lambda__g*a>0;

                  0

is(f__1-f__2=0) assuming real, lambda__g*a>0;

                 true

# example where not equal
eval([f__1, f__2], [lambda__g=-1, a=1, c=1]);

          [  1  (1/2)  1  (1/2)]
          [- - 5     , - 5     ]
          [  2         2       ]

This kind of question has been discussed before, eg. here and here.

Unfortunately the brief answer is no, there is no easy mechanism for that.

But it can be kludged using rescaling and forced tickmarks. One can even write procedures to do that automatically.

For your example,

Porig:=plot3d(abs(Zeta(x+y*I)),x=-4..5,y=-10..40,
              view=[-4..5,-10..40,0..4],
              orientation=[-15,75,0]):
Porig;

xl,xh,yl,yh,ny:=-4,5,-10,40,6:
sc:=(xh-xl)/(yh-yl):
plots:-display(
  plottools:-transform((x,y,z)->[x,sc*y,z])(Porig),
  axis[2]=[tickmarks=[seq(sc*(yl+(yh-yl)*(i-1)/(ny-1))
                          =evalf[3](evalf[10](
                             yl+(yh-yl)*(i-1)/(ny-1))),i=1..ny)]],
  view=[xl..xh,map(`*`,yl..yh,sc),0..4],
  scaling=constrained,
  orientation=[-15,75,0]);

The above rescaling is simpler than the general case, as the x-z aspect ratio was already "nice". The z-range and target aspect ratios can also be programmatically incorporated into such code.

There is also no very nice way to programmatically remove that extra white space around that last plot. You can resize and manually zoom, but the only fully programmatic way (of which I know) involves using DocumentTools, eg. DocumentTools:-Layout:-Plot and is more effort.

Each separate evaluated call to your procedure f will return a different and distinct escaped local whose name appears as x.

When you enter f()+f() then that is automatically simplified to  2*f()  before the call to f is evaluated. Hence the result of 2*x.  It works differently in the handling of  f()-f()  and two distinct calls to f get evaluated.

I cannot tell whether you want results in terms of (only) conjugates, or whether abs calls are acceptable.

But one idea might be to yank out the determinant, eg.

   1/simplify(Determinant(A)) . simplify(A.L.Adjoint(A),size)

or,

   1/simplify(Determinant(A)) . simplify(A.L.simplify(Adjoint(A)),size)

restart;
with(StringTools,PatternDictionary):

bid:=PatternDictionary:-Create(`builtin`):
words:=[seq(PatternDictionary:-Get(bid,i),
            i=1..PatternDictionary:-Size(bid)-1)]:

# and now...

StringTools:-Anagrams("trun",words);

                "runt", "turn"

StringTools:-Anagrams("crate",words);

      "cater", "carte", "caret", "crate", "trace"

If you are pulling the candidate string (ie. the first argument passed to the StringTools:-Anagrams command) from somewhere else then you may wish to first hit it with StringTools:-LowerCase so that it matches the strings in the wordlist.

You could also use ospd3 (a large Scrabble dictionary) instead of `builtin`. The former contains some words not present in the builtin list, eg. "gherkins". Or you could construct your own, from some imported collection.

restart;
with(StringTools,PatternDictionary):

bid:=PatternDictionary:-Create(`builtin`):
words:=[seq(PatternDictionary:-Get(bid,i),
            i=1..PatternDictionary:-Size(bid)-1)]:
bidospd3:=PatternDictionary:-Create(`ospd3`):
wordsospd3:=[seq(PatternDictionary:-Get(bidospd3,i),
            i=1..PatternDictionary:-Size(bidospd3)-1)]:

#...and now, using an example for comparison

cand := StringTools:-LowerCase("SAET");

                     cand := "saet"

[{StringTools:-Anagrams(cand,words)}[]];

                 ["east", "seat"]

[{StringTools:-Anagrams(cand,wordsospd3)}[]];

      ["ates", "east", "eats", "etas", "seat"]

The with command will not work properly from inside a procedure, and that is documented.

Instead of the incorrect attempt,
   with(LinearAlgebra);
inside your procedure GaußKronrodQuadraturKurz, you could utulize the uses facility. You can add this line immediately following the local declarations,
   uses LinearAlgebra;

Another choice would be to utilize the full-form name of the package's exported commands, eg.
    LinearAlgebra:-Eigenvectors(...);

Simply call it as,

   Tabulate(DF):

without the print. And then the terminating full colon should have the desired effect.

(Your call to print will force the explicit printing of the returned value, which shouldn't be very surprising because that is the purpose of that command...)

It is worthwhile looking at the result from your call  PDF(0.5*X1 + 0.5*X2, t)  , ie. looking at what is actually being passed to the plot command, and comparing with other formulations.

The integral can be computed (even with floating-point coefficients), without as much numeric damage to coefficients and ensuing evaluation at plotting points. Loss of accuracy can be incurred for this particular example during reformulation (eg. expand, normal, simplify ...).

PDFexpandedpwpoly.mw

I am not suggesting that this is a better workaround that using exact rational coefficients for the original mix. I am trying to address the OP's question about why it can go wrong.

@Maria2212 That call to assume inside procedure S is the cause of the problem.

Remove the call to assume that you have inside S. Then try changing the call to dsolve inside S to this, instead:

   dsolve(L,y(v)) assuming lambda<0;

Also, inside procedure S there is a problematic call to subs which contains this:

   indets(%%,name)[4]

What name are you trying to extract, using that indets call? That method of getting at the name is very poor and error-prone. It should be replaced with something better, but you should tell us first what name it is trying to obtain. Is it one of _C1, _C2, lambda, or v? (Judging from your supplied output I suspect that it is a roundabout attempt to get the name lambda. But perhaps that is another programming mistake.) This should be fixed.

You should also get rid of all the use of % and %% inside S, and instead use assignments to additional local variables.

The use of sum and name-concatenation inside procedure Galerkin is poor. Better would be add and indexed names.

You should not set Digits:=2 . That is a very poor way to display results with only 2 digits, since it incurs significant roundoff error.

There are a couple of difficulties. One is the radical in the denominator, which can be handled using evala or rationalize. Another is the conjugated term.

example_symbolic_ac.mw

Are you looking for something like one of these?

arg_hue.mw

Or are you saying that you want the shading from your 2D image for call to complexplot3d? (It really isn't clear to me, from your Question, sorry). In that case could you simply negate the expression passed to complexplot3d? Eg,

plots:-complexplot3d(-(z - 1)/(z^2 + z + 1), z = -4 - 4*I .. 4 + 4*I
                     , style=surface, view = [-2..2,-2..2,0..2]
                     #, orientation=[-90,0,0]
                     , grid = [201, 201], shading = zhue
                     #, lightmodel=none
                     );

Do you also want contours?

You could also use printf.

Refine_Extrapolation_ac.mw

Here are various ways around that problem in your old Maple 13.

temp2.mw

(The problem relates to the presence of name r both within the indexed name P[r] and standalone, inside the radical.)

Here is a way, using freeze and thaw.  I also added an option for simplification within collect.

T := (p*a^(-Phi(xi))+q+r*a^Phi(xi))/ln(a):
u[0] := C[0]+C[1]*a^Phi(xi)+C[2]*a^(2*Phi(xi)):
u[1] := diff(u[0], xi):
d[1] := C[1]*a^Phi(xi)*T*ln(a)+2*C[2]*a^(2*Phi(xi))*T*ln(a):
u[2] := diff(d[1], xi):
d[2] := C[1]*a^Phi(xi)*T*ln(a)*(p*a^(-Phi(xi))+q+r*a^Phi(xi))
        +C[1]*a^Phi(xi)*(-p*a^(-Phi(xi))*T*ln(a)+r*a^Phi(xi)*T*ln(a))
        +4*C[2]*a^(2*Phi(xi))*T*ln(a)*(p*a^(-Phi(xi))+q+r*a^Phi(xi))
        +2*C[2]*a^(2*Phi(xi))*(-p*a^(-Phi(xi))*T*ln(a)+r*a^Phi(xi)*T*ln(a)):
expr := expand((2*k*k)*w*beta*d[2]-(2*alpha*k*k)*d[1]-2*w*u[0]+k*u[0]*u[0]):

thaw(collect(subs(a^Phi(xi)=freeze(a^Phi(xi)), expr),
             [freeze(a^Phi(xi))], simplify@factor));

And, if you would like terms like  (a^Phi(xi))^4  to become  a^(4*Phi(xi)) ,

combine(%, power);

collectexample.mw

Depending on your metric for measuring size of an expression there are a few alternatives that can reduce the size a bit more, eg. collection w.r.t. some additional names.

There is an old problem with Optimization and "operator form" where the internal construction of the gradient procedure gets confused and produces something which merely returns zero(es). (It's a problem in the automatic differentiation.)

Some aspects of that were fixed a while back, but your example looks like it may be running into a similar problem.  (...a zero gradient confuses the algorithm into thinking that first-order conditions have been satisfied.)

Here are three workarounds. The first and second use "expression form". The first delays premature evaluation of a call to TV, using dummy variables. The second uses a slightly modification of procedure TV that returns unevaluated when passed nonnumeric arguments. The third uses a manually constructed gradient procedure that itself does numeric differentiation (via fdiff), see this old Post.

Download dsol_param_Maximize.mw