@mapleatha That's not what I wrote!

I deliberately did not suggest what you just tried, as that would certainly insert floats for the tickmark values (and not the symbolic rational multiples of Pi/2).

Please try what I actually suggested ,(which inserts the symbolic multiples in at least as far back as Maple 16).

@ogunmiloro I have now tagged your Question as being for Maple 18 (six major releases ago, released in the year 2014), as I did previously for your earlier questions.

Has not the version of your Maple been an issue for code suggested in some previous query by you? Is there some reason why you cannot tag your Questions with your version details when you post them?

@nm You might look at the Explore command, eg.

Explore(plot(sin(a*x),x=-2*Pi..2*Pi),
        a=0.0..1.0,initialvalues=[a=0.4]):

That will embed an interactive application within the current Worksheet or Document.

If you'd prefer a popup application (but with only a unimodal operation) then you could look at the Maplets package.

@MapleEnthusiast I have not forgotten your followup refinement, but I just haven't had free time to consider it properly, sorry. I will try and find some spare moments. These are tricky times.

@Carl Love This question has arisen a few times: How to get the effect of a smooth curve (ie. adequate number of points, preferably using default adaptive plotting) and only a modest number of symbols overlaid.

The option style=pointline ties the number of symbols to the generated data points, unfortunately. Hence these solutions to forcibly overlay two "plots" -- one for the curve with adaptive plotting and one for the symbols at a modest number of points without adaptive plotting.

It might be useful for it to be automatically available, so that people don't have to figure out the overlaid scheme as suggested. Also, the forced overlay results in additional data in the constructed plot structure, and that might make external export of the data more fiddly.

Perhaps this kind of thing would be a better (and more commonly desired) result from the style=pointline option itself? Is the current behaviour really more desirable? If so could it benefit from some option modification so as to specify the number of rendered symbols separately from the specification of the number of curve data points? And how about requesting their spacing evenly by arclength rather than by value of the independent parameter? Comments?

@nm I have sent you messages (though this forum) about splitting and duplicating topics. Your email server is rejecting them as spam. I get the bounced email session transcript.

Put your very close followup queries (eg. about disabling this typesetting effect in your LaTeX export) here, instead of in a separate Question.

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