You might notice that the following direct use of plots:-odeplot (with mode=log for axis[1]) undersamples and renders a coarser curve in the lower range, as compared with plots:-semilogplot. I can't tell whether that's an issue for you since you haven't bother to provide your full example.

Download ode_semilog.mw

Are you looking for this distinction, which is documented on the Help page for arctan?

Download arctan.mw

You don't need the Embedded Plot Component in order to simply plot them all together, with the plots being rendered at the cursor's current output location.

For that all you need is,
    plots:-display(plotlist);
or, within a procedure call that returns something else,
    print(plots:-display(plotlist));

Here are those two ideas: pdisp.mw

In contrast to the above, a Embedded Plot Component allows you to set a fixed location in your document. That way, you can replace with other plots later on, programatically, and they will all appear in the same location as earlier, not matter how many times you repeat. You could also do that whenever some procedure of yours gets called. The key thing is that the plots are rendered in the same location, overwriting what was there before. This can also help save space, so that your worksheet doesn't get cluttered or scroll as much.

If you have some other usage scenario then it would be best if you could describe it precisely. (I can think of some other scenarios, but guessing can be inefficient.)

Your problem was not in evaluating the entries of x (ie. each Vector in your aVectorList). It was due to not accounting for AddVector being reused each time through the loop.

[edit] I gave a 1-liner alternative below, using seq. (Other alternatives are possible, using map[2], etc, including the one Carl has subsequently provided in his Answer.) Since a terse one-off replacement doesn't provide insight into what went wrong for you originally, I wrote all the rest with the hope of explaining by example.

Download Mutable_ac.mw

restart;
kernelopts(version);

   Maple 2021.1, X86 64 LINUX, May 19 2021, Build ID 1539851

Ftarg := 1/2+signum(x-mu)/(2*GAMMA(1/beta))
             *(GAMMA(1/beta)-GAMMA(1/beta, abs((x-mu)/sigma)^beta)):

f := beta/(2*sigma*GAMMA(1/beta))*exp(-(abs(x-mu)/sigma)^beta):

conds := x::real, mu::real, beta > 0, sigma > 0:

simplify( diff(Ftarg, x) - f ) assuming Or(x>mu, x<mu), conds;

                       0

In some older versions such as Maple 2015 you could split that into separate integrations for x>mu and x<mu.

For input it is exp(...) not e^(...).

The name "e" has no special value in Maple.

The typeset output displays as a bold, upright Roman e^(...) and that is what often confuses people.

restart;                                                                           

uu := (x, y, t) -> exp(.2*t)*(exp(-x)+exp(-y)):                                    

uu(.1, .1, .1);                                                                    

              1.846232693

You could also type the letters exp and then press the Esc key and so use command-completion, in order to get a nicely typeset input like that bold, upright e^....

You could also use the appropriate entry from the Expressions palette., although personally I find that more awkward since your hand has to switch back and forth between keyboard and pointer.

At the top right corner of each Question/Post/Answer you should be able to see a Thumbs-Up icon and a Star icon.

The Star icon is for marking something as one of your favorites. When marked it appears in blue, when unmarked it appears in grey.

Put the Library file (.mla filename extension) in a location that is in the path as specified by libname.

And so one possibility is to put it in a location of your choice, and then to augment libname with that location. 

You could read Answers to several previous, related Questions. Eg. here and here.

A Vector is properly a mutable structure, ie. its entries can be changed in-place.

In consequence, different Vectors are distinct structures, even if they just happen to have the same entries. So a set of such are not reduced by merely apparent duplicates (ie. Vectors having the same entries).

In contrast, lists are not properly mutable; two lists having the same entries point to the same uniquified structure in memory. So a set of equal lists gets duplicates removed.

note: There is some purportedly user-friendly functionality that lets you change a list's entries as if it were acting in-place. But the result is a new and distinct structure, so this is actually faking in-place action.

Download DuplicateEntries_ac.mw

Download SC1Roots.mw

I submitted a bug against solve about three weeks ago -- that it was missing solutions -- in a very similar case (trig, bounded above and below). I will submit this new example.

Someone else mentioned that applying expand worked for this example. For some other examples applying combine works (but not for this example). Another possibility here is to split the domain.

{solve([f, t >= 0, t <= Pi], allsolutions, explicit)}
union
{solve([f, t >= Pi, t <= 2*Pi], allsolutions, explicit)};

  /                                /    1   \    /    2   \   
 { {t = 0}, {t = Pi}, {t = 2 Pi}, { t = - Pi }, { t = - Pi }, 
  \                                \    3   /    \    3   /   

    /    4   \    /    5   \ \ 
   { t = - Pi }, { t = - Pi } }
    \    3   /    \    3   / / 

For any of these workarounds one can find similar examples for which it fails while some others succeed.

None of these workarounds seems as robust as Calculus1:-Roots, for some restricted flavour of problem.

That should be
   with(GeM):
instead of,
   With(GeM):
as you showed it.

If that's not your problem then you should upload and attach you worksheet.

Download label_ts.mw

I don't mind having to force the desired ordering of the terms in the product. But it would be much better if typeset were not so weak (ie. if it were to do the full job of typesetting to a form that were not fragile w.r.t. subsequent reordering or evaluation). It's not very user-friendly, to have to go to so much effort to produce a more robust result.

You asked why it happens. It happens because that's of how convert(..,string) is handling it, using the %a format.

You might prefer to force the %g format instead.

sprintf("%g",0.12);

              "0.12"

As for your convert call, it does this:

sprintf("%a",0.12);

              ".12"

> trace(sprintf):
> convert(0.12,string);
{--> enter sprintf, args = "%a", .12
              ".12"

<-- exit sprintf (now in `convert/string`) = ".12"}
              ".12"

What do you think about the following?

Download eu.mw

If I understand what you're after then this seems to accomplish that last simplification, and also gets the earlier rational part in another manner.

maxcharheight_ac.mw

[edit] I will submit a bug report against simplify, for the following:

ee := exp(2*ln(1/2 - sqrt(5))*sqrt(5)):

simplify(ee); # hmm

   exp(2*(-ln(2)+ln(-1+2*5^(1/2))+I*Pi)*5^(1/2))

simplify(expand(ee));

    (1/2-5^(1/2))^(2*5^(1/2))

simplify(ee,exp);

    (1/2-5^(1/2))^(2*5^(1/2))