You can wrap the result from seq in square brackets, in order to make a list from the sequence of numbers.

  L := [seq(a(n), n = 1 .. 100)];
  plots:-listplot(L);
 

Do you mean like this?

seq([seq([a[i,j],b[(j-1)*3+i]],i=1..3)], j=1..3);

   [[a[1, 1], b[1]], [a[2, 1], b[2]], [a[3, 1], b[3]]],

   [[a[1, 2], b[4]], [a[2, 2], b[5]], [a[3, 2], b[6]]],

   [[a[1, 3], b[7]], [a[2, 3], b[8]], [a[3, 3], b[9]]]

Or, if with slightly different bracketing,

seq(seq([a[i,j],b[(j-1)*3+i]],i=1..3), j=1..3);

   [a[1, 1], b[1]], [a[2, 1], b[2]], [a[3, 1], b[3]],
   [a[1, 2], b[4]], [a[2, 2], b[5]], [a[3, 2], b[6]],
   [a[1, 3], b[7]], [a[2, 3], b[8]], [a[3, 3], b[9]]

This runs in Maple 18.02 (since your Questions are usually restricted to that old version).

Download collect_exp2_18.mw

In the above code the term
   exp(-I*(-Omega*t+k*x+z*k[1]))
is deliberately kept as you gave it, ie. not turned into
   exp(I*(Omega*t-k*x-z*k[1]))
or
   1/exp(I*(-Omega*t+k*x+z*k[1]))

And similarly for the other exp call.

Also, a term like
   exp(-I*(-Omega*t+k*x+z*k[1]))^2
is deliberately kept as is, and not turned into
   exp(-2*I*(-Omega*t+k*x+z*k[1]))

You have not informed us as to which variables are to be considered as purely real. So I am guessing that all the indeterminates can be taken as purely real. You originally omitted similar information in another of your recent Questions. This is not helpful.

You asked why your loop approach cannot be replaced with seq.

So I will show you how your seq attempt can be easily adjusted to work, using the prefix form of `+=`.

Using your N, V, and sumidx,

roll:=rand(1..9):
N := sort([seq(seq(10*(2+jdx)+roll(),jdx=1..5),idx=1..10)]):
V := 10*seq(roll()+10*trunc(N[idx]/10),idx=1..nops(N)):
sumidx := [seq(floor(N[idx]/10)-2,idx=1..nops(N))];

You can now proceed with,

S := 0 *~convert(convert(trunc~(N/10),set),list):
seq(`+=`(S[ sumidx[idx] ],V[idx]), idx=1..nops(N)):
S;

     [3420, 4570, 5480, 6620, 7320]

which agrees with your loop approach,

S := 0 *~convert(convert(trunc~(N/10),set),list):
for idx to nops(sumidx) do
    S[ sumidx[idx] ] += V[idx]:
end do:
S;

     [3420, 4570, 5480, 6620, 7320]

A slightly wider pair of ranges for the parameters (along with a restricted vertical view) can help avoid the impression that the two surfaces are equal along a certain direction.

You can also play around with the stylistic effects.

plot3d([exp(t^2+10*u-1), -121+22*t+10*u, [[11, -12, 1]]],
       t=8..12, u=-15..-6, view=-50..50,
       color=[grey,green,red], style=[patch,surface,point],
       symbol=solidcircle, symbolsize=10,
       lightmodel=Light2, transparency=[0.4,0.0,0.0]);

It can get tricky finding a decent view, since a wider range (ie. larger t) alongside the restricted view can cause the GUI's plot render to fail to show one of the surfaces.

Here is one way to avoid calls to TF from happening (prematurely), ie. unless its arguments are not all of type realcons.

Download Min_ex.mw

Here are some ideas, which you should be able to adjust.

I find that for animations of compound plots it's useful to create a procedure (below, F) which can be used to quickly generate and test each frame -- calling it with only a value for the animating parameter. Eg,  F(0.5) etc.

Then you can more quickly adjust that procedure, as needed.

And then the call to plots:-animate is very simple as a last step.

Download plotting_anim_textplot.mw

You are accidentally passing a sequence of scalar expressions to the simplify command, since that is what dsolve is returning.

You could correct that by wrapping those results from dsolve in a list, eg.

   simplify([dsolve(DE, explicit)]);

When you pass such a sequence of arguments to simplify then some of the arguments are taken as being options to the simplify command. But your goal appears to be simplification of all that dsolve returns (which could be a sequence of multiple solutions). So you could pass them all within a list or set.

Here's one way, using your operators assigned to f1 and f2.

f1:=x->a*x^2:
f2:=x->a*x^2+1:

Explore(plot(eval([f1(x),f2(x)],a=A),
             x=-1 .. 1, y = -3 .. 3),
        parameters = [[A = -1.0 .. 1.0, label=a]]);

It'd be easier (as Kitonum has already shown) if you simply used expressions for f1 and f2, instead of operators. That also works with assigned names f1 and f2.

f1:=a*x^2:
f2:=a*x^2+1:

Explore(plot([f1,f2],
             x=-1 .. 1, y = -3 .. 3),
        a = -1.0 .. 1.0);

Are x, t, and lambda known to be purely real?

It might be reasonably taken that the other names lambda1, epsilon1, and epsilon2 are not purely real, because they were entered stand-alone in calls to conjugate. It seems weird that you'd enter those if you didn't intend it so. If this is true then using only evalc (without further assumptions on these other names) is not appropriate.

The following also works in Maple 18.02.

restart;
alias(phi = phi(x, t), chi = chi(x, t), psi = psi(x, t), rho = rho(x, t)):

A := -phi*(2*epsilon1*conjugate(epsilon1)*psi*conjugate(epsilon2)*conjugate(phi)*epsilon2*conjugate(psi)+epsilon1^2*conjugate(epsilon1)^2*psi*conjugate(phi)*conjugate(psi)+chi*conjugate(epsilon2)*epsilon2*conjugate(psi)*conjugate(rho)+epsilon1*rho*conjugate(epsilon1)*conjugate(phi)*conjugate(rho)+epsilon2^2*psi*conjugate(epsilon2)^2*conjugate(phi)*conjugate(psi))*lambda1-conjugate(lambda1)*conjugate(chi)*(epsilon2*psi*rho*conjugate(epsilon2)*conjugate(phi)+chi*conjugate(epsilon1)*psi*epsilon1*conjugate(psi)+chi*rho*conjugate(rho)):

expr := subs({chi = exp((I*lambda*(1/2))*x-I*t/lambda),
              phi = exp(-(I*lambda*(1/2))*x+I*t/lambda),
              psi = exp(-(I*lambda*(1/2))*x-I*t/lambda),
              rho = exp((I*lambda*(1/2))*x+I*t/lambda)}, A):

simplify(expand(expr), size) assuming lambda::real, t::real, x::real;

    -(epsilon1*conjugate(epsilon1) + epsilon2*conjugate(epsilon2) + 1)
    *(lambda1*epsilon1*conjugate(epsilon1)
      + lambda1*conjugate(epsilon2)*epsilon2
      + conjugate(lambda1));

Slightly shorter and lighter is,

   factor(expand(expr)) assuming lambda::real, t::real, x::real;

You could also follow that up with,

   map(simplify,%);

to get the products of the form name*conjugate(name) turned into abs(name)^2. Or you could issue convert(%,abs) as a last step using the code above.

Download vector_eval.mw

One alternative is to try and compute it numerically.

I get PathInt to return the inert integral directly, then try to compute that numerically. I do that in two ways. The first way just splits into real and imaginary components, and loosens the target accuracy.

Download some_path_int0.mw

The second way does it in steps, manually splitting the domain. I did it partly because I got once got some conflicting results when trying more straightforwardly, and I wanted to double-check.

I split the domain into piecewise continuous parts, then integrate the real and complex parts of the integrand separately (with a forced choice of numeric method) over each of those parts. I utilize the periodicity to keep t small (in the first Pi period) which seems to help numerically. Once the domain is split, this approach seems to allow quick and successful computation with a finer accuracy tolerance than I was able to take in my first approach.

Download some_path_int.mw

With luck I didn't mess it all up.

The only slow bit was the call to discont. (I didn't try fiddling with fdiscont.) But that only has to be determined once, after which that domain splitting and the periodicity allow arbitrary integration ranges to be handled quickly.

Here are two ways.

The goal itself seems dubious. If you want the body of procedure b to not depend on the changing nature of procedure a then why construct b in that that way? (Also, why do you have to use procedures instead of expressions, at all?)

Download proc_s.mw

If you have total control over the initial construction of procedure a then you could also do the first variant as follows:

Download proc_inline.mw

It's possible that this is only a toy example, and that you may have some more involved example for which you cannot sucessfully utilize the unapply approach because the nature of procedure b doesn't allow you to properly call it with an unassigned name like x as its argument.

If you have more restrictions, etc, then it would be better to show us.

If the procedures a and b are completely constructed by you (and not the return values of some computations) then using expressions instead of procedures seems so much more straightforward and usual.

Yes, that's one of the main points about "loading" a package using the with command. It rebinds the names of its exports.

You can still access the original "global" name by using the colon-dash syntax in your own entered/parsed code. For example,

Download pkg_rebinding.mw

Note that instances of the name Gcd in procedures already (before the rebinding) saved in a .mla archives are not affected -- they were saved with the original name, whose value you have not reassigned. So merely loading the package doesn't change the value of the instances of the these global names inside the procedures of, say, stock Maple commands.

ps. I changed your query from a Post into a Question.

Is this the kind of this you're after?

I ran this in Maple 16.02, but perhaps you are running Maple 12?

The 3D plot seems to show that (for any value of Zstub in its given range) the maximal value of Gamma is attained at one of the end-points: either f=f1 or f=f2. And you seem to want to find the Zproc that minimizes that maximum. That seems to occur at Zstub=Z[N]. But, even so, you may still wish to compute that via the nested optimization, as opposed to merely observing where it occurs on the 3D plot.

Download transformer_with_short_(Primes)_ac.mw