If you are asking a homework question then you could first check recent Questions with the homework tag.

The day before you asked this Question I answered a very similar Question about Newton's method for homework, where the Asker was also confused about procedures versus expression form. (I showed both ways, as Carl has done here.)

It works for me in Maple 2020.0 (and Maple 2019.2, at least) but not in Maple 2020.1.

I have submitted a bug report.

@vv I suspect that he meant that the format of a .m file is not legible when viewed as text, outside of Maple.

@nm I wonder whether the OP cares that the two forms are not equal for all possible real values of the variables.

As examples,
  [ L__1=-1, L__2=1, L__2p=1, L__m=1 ]
  [ L__1=1, L__2=-1, L__2p=-1, L__m=1 ]

@Carl Love I changed those two instances to plain text (black on white, no foreground or background color), after you made your Reply mentioning it.

@Carl Love Yes, thank you for stating the clarification; that was my intended meaning.

I don't see this done often, but some additional protection against inadvertant clashing with an assigned global instance of a concatenated name can be attained by forming an escaped local. (I'm primarily thinking about your mention of getting display effects using concatenated names, rather than as variables for computation.)

restart;

`This is a long name.`:=3:

v:=`tools/gensym`(cat(`This is `,`a long name.`)):

v;
        This is a long name.

`This is a long name.`;                                                            
                3

assign(v,7):
v;
                7

eval(v,1);
        This is a long name.

`tools/gensym`(cat(`This is `,`a long name.`));
        This is a long name.

%;
        This is a long name.

@ecterrab You appear to have misinterpreted some of my points.

I did not state or suggest in any way that you are the fellow who removes (or is likely to remove) usefulness. I am asking that you don't remove the functionality to pull out the multiplicative term. In no way can such a request be fairly interpreted as a claim or accusation of what you are likely to do.

Also, my main point was not about compatibility. My first and main point was that if `simplify` were adjusted to turn an inert `Int` into a constant (where applicable) then there ought to be also some way to forcibly, programatically prevent that. As you mentioned, there are situations where keeping inert integrals intact is useful and desirable.

I don't think that whoever believes differently from me must be wrong. I don't think that's a fair suggestion -- whether in quotation marks or not.

@ecterrab The idea that a call to the simplify command might return the value of an inert Int call (even if only when the value is found to be any constant) is generally suboptimal, unless there is a way to forcibly prevent it while calling simplify. Such a behavioural change would prevent several important kinds of symbolic manipulation that relies on inert integrals remaining present for programmatic purpose.

Such a change would break code of mine that is designed around the current behavior. Benefits mentioned so far (eg. you prefer it, etc) do not merit introducing an otherwise unnecessary code incompatibility.

I am aware that there are already a few cases where inert Int may already be simplified to some constant. I don't propose changing the following (which does not require using the value or equivalent):

simplify(Int(f(x),x=a..a));

        0

As an additional side note -- if you are looking into somehow merging the simplify code that handles Int and %int, please do not remove usefulness. I often utilize the behavior illustrated in the first example below,

restart;
simplify(Int(4*f(x),x));

    4*Int(f(x),x)

restart;
simplify(%int(4*f(x),x));

    %int(4*f(x),x)

@vv Yes, I mentioned that to someone else just a few days ago.

That aspect doesn't affect the above, though, since the calls to (local) gamma procedure are evaluated and resolved when the double-Int is constructed.

I just threw in the top-level local declaration so that the OP's code could assign to the otherwise protected, global name.

@lemelinm Your Equation Label (4) had GeV only because it was set up to do so forcibly using Units Formatting of that Document Block's output. (View->Markers from menubar to see that).

The useunits option to the plot command doesn't convert between units. The units are stripped off, and then the useunits is used for the axis labels.

Here are two alternatives:
1) Utilize the UseUnits command to make GeV the default unit for the dimension shared with J (joules, the SI default).  Quark-Quark_interaction_ac1.mw

2) Convert the units, or introduce the appropriate scaling factor. (I also removed the Units-formatting of Equation Label (4), just to illustrate). Quark-Quark_interaction_ac2.mw

@a_simsim Ok, that is just a simple revision of what I already showed (ignoring the grouping by colour).

restart;

m:=LinearAlgebra:-RandomMatrix(7,2,generator=0.0..1.0):

P:=ComputationalGeometry:-VoronoiDiagram(m):
V:=[op(indets(P,specfunc(anything,POLYGONS)))]:

# A list of seven 2-column Matrices (first column contains
# x-values, and second column returns y-values).
Mlist := map[2](op,1,V);

# A list of seven listlists (lists of lists).
# Each listlist contains the points [x,y] in
# lists each of two elements.
map(convert,Mlist,listlist);

See the Export or ExportMatrix commands if you wish to export the Matrices to file(s).

@Carl Love I have too. But it's still much better to provide the actual Document. Otherwise it's more difficult to know whether the problem is specific to Maple 2017(.3), possibly one some platform, or typesetting level, etc.

It's possible that the cut&paste of the particular 2D Math to 1D Execution Group (or somewhere else), as an initial step, might be a workaround.

I'd like to see the specifics. It's not a guarantee, but surely it cannot be worse to have the actual problematic Document (possibly with precise details on actions to reproduce the problem).

It is not reasonable to expect the best diagnosis in the absence of your actual Document.

@Lenny You already had a mechanism by which the PlyTable1 data (Matrix) could be available to the procedure, eg. GetDet.

By this I mean that your original attachment already had a DataTable embedded component, whose associated "rtable" was the 2-by-1 Matrix PlyTable1.

Indeed, if I fill in a few values in that DataTable (say, 1.2 for first entry in the only column, and 1.3 in the second entry in the only column) then that Matrix is available from within the procedure (or outside it). And that data survives closing & reopening the Document.

Your original attachment did not work properly after wrapping the code in the proc...end proc as you mentioned (even with some PlyTable1 data entered in the DataTable, since the original attachment lacked such data) because of the reasons I explained in my Answer. You may have coinceidentally fixed/avoided the problem I described, by some other changes to your methodology.

Is this a homework question? If it is, then why not tell us how you think it should be done, and how you'd start going about accomplishing it?