@markweitzman In Maple 2019.2 it doesn't bother with ftoc or ftocms once it gets that result from the meijergspecial method.

In Maple 2020.1 the internal mechanisms have been adjusted, and it continues for your example and tries ftoc and gets the simpler result.

You can see evidence of some of this by issuing these commands:

restart;
kernelopts(version);
infolevel[int]:=4:
int(2*Pi*x*sqrt(1+x^(-4/3)/9), x=0..1);

As previously mentioned, you can force method=ftoc or method=ftocms and get the simpler result from Maple 2019.2 as well.

Does your computation require the Grid Toolbox, rather than just the Grid package that is stock in Maple 2020, in order to compute with parallelization on your local multicore machine?

@robertocooper I have deleted a duplicate of this very Question (which merely showed another attempt at programming it). Don't split the Question and topic like that.

You can put your followup code in a new Reply here, or augment the Question body above and add it there.

@tomleslie I suspect that the Question is about discovering the particular identities of all the instances existing within some Document, of a given type of Embedded Component.

I don't think that the OP is asking about valid terms for referring to types of Components.

@Carl Love That's a very good point, thanks. I was hung up on the italics issue, which is not nearly as important.

However, I feel that the mechanism of assigning something (anything) to the problematic names is handy, but not great. It's a workaround.

It would better if the Typesetting package offered a configuration option for this. It has several similar things for special-function calls, relational operators, etc. It seems natural to me that it could also offer control for the Greek letters.

@mmcdara I didn't suggest that you would remove the global declaration inside your procedures. But it's not necessary at the top level. That is all.

You have shown one possible edit to the code, to initialize G:=[] inside the outer procedure. Fine.

But it's not the only way to edit the original.

You could also have kept the G:=[] done at the top level just before calling `Main` (or `f` in your followup)  while deleting the problematic top level global declaration statement. That is the shortest edit to the original. [edit] I showed this very idea, with code, in my Answer.

There are also ways to access and assign to global G from within the procedures -- even if they don't have their own `global` declarations. But I'll leave those aside as they are not simpler.

As an aside, personally I think changing globals from with procs is generally inferior namespace management. A modern alternative is to have Main be an appliable module which stores its own module-local G and provides an accessing export for getting G's value from outside Main.

@mmcdara [response below edited, in light of latest reply by the OP.]

At the top level assignments and access to the global G are immediately available.

You have not shown a version of the procedure Main (or even a very simplified one), which illustrates the difficulty in running in Maple 2020 versus Maple 2015.

Can you show a simple example in which the top level statement
   global G;
is required in order for a Main procedure to function properly in your Maple 2015?

Is it possible that the code change to initially assign the empty list to G is needed for some other reason, unrelated to whether you explicitly declare global G at the top level in Maple 2015?

@mmcdara I don't understand where the proc(...) exists, that matches that end proc. It's not clear from your proto-code what is being done (as you aver) at the "top level".

You didn't attach a worksheet with code that reproduces the issue (as I suggested). That makes it more difficult to tell what your code actually does in Maple 2015.

The term top level usually refers to statements outside any procedure body (including any parent procedure).

Could you attach an example of a worksheet in which that syntax was used and explain what effect you think it had?

@Gillee I only shoved in that eval from habit (for the case where the operator were assigned to a name, so get around last-name-eval). But it's not necessary for the anonymous operator. This should serve also:

Grid:-Map(subs(rr=r,MM=M,k->LArip(k,rr,MM)),[$(1..r)])

There are other ways to handle the original issue; I just went for less editing.

I have not studied your algorithm, but it seems that it might benefit from memoization. For example, the following runs in about 14sec using n=8 on my machine (previously was 24sec).

Magma_GridMap_ac_memo.mw

You could check for correct results.

@mmcdara It is a historical idiosyncrasy that both COLOR and COLOUR have been used at different times within plotting routines. Both are protected names.

In general Maple documentation is supposed to use American rather than British/Canadian spellings for documentation. But it's unclear what the rules are for structural elements.

I try to rememeber to use both, as {COLOR,COLOUR} within my typechecks of plotting substructures, which matches either.

By the way, I voted up this posting.

I have edited my Answer. In particular please not that in Maple 2017.2 (and 2020.1, etc) the Histogram command accepts and makes use of the legend option.

I don't know how terse/flexible/powerful you need this code to be, as I don't know all the scenarios in which you might use it. I'm sure you realize that there are many degrees and ways to make it more or less flexible or general or easy to re-use.

You might find mildly interesting an older Post I made which uses a similar technique, for adding legends for 2D contours (in older versions, as Maple 2020 proper can do that now). There I used the same trick to add a LEGEND substructure based on the forcibly present _HOVERCONTENT substructure (which I utilized to grab the contour values more reliably than by recomputing from the CURVES data).

It's satisfying to build a useful and new plotting structure variant for which there is no immediate command.

@mmcdara You have read and interpreted it correctly.

Also, that's a usual feature of truefalse keyword options -- supplying only the name acts like supplying it as equal to true. That's documented [1, 2] under the procedural parameter-processing Help pages.

Could you attach a worksheet or otherwise show us the definitions of f and g?

Upload and attach a worksheet that constructs these and reproduces the problem.

It is possible that your two instances of P[psi] are actually different names (eg. created with different assumptions on them, or as different escaped locals, or through some other means, etc). But it's really only helpful if you provide the means for us to see and reproduce the issue.

How far have you gotten with this coursework?