FWIW, repeating the call Test(), or simply calling Coordinates(X, quiet) twice in succession inside Test produces the correct result. I have no idea why. This is not meant to be an adequate solution to your problem, nor have I marked it as an Answer. I'm merely putting it out there as another clue to the solution.

By setting printlevel to a high level (I used 99), you can see that thousands upon thousands of different things happen (like setting global variables) when Physics is loaded, whether from within the procedure or through with at the top level. Perhaps one of those things happens differently.

@tomleslie What you say doesn't apply to the "Kernel connection has been lost" error (which should be called the "kernel has crashed" error because that's what's happened in the vast, vast majority of cases that you get this message).

Regarding your first point: My experience with this error is that it's usually caused by doing things that are allowed by the documentation but are too complicated by being too heavily nested, too recursive, too many variables, etc.

Regarding your second point: This error can't be trapped. The kernel process has died, and only the interface process (and possibly kernels associated with other worksheets) remain alive.

That being said, and having read all the code that Adam has posted, I'd say that his code tends towards things being too heavily nested.

The set of functions R^[a,b] (i.e., the functions from interval [a,b] to the reals) is uncountable, so surely there can be no universal decision algorithm to decide which of them are integrable (and, the definition of "integrable" must be stated, as there are several competing definitions). This is not even addressing the issue of parameters, which vastly complicate the problem.

So,

1. Please give two examples of the type of functions that you actually care about: one which is integrable and one which isn't
2. Please state the type of integrability that you're using (Lebesgue, etc.)
3. Please define "dimension" as you used it in the phrase "parameters (like dimension)".

@vv

Thanks for posting this compilable code.

I see that you used type(n,even). Surely the types that one can use with the highly symbolic type command are extremely limited in compiled Maple. Are those allowed types listed somewhere?

I see that you worked around the negativity problem that I had with endogenous frac by adding 5 to the result before doing frac. It tooked me several minutes to figure out how you worked around the problem, so that deserves a comment.

So, I guess that it's not currently allowed that one compiled procedure call another compiled procedure?

@Annonymouse Actually I ended up not needing to use the last of those four assumptions because your conditions are equivalent to every equation either being vacuous or having somewhere an "h name". It doesn't matter which side or whether it's isolated.

@Carl Love The code in the Answer above has been vastly simplified. The functionality is identical to what it was before. I just made use of the facts that

remove(s-> ormap(not F(s), ...), ...)

is equivalent to

select(s-> andmap(F(s), ...), ...),

and

indets(e, t) <> {}

is equivalent to

hastype(e,t).

@Christopher2222 

I think that you may be making the mistake of thinking that

remove(s-> true in F(s))

and

remove(s-> false in F(s))

(for any function F that returns a set of booleans) are opposites or complements. They aren't because the sets in general contain both true and false. The complement of remove(...) is select(...).

From the examples, I guess that I can make the following assumptions about the relevant hs:

• that they are always lowercase (h rather than H)
• that they are always the last character of the main stem of the name (the part of the name before any index or subscript)
• that subscripting, when used, is always of the form A[B] rather than A__B
• that the left side of every equation is simply a name, as would be the case if these equations were returned by solve.

If I can make these assumptions, it will simplify the code. If these assumptions are not valid, a solution is still possible.

@Adam Ledger Yes, the PSLQ algorithm, which is used to derive the summation formulas, is pretty deep.

@Adam Ledger I don't yet understand it either, and I'm not embarrassed to admit it.

Do not put off learning complex analysis just because you haven't yet mastered real analysis. Complex "makes more sense" overall. It has far fewer pathological counter-examples than does real analysis.

I often bemoan the fact that complex numbers are totally excluded from elementary calculus education. This leads to the abominations int(1/x, x) = ln(abs(x)) (rather than just ln(x)) and the Maclaurin series for arctan has radius of convergence 1 even though arctan has derivatives of all orders for all real numbers.

@vv Yes, the unstated pedagogical point of this Question is to develop custom quadrature rules to handle classes of integrands with specific types of singularities by using weight functions. Student:-NumericalAnalysis:-Quadrature(..., method= gaussian...) doesn't look for singularities. As is shown even in elementary calculus classes, applying standard quadrature rules to Int(sqrt(x), x= 0..1) gives poor results due to the derivative going infinite at x= 0.

@Mariusz Iwaniuk As I mentioned above, this behavior is explained on the help page ?evalf,sum. Since there's an option to override the behavior (formal= false), it must be by design. I guess it's an open question whether it's a bad design.

@Adam Ledger The code above is much simpler than many things that you've posted! What don't you understand? I'll explain it. I know that you're interested in number theory. If so, you need to understand the ModExp algorithm from the above code because it's a fundamental algorithm of computational number theory.

Isogenies of elliptic curves over finite fields is directly implemented in SageMath (a free and open-source alternative to Maple). See the Wikipedia article SageMath. That's not to say that someone hasn't implemented it in Maple; I'm just not aware of it if they have.

@tomleslie I have no doubt that the problem is the implied multiplication, as you guessed.