This regression in behavior is a bug, I think. (I will submit a report.) It is a problematic change in one aspect of the behavior of the Histogram command.

Here is a very simple solution to handle your example, requiring only a wrapping call to plots:-display.

with(Statistics):
X := RandomVariable(Normal(1, 2)):
w := Sample(X, 1000):
plots:-display(Histogram(w), legend = "data set 1");

Below I edit the Histogram procedure's parameter/option specification, to get the original legend functionality back, to cover this example more directly.

If the following works for you then you might consider temporarily adding the redefinition part to an initialization file. That would allow you to utilize Histogram directly and straightforwardly, as in Maple 2021, etc.

Download Histogram_legend_M2022.0_ac.mw

One kludgie approach is to use either the `caption` or `title` option instead of `legend`, but that doesn't automatically get the colored rectangle. It also doesn't merge properly if you display a few of them together. So IMO this is an inferior alternative for the behaviour you want. But the behavior you want is fully reasonable.

Are you allowed a wider range than your specified lw..up = 0.01..10 ?

After correcting the syntax problems with multiplication that Preben mentioned, I go the following.

Notice that these solutions all seem to be permutations involving the same numeric values -- with some entries lying outside your specified range 0.01..10 .

Download eqs_sys_iso.mw

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.