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

Your method of generating a sequence of data points, and then interpolating that, and then plotting the interpolant, is very inferior to the direct method shown below.

I have deleted at least one duplicate posting of yours, in which you asked about the same inferior method for a very similar examples.

(You have asked duplicates of some other of your query topics, as well. Stop spamming this site with duplicates.)

@AHSAN It is impolite to expect other people to have to type in your equations for you.

@Carl Love No worries, Carl. I assume that we always have purely constructive discourse!

I had assigned the results from GenerateMatrix to A,b two names, then concatenated before calling Modular:-LineasrSolve. Six of one, half a dozen of the other...

I'm glad you took the high road and showed your answer. Upvote. The OP's use of deprecated lowercase matrix, evalm, etc, made me a little sad.

@Carl Love I wasn't sure what the instructor was up to, on that point.

At first I had code using each of Linsolve(...) mod p, LinearAlgebra:-Modular, and even msolve, but figured that using just solve might give the OP something more to think about.

Your Document was last saved in Maple 18, and not Maple 2018 which is four major releases later. I have adjusted the Question header accordingly.

@Carl Love I had only a sneaking suspicion about the "possibility" of speedup. Yes, I was wondering about simplification (once all the exp and arithmetic had been combined on the real&imag parts, split by evalc, code optimized, etc). I was just wondering... 

More hazily, I wasn't outright sure whether I might also save on arithmetic by avoiding extra care for corner cases (reciprocals, etc). Maybe a poor idea. I was just wondering... 

But nothing concrete.

And I was also trying to recollect details of the platform-specifc complex arithmetic bug(s) I'd seen years earlier -- though I didn't mention it earlier because I was trying to, umm, keep it simple.

@Yiannis Galidakis I wrote that "expmap4.mw" worksheet early in the year 2016, for Maple 2015. I didn't write it for Maple 18 (established by the fact that it uses the newer IterativeMaps package).

Here is an adjustment of the first part (just the plot3d), which runs faster in my Maple 18.02 due to explicit use of evalhf which I have added for you.   expmap4_part1_18.02.mw