@Anthrazit Could you provide examples of the "unit conversions and a lot of other stuff" that the Units:-Standard package allows but the Units:-Simple package does not?

@Mac Dude This is often done like,

    indets(A, And(name,Not(constant)))

so that names like Pi are omitted.

@Anthrazit The questions you appear to now be asking now are not directly related to the original problem.

The original problem was with producing distinct instances (alternatively, snapshot copies) of AddVector each time through the loop -- so that they could be separately put into results as distinct Vectors. The original problem was not in evaluation of entries in x a Vector of aVectorList (or lack of it). If you understand that now, great.

The questions you're posing now relate more to examples like the following. (These are not like you original, in which the entries of the Vectors of aVectorList were all just numbers.)

Download rtableeval.mw

So, in your original problem you could also implement a solution using map(eval,AddVector) or instead of copy(AddVector), since both of those happen to produce a distinct new Vector. But as I mentioned in a followup comment, I don't think that either of those is a best approach here.

@Anthrazit In none of these examples (your first, and all mine) do the entries of AddVector retain any connection to the original entries of the Vectors in aVectorList.

Even if you changed any entry of either Vector in aVectorList inplace, after-the-fact, it still would not affect the entries of the Vectors in results.

One easy way to explain that here is because the Vectors in aVectorList are of length/dimension 2, while those in results are of length 4. They simply cannot be the same structure. (Here, this is also true at any length. But here it helps us realize it.)

When entries of a Vector are accessed individually they get evaluated. You get the scalar value, not a reference to it. Your original problem was not due to references to the entries of any Vector in aVectorList, or any way of accessing those.

As I mentioned before, your original problem was not related to mutability, per se. It was more due to using name AddVector as a reference to the same Vector each time through the loop. That re-uses the same Vector each time through the loop, which does not help you get distinct Vector structures into results.

By the way, another way to fix your original example is to augment the results by
   copy(AddVector)
instead. But that method only works properly because you happen to act on all the same entry positions each time through the loop. To be safe, in general, you'd also want to zero out all entries of AddVector, each time through the loop, say using ArrayTools:-Fill. Otherwise AddVector could be dirty with some stale, prior values, and in consequence so might be the copy. I did not mention this way earlier because it is unnecessarily more complicated, and has no special merit.

Download Mutable_acc.mw

@mmcdara This is relatively poor solution, since it incurs additional and unnecessary floating-point roundoff error (and loss of accuracy in the result) for some ranges of exponent.

@Ronan Yes, there are some other cases. Some of those relate to whether bounds are supplied (in the form of inequalities). That can sometimes make a problem more difficult.

The are also a few oddball (but thankfully, relatively rare) cases in which passing the real option can help. The real option is documented as being for polynomial problems, including with parameters present. But, curiously, I've seen rare non-polynomial (& non-trig) examples where passing it can help. Yet I've also seen some other non-polynomial examples where passing it hinders success.

If you walk through Calculus1:-Roots you can see that it tries a variety of tricks, including multiple calls to solve, both with and without various options, to try and squeeze out as much as it can. It also attempts to verify exact roots via resubstituition -- though that can sometimes be quite expensive.

As you suggest, it's a broad topic. It's also quite difficult in general. And even some "short" examples can be difficult.

Concatenation produces instances of the global names.

restart;
proc() local xy:=4;
       assign(cat(x,y)=7);
       xy;
end proc();

             4

xy;

             7

So even if you had all your Sij declared local then you still wouldn't be able normally to reference them via concatenation. (You'd be referencing the globals.)

So likely either your code is actually referencing the globals (later), or you already have that many explicit statements (which usually takes as much effort to produce as that many local declarations).

I am suspicious of your claim that the rest of the code is not useful for us -- with the implication that representative code of how these names get subsequently used is not germane to your Question.

ps. There are tools for programmatically constructing (and deconstructing) procedures. You could use these to programmatically (re)generate the procedure with the desired locals declared. But such a contrived solution should not be made without clearly justifying the need.

Please don't submit another duplicate of this query, in a separate Question thread.

@mahasafy You have to first obtain the GeM package. I am guessing that you mean the package at this GeM site.

Have you done that yet?

Is it a .mpl file or a .mla file?

Let's suppose that you download it as a file on this folder on your machine. (Change this, if the location on your machine is different!)

If it is file named GeM.mpl file, put this as a command at the start of your worksheet.

   read "C:/Users/mhasafy/GeM.mpl":

If it is a file named GeM.mla, put this as a command at the start of your worksheet.

   libname := "C:/Users/mhasafy/GeM.mla", libname:

Then run the rest of your commands, starting with,

  with(GeM);

@ You claim that, "If cos(i) isn't imaginary, then i•sin(i) must be."

That is not true.

The values of those two quantities are shown in my Answer. Both are purely real.

You should be able to find many derivations of those in a web search, for explanation or separate confirmation if you need it.

@rcorless There have been a few prior reports of the Animation toolbar not appearing in some people's Maple 2021.1 GUI.

@mmcdara In my opinion this is not a very good solution. It only happens to work because on the order in which the product is being stored (after uniquification) in memory.

It is fragile, because it can be broken by any intermediate creation of the (new) product with the undesired lexical ordering.

Download fragile_1.mw

It can also be broken by any subsequent reordering of the product (DAG). This matters because (rather horribly) the typeset facility only stores the expression and does not prevent further evaluation.

Download fragile_1a.mw

In a similar vein, the OP's original can be (magically) made to work by a fortuitous interjection. But this even more weak and fragile because the typeset syntax does not prevent subsequent evaluation -- here stripping off the uneval quotes and wrecking the label.

Download fragile_2.mw

I don't think that either of these should be particulalrly recommended, since neither are generally robust.

Since you are obviously having trouble with provided answers because your version is quite old, why don't you bother to tell us explicitly which version you are using?!

Please explain what you mean by providing your example explicitly.

If you mean that you want to compute the area between the envelope curve and the x-axis then please state that.

You wrote that your example is too complicated to solve. That might mean that it is too complicated to be handled purely symbolically, but it's difficult to tell what you mean without seeing it.

You can upload and attach a worksheet using the green up-arrow in the Mapleprimes editor.

Upload a worksheet that contains the definition of f.

That may show us whether f is evalhf'able or compilable. It might even be that performance of individual computations of f(x,y) could be improved.