@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?

How far have you gotten with this coursework?

@Spirithaunter I suspect that your actual example is something larger and more involved, whose full details you have unfortunately not yet shown us.

So I shall guess as to what kind of thing your are trying to accomplish. Sorry if I guess poorly.

restart;
A1 := Vector(8,i->1.0*i);
A2 := map(sin, A1);
M := <A1|A2>;
Mnew := Matrix(remove(t->is(t[2] < 0),convert(M,listlist)));
plot(Mnew);

#DocumentTools:-Tabulate(Mnew, widthmode=pixels, width=300):

DocumentTools:-Tabulate(<<"x"|"f(x)">,Mnew>,
                        fillcolor=((M,i,j)->`if`(i=1,"Orange","PeachPuff")),
                        widthmode=pixels, width=300):

I actually was thinking of DocumentTools:-Tabulate acting on just a Matrix, as I find a DataFrame unnecessarily awkward for this.

In Maple 2015.2 this command crashes the kernel:

   sort(Vector(0))

and that seems to be what happens in your example.

That command does not crash in Maple 2016.2 and Maple 2020.1, as far as I can see so far.

At ten characters  sort(<[]>)  is pretty short, but not a record.

@binbagsss  Here are equations that you provided. The first equation you stated in your Question. The rest you provided in one of your posts on stackoverflow. You can easily change them.

eq1 :=  Uo/(sqrt(Go*Ho)) = Fr:
eq2 := (rho*Go*Ho^2)/sigma = W:
eq3 := St = (To*Uo)/Ho:
eq4 := Ca = (mu*Uo)/sigma:
eq5 := mu/sqrt(rho*sigma*Ho) = Oh:

The following deals with mu/To*Ho which is one of your input examples. It is a "one-liner".

eval( mu/To*Ho, [eliminate({eq1,eq2,eq3,eq4},{Go,Ho,To,Uo})][1,1] );

                            Ca sigma
                            --------
                               St  

The following deals with Go*Ho/Uo^2 which is your other input example. It is done the same as the example above.

eval( Go*Ho/Uo^2, [eliminate({eq1,eq2,eq3,eq4}, {Go,Ho,To,Uo})][1,1] );
                               1 
                              ---
                                2
                              Fr 

The following adds the 5th equation to the example above, and shows that the answer is not unique.

eval( Go*Ho/Uo^2, [eliminate({eq1,eq2,eq3,eq4,eq5}, {Go,Ho,To,Uo})][1,1] );
                                 2
                             W Oh 
                             -----
                                2 
                              Ca  

The non-uniqueness of the answer is because of Maths, not because of Maple. When the input example has more than one answer (ie. more than one dimensionless representation) then only you can resolve the ambiguity. Only you could decide which equations should be used.

@Joel19 I assigned the result from ImportMatrix to the name M, and you have assigned it to name A.

But you didn't adjust other places in the code that used the name M. Those need agree with your earlier choice.