@Lenny The PlotComponent has a property named mouseMode, which you can set using SetProperty.

But mouseMode is not part of the plot structure generated by any plotting command, and accordingly the plotting commands offer no such option.

And so, the mouse probe business is part of the PlotComponent, not the generated plot structure.

In contrast, the axis mode is part of the plot structure, and can be specified using the axis option, and cannot be set using SetProperty (because it does not correspond to any property of the PlotComponent).

@MapleEnthusiast Please don't split it off as a separate Question thread. Instead, please just add any additional considerations or explanation to this thread.

@MapleEnthusiast Notice that the call to solve used produced a result containing:

   dlogR[3, 1] = dlogR[3, 1]

 The call to solve that produced that specified the variables as all three of the dlogR[k,1] names, k=1,2,3,

   solve(simplify({eq1, eq2, eq3}, Constraints), {dlogR[1, 1], dlogR[2, 1], dlogR[3, 1]})

As you've noticed, the variable dlogR[3, 1] is free and unconstrained, in that solution.

The same result would have attained if it were instead called as,

   solve(simplify({eq1, eq2, eq3}, Constraints), {dlogR[1, 1], dlogR[2, 1]})

with just the "first two" of those (ordered in a set, lexicographically) variables specified.

You could also compute these:
   solve(simplify({eq1, eq2, eq3}, Constraints), {dlogR[1, 1], dlogR[3, 1]})
   solve(simplify({eq1, eq2, eq3}, Constraints), {dlogR[3, 1], dlogR[2, 1]})
with the excluded dlogR[k,1] variable being free (the solution of the other two being dependent upon it).

Is that the kind of thing that you mean?

@mmcdara 

Inside the procedure body¹ the code fragment on the right of the double-colon (ie., the type) gets evaluated before the type-check.

And [nonnegint$3] evaluates to [nonnegint, nonnegint, nonnegint]. As a structured type, the latter means a list of three elements, each of which is of type nonnegint.

So the syntax not [n,x,y]::[nonnegint$3] means the boolean negation of the type-check whether the list [n,x,y] is a list of three nonnegative integers.

1) In contrast, inside the declaration of a procedure's parameters the right-side of the double-colon is not evaluated. As a pseudocode example,

 F := proc( M::Matrix(square) )
    if M::'Matrix'(datatype=float[8]) then
       ...
    end if;
 end proc:

The right side of the double-colon within the procedure body requires the uneval quotes, or else the call to the Matrix command would be undesirably evaluated. But inside the procedure's parameter specification the Matrix should not be so quoted.

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).