@Markiyan Hirnyk 

But as I said, I know I could add an assumption and do it:

(I can handle this with assumptions, but this is just an example).

And this is how I do it now allready.

As I said, this was just an example. Suppose I do not want to use assumptions and use some specific value at some later point? The above case can show up in different location and different cases. You might argue that this is too much of a contrived example and will not come up in practice, and you could be right. But it came with with me now when I was trying to solve with Laplace and did not work, and then tried to do subs after the fact.

@acer 

I do not like solution that require manual mouse/click/menu actions. I want programmable solution, so I can write the code once and run it and not have to keeping clinking and pulling menus each time. Thanks any way, this was just something I noticed. I do not think I'll be using Bodeplot much any more in Maple. I just wanted to try it. It has many other problems and I'll get tired just to try to enumerate them. So I think I will stop here and go on to something else.

@acer 

In this example you have forced one part of the size to 300, but then complain that the aspect ratio is not right.

I changed one size and used default for the other  size=[300,"default"]?

So that the other dimension will automatically change keeping the same aspect ratio.  At least that is what thought should happen. You used default also for one size yourself here:  size=[default,0.7]

In Mathematica, there is an option called AspectRatio that one can adjust themselves. I am simply asking if there is such an option in Maple plots and graphics. How does one even query what aspect ratio is used by a plot in Maple? In Mathematica one can query the aspect ratio used and changed it if needed.

@Carl Love 

Thanks. Is this documented anywhere? I spend maybe  30 minutes looking at examples, and none of them even mentioned the exports(sys) and how to read these fields inside.

Very few examples to help one how to use it.

to get better help you should post complete code in plain text that one can copy and run to see the issue.

Putting a link to a page where one has to search the page and cut and paste pieces of code just to try to stitch togother something that might look like what you have as an image is not the right way to get help.

@Carl Love 

What makes you "sure" that there is a "special case" solution to this? Have you actually ever seen a Maple plot with a correctly placed stacked legend?

As I said, I am newbie in Maple. I just said this assuming there could be another special "patch" fix for this or some option somewhere hidden in some function. My point is that again, there is no common data structure and a way of viewing things that works the same for all cases, packages and functions as the case with Mathematica. That is all what I meant.  This is not just for legened, but for many other things I find in Maple. It seems maple was put togother as collection of different packages each does things its own way, instead of building things all using the same common design and way of doing things.

@Carl Love 

thanks, but I am finding Maple to be not consistent in many of the things it does. I am documenting many of these inconsistencies as I learn it. I have few pages filled so far.

What if one wants to have the lgened below the x-axis as before, but be stacked up as well? Trying your solution with location "bottom" does not work. With Mathematica, I found it to be much more streamlined in how it handles all these issues. With Maple it seems to be different way to do something in different cases with no overall theme or process that one can follow, and different packages seem to do things differently.  No single overall design seems to exist. But Maple is really good in differential equations, so may be it all balances out at the end.

Here is an example of inconsistent behaviour, or at least, an unexpected.  Plotting the same thing, with legend on the right vs. legend as default (bottom) gives different size plot. It seems the legend size is counted as part of the plot itself. This is not what one normally would expect.

restart:
alias(DS=DynamicSystems):
sys := DS:-TransferFunction(1/(s^2+0.2*s+1)):
p1:=DS:-ResponsePlot(sys, sin(t),duration=25,color=black,legend="response"):
p2:=plot(sin(t),t=0..25,color=red,legend="input",size=[300,200]):
plots:-display([p2,p1],axes=boxed, title="step and impulse reponses",legendstyle= [location=right]);

Now using

plots:-display([p2,p1],axes=boxed, title="step and impulse reponses",legendstyle= [location=bottom]);

I am sure there is another special case solution for this. I tried putting an explicit size on the first plot to fix the plot size, but it seems legened size is an issue. So different, special case, solution is needed again.

@Carl Love 

a follow up: Is there a way using this method to arrange the legends to be on top of each others (column wise) instead of next to each others as is now? In normal use of legend(), one can use Array() I think to change the arrangement, but how would one do it in this case?

thanks

you should show the exact code you typed.  You could not have typed "for t<10 and 0 for t>10" since this is not valid Maple code.  ALso you need to use := for assignment, not "="

@liushunyi 

If you want an expression sequence vs. a list, then do

r:=map(i->coeff(p,x,i),[seq(i,i=0..n)]);
op(r)

whattype(%);

      exprseq

The 3 main basic data types in Maple are list (thing with []) and set (thing with {}) and expression sequence.

@Joe Riel 

thanks, it worked. This should be the default actually. I hope someone at Maplesoft changes this for version 19 to make it so.

fyi, the example I showed above, now looks like this. I did not expect this result:

_LatexSmallFractionConstant := 0:
latex(diff(y(x), x)+y(x)*cos(x)-(1/2)*sin(2*x) = 0);

{\frac {\rm d}{{\rm d}x}}y \left( x \right) +y \left( x \right) \cos
 \left( x \right) -{\frac {\sin \left( 2\,x \right) }{2}}=0

What I really wanted is this:

Which is produced by this latex:

{\frac {\rm d}{{\rm d}x}}y \left( x \right) +y \left( x \right) \cos
 \left( x \right) -\frac{1}{2} \,\sin \left( 2\,x \right) =0

i.e. simply changing 1/2 to \frac{1}{2}. But as you can see, Maple did not do this in this case. i.e. when 1/2 is inside a more complex expression, it decided to do something else.

Well., still better than before, but not the correct way to do it.

@ecterrab 

"And the option useInt is an option of dsolve, not odetest"

You are correct, sorry, my mistake. I was reading about useInt in the help for odetest, that is why.

But then odetest() has an options parsing problem? If it had given me an error about invalid option, I would have realized right away that I was using this option on the wrong Maple command.

Why does it not check that the options it is given are valid? All these calls below produce no error about an invalid option supplied: (the setup is as given in my initial post above). Should not a Maple command first check the arguments its is passed are valid before processing the call?

odetest(sol1,ode1,useInt);
odetest(sol1,ode1,implicit);
odetest(sol1,ode1,"why odetest accept anything here??");
odetest(sol1,ode1,1,2,3,4,4,5,6,7,8,9);
odetest(sol1,ode1,seriesXXXXXXXXXXXXX);
odetest(sol1,ode1,seriesXXXXXXXXXXXXX,zzzzzzz,yyyyyyy);

all of these produce the same result as

odetest(sol1,ode1);

thank you

@ecterrab 

I did not try the Int option on all of them, I was tired and by random tried it on one or two. Those happened to be the ones that did not work. Same for implicit. Then I gave up and just ran odetest() on all as is.

The problem is that as user, it is hard to just keep trying things like this. The steps you show above are not something a normal new user (student for example) would know how to do unless they have lots of experience with Maple.

It will be nice if Maple can automate internally all these steps. For example, odetest() can have an option, "try_all=true" and let odetest() internally try useInt and if that does not work, try implicit or any other option there is. I found by trial and error that using implicit option worked even if the solution was not implicit in y(x). Having "try_all=true" will make this function easier to use. Most of the time, the user just want to know if the solution satisfies the ode or not, they really do not care at that moment at least, what method Maple uses to obtain this result.

This is btw, similar to user getting ODESolStruct as solution from an ODE. The steps to go from ODESolStruct to construct an actual solution are not easy and complicated. Adding more examples in the help will also be useful.

Similarly, it will also be useful if this can also be automated and so a user can just ask Maple to give a final solution without them having to do so many other manual steps and trial and error to get a final solution, which requires lots of Maple skills to do as well. But this might be much harder to automate than having odetest() try useInt and try implicit automatically.

Thanks again for your help. This was very useful. As a student, I find Maple DSolve to be very good and very fast as well.

@ecterrab 

I installed DEsAndMathematicalFunctions18-5.4 and it now returns 0 from the odetest.

I assumed since odetest() did not return zero, then a solution could not be found and so ODESOlStruc was similar to DESol which is returned when no solution is found.

I need to study more about ODESOlStruc.

Thank you

@Alejandro Jakubi 

thanks. now it worked.