@manon22lr Upload a worksheet that contains the full code that reproduces your problem.

Tell us which version of Maple and which version of DirectSearch you are using.

Tell us whether you are running any special initialization file for Maple.

In other words, please provide more detail.

There is no attachment.

@nm Yes, of course it is possible to utilize $ instead of seq, for a shorter version that is also re-usable for general Matrices. I have added such in my Answer.

I don't understand why Kitonum has phrased it as if the two methodologies are somehow exclusive -- they aren't.

It is not better to have to supply the number of columns as an second argument to the procedure, since picking it off for each call leads to more effort and typing. Just have the procedure do it. Eg,

   A->['A[..,i]'$i=1..op([1,2],A)];

which is two characters shorter than,

   A->[''A''[..,i]$i=1..op([1,2],A)];

which in turn is one character shorter than the form given previously using seq.

@zphaze You have made precisely the mathematical mistake that I suspected and mentioned earlier. You isolated the arctan and then applied tan to both sides.

That is an invalid solving methodology. It is invalid mathematically and logically. It can produce answers which are wrong -- and that's what happens of this example.

The result you expected is not a solution to the original equation.

A solver which disregards  LHS - RHS == 0 is poor (at best).

Short-cut paths to solutions of similar problems still need very tight characterization of methodology, no matter how convenient the functionality motivation might be.

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