Are you sure that you aren't missing something that's given in the original source of this problem? I can't imagine how this integral could turn up in any practical problem. You might as well integrate cos from -infinity to infinity: Clearly there is an uninteresting oscillatory divergence.                                           

I don't understand why there is an index-out-of-bounds error. On a quick read through of your code, I spotted the obvious mod bug, so I corrected that, which fixed the whole problem, so I just left it at that.

The index error doesn't occur if the code is run in native Maple.

You can access the C code by doing (in Maple), before compiling:

infolevel[Compiler]:= 3:

This will show you the name of the text file containing the C code. You can add some debugging print statements to this code and rerun it if you want. Personally, I'm happy with the proviso "Use irem instead of mod in compiled Maple code."

@pchin Is it possible for a user to simply turn off the Typesetting Rule that produces this error?

This situation that error messages may come from the Typesetting Rules opens up a whole new level of complexity in debugging Maple code. Since the errors can be avoided by simply suppressing the output (and then using lprint), this will often be satisfactory to the user. But it is difficult for the user to know at first that the error is coming from the Rule rather than their code! Here are two ideas to address this:

1. These error messages could be distinguished from regular error message by being prefixed with the word TYPESETTING.

2. The invocation of a Typesetting Rule could be wrapped like this:

try 
   whatever 
catch:
   if interface('typesetting') = 'extended' then
      interface('typesetting'= 'standard');
      userinfo(
         1, Typesetting, 
         "Typesetting (extended) error detected; resorting to Standard Typesetting."
      );
      whatever;
      interface('typesetting'= 'extended')
   else
      error
   end if
end try;

It is not necessary to have procedures in individual text files in order to do version control. I personally find that unwieldy (too many files). I like one file per module. The way that my brain works in comprehending computer code, I find that about 500 lines per text file is ideal. My ideal maximum size for a procedure is what will fit on a single screen using whatever editor/monitor combination that I'm using. I often have a lengthy comment (10 - 20 lines) at the beginning of a procedure. I don't require that this comment fit on the same screen as the procedure.

Edit: I removed my remark that Git supports syntactic colouring for Maple. I was conflating it with vi and its derivatives, which do have the colouring.

@Kitonum Thanks for the correction.

@Markiyan Hirnyk No, poles alone don't imply the divergence of an integral, of course. But in my experience poles in multi-dimension integrals almost always confound the numerical integration routines. Consider this relatively simple case:

evalf(Int(1/(x^2+y^2)^(1/4), [x= -1..1, y= -1..1]));

When will you no longer be a "Maple newbie"? You've been a member of MaplePrimes for nearly five years (indeed, 86 days longer than I've been a member), and you've been a regular contributor for over three years. You have a reputation of 1340, which places you at #30 on the all-time list of highest-reputation members.

There are numerous points where the denominator is zero.

@John Fredsted Thanks. It's a reconciliation of the dichotomous nature of Boolean logic with the trichotomous nature of total ordering. The third case, a[k] = b[k], is the unstated else clause of the if statement, which forces either comparison of the next pair (if there is a next pair) or comparison of the list (or Vector) lengths (if there's no next pair).

@magiblot 

To answer your first question "How does the computation change....": If you don't specify an initial point, the algorithm uses some method to guess at an initial point, or perhaps just picks one at random. But there must be an initial point for the iteration whether you supply it or not.

To answer you second question "Would any point....": No, not necessarily. The relationship between the initial point and point which is converged upon can be extremely complex, even for simple polynomial objective functions. For any given extremum, the set of initial points for which the algorithm converges to that extremum is called the extremum's basin of attraction (for that algorithm). These basins can be fractals of unimaginable intricacy and complexity, in which case they're called strange attractors. There are Wikipedia articles on both of these italicized terms.

But given an extremum, there is some open set containing that extremum that is a subset of its basin of attraction. Were it not so, there'd be no practical value in having an initial point option. In other words, if you start close enough to the extremum, then you'll find it. There's no a priori way of knowing how close "close enough" is.

@magiblot Yes, you may solve for the corner points directly rather than considering those as separate Lagrange multiplier problems. This is certainly the way to go if you're solving these problems by hand. If you're using Maple, I have a technique, which I'll post shortly, which does the interior and all the Lagrange multiplier problems for all the boundaries, in all dimensions (including the 0D corner points), with a single solve command.

@Earl I'm not sure if this is relevant, but is there any significant difference between the edges of the Catalan surface and the Mobius strip, which you called single-edged? The edges are topologically homeomorphic, although the surfaces are not.

Indeed, it is true that solve ignores real assumptions, even if you use option useassumptions. This is mentioned in the help. Usually it is better to formulate assumptions as inequalities and include them in the set of equations passed to solve. I don't see how that can help in this case. 

@mj1751 Using the paper, you need to change F[k+1]:= solve(eq) to F[k+1]:= solve(F[k+1] = eq).

@mj1751 Looking at the paper's equation now, I see that you've entered it incorrectly. Try entering it the way that it appears in the paper; do not attempt to manually solve it for F[k+1]. I don't have time right now, but I'll get back to it in about 3 - 4 hours.