If a sub-procedure A is defined inside another procedure B, and procedure B is called in a performance-critical inner loop, will the Maple interpreter read the definition of A again every time procedure B is called? I'm wondering if I should just avoid nested procedures, as how you would write programs in C, as opposed to Pascal which allows nested procedures.

In Maple 2019.2, I'm trying to compute series expansions. For the input
series(1/z^4/(1-z), z=0, 1);
Maple gives me a series of the expression around z=0, truncated to 1 term, i.e.
z^(-4) + O(z^(-3))

But with the input
series(1/z^4/(1-z), z=0, 2);
Maple gives me the result
z^(-4) + z^(-3) + z^(-2) + z^(-1) + 1 + z + O(z^2)

Apparently Maple has decided not to give a series with 2 terms, but a series up to O(z^2). I'm surprised that the third argument of "series" is not treated in a consistent manner. I've restarted the Maple server between the two computations, so it's not a memory effect.

In the above example, this is just a minor annoyance, but I'm actually dealing with huge expressions, and for performance reasons it's important to truncate the series expansion at the desired order and stop further computations. Has anyone encountered this problem?

In Maple 2019, I'm using the "applyrule" function to write a simple routine for contracting vector indices, following the Einstein summation convention (repeated indices are summed).

Input:

applyrule(
  vec(a::symbol, i::symbol) * vec(b::symbol, i::symbol) = dotproduct(a,b),
  vec(a,k) * vec(b,k)
);

Output:

dotproduct(a, b)

So far it works as expected. Now I add an "uncontracted" vector, and the code seems to become unpredictable. First, let me show a case in which the code still works:

Input:

applyrule(
  vec(a::symbol, i::symbol) * vec(b::symbol, i::symbol) = dotproduct(a,b),
  vec(u,k) * vec(u,i) * vec(c,k)
);

Output:

dotproduct(c, u)*vec(u, i)

As expected, contraction has been done on the repeated index "k", but vec(u,i) was left alone. However, the above code fails if I simply change the variable name "u" to "a":

Input:

applyrule(
  vec(a::symbol, i::symbol) * vec(b::symbol, i::symbol) = dotproduct(a,b),
  vec(a,k) * vec(a,i) * vec(c,k)
);

Output:

vec(a, k)*vec(a, i)*vec(c, k)

Apparently, the rule was not applied because I used "a:symbol" in the transformation rule. But I thought "a::symbol" should be considered a wildcard that represents any symbol, including "a" itself?

Depending on the exact input, this bug sometimes shows up, sometimes not, but the above examples are verified to be reproducible. A simple workaround is always avoiding the use of the same variable, but this seems to be hack. Is there a proper solution?