I have just tried this for Maple 2015.2 on 64-bit Win7. The Manipulator:-Pan command works the same way from either the Plot toolbar, or the right-click context menu. Basically, I can move the graph in any direction, as per the Maple help

To pan the plot, right-click on the plot, and select Manipulator>Pan. Hold down the left mouse button and use the mouse to move the plot around. To scale the plot, perform the same steps, but select Manipulator>Scale.

Tip: You can also change the manipulator tool by clicking on the plot, and then selecting the appropriate tool from the plot toolbar:

So what exactly is going wrong???

fsolve() will provide a numeric solution for pretty much any equation, assuming one exists. So, for example, it will return the numeric solution of

fsolve( (x-2)^2=4*x-3 )

If one supplies fsolve() with a simple expression (ie no '=' sign), as in

fsolve( (x-2)^2 )

then fsolve() assumes that one wishes the solution (x-2)^2=0 - saves typing!

Obviously fsolve() can handle many different ways of defining the expression/values/permitted ranges - check out the fsolve/details help page

Acer (or I) could have computed the inverse function to get the angle from the distance without embedding it in a procedure. Eg in Acer's worksheet, the simple expression

fsolve(distancia-500, 0 .. opt[2][1])

will return the answer you want. For either/both of us, embedding the fsolve() commands within a procedure was a matter of convenience/ease of use/argumentChecking etc etc, - and in my case, getting both of the possible values.

fsolve() uses a variety of different methods, depending on the supplied problem: whether it is an equality problem, an inequality, single/multiple expressions, single or multivariable. I have no doubt that for an appropriate problem, it may well use what you call "a simple iterative solution using if"

Whilst you may have written a a solution method within Excel, I suspect that it will only work for a "small" class of problems - and it will not be as efficient as Excel's built-in 'Goal Seek' or 'Solver' commands. (From memory this functionality is only available in Excel if you have installed the optional Analysis and Solver ToolPaks)

I used essentially the same method as Acer to compute the distance function for a given launch angle - although I noted that any distance (other than maximum distance) can be achieved with two different launch angles, and I computed both angles. so the following refers to my own worksheet posted above (projProc3.mw). This should explain how the calculation is performed.

You understand that the command

plot( myProc, 0..Pi/2);

computes the distance travelled (computed by the procedure myProc() ) for any launch angle between 0 and Pi/2. You should note at this stage that this plot demonstrates that any distance can be achieved for two different launch angles

The optimization command

opt:= Optimization:-Maximize(myProc, 0..Pi/2);

returns the maximum distance which is attainable for launch angles between 0 and Pi/2. In fact it returns two quantitiies: the first is the maximum distance and the second is the launch angle at which the maximum distance is achieved. The latter is referred to as 'angMax' in what follows

Consider now the expression

fsolve(myProc-d, 0..angMax)

In general, fsolve() returns the roots (or zeros) of the supplied function (myProc-d), for values of the variable in the supplied range (0..angMax), so you should interpret the above command as

1. myProc will return the achieved distance, for any angle in the range 0..angMax
2. 'd' is the desired distance
3. so fsolve (myProc-d, 0..angMax) will return the angle where myProc returns the desired distance (because at this value myProc-d will be zero)

In other words the above command can be interpreted as

fsolve( function_which_returns_distance - desired_distance=0,  0..angMax).

As noted earlier, there are two angles for each desired_distance, one in the the range 0..angMax, and one in the range angMax..Pi/2. The procedure angFromD I used in the above worksheet returns both, just by changing the range argument in the fsolve() command.

Acer's suggestion about using the y(t)=0 event to stop the ODE numerical solution process is *brilliant*, and allows all the subsequent calculations to be performed much more easily.

I made this change to my previous code, and now everything works properly - even the Optimization[Maximize] step which was returning nonsense before, for reasons I still do not undertand.

I also added a procedure to return both possible angles for a given distance - see the attached

projProc3.mw

I haven't utilised the parameters=theta option in the dsolve command, although I accept that this would improve efficiency

I wouldn't get hung up on the UseHardwareFloats() call - I found that I didn't have to play with this. The purpose of setting this is to control whether routines in the Optimization package use 'software' floats (Maple default, more accurate, but a bit slower) or 'hardware' floats (less accurate but probably bit faster). You should note that setting UseHardwareFloats(true) may be overridden if the value of Digits is high. See the help page at

?Efficient Computation in the Optimization Package

################################################

Answers to a few other questions, you have asked

1 I would like to know how do you go down without clicking enter while you are typing a code, i think it's shift + enter, but im not sure.

Yes it is Shift+Enter

2. why are you typing local t before work with a t value?

When using procedures it is a good idea to localise the variables being used  so that they only exist within the procedure. Without a local statement in the procedure body, Maple will look at the level from which the procedure was called to see if it is defined there. If it is, then that value will be used If it doesn't, then you will get a warning that a variable is implicitly being considered as 'local' to the procedure.  Check the appropriate section on the ?Procedures help page

3. To replace the parameters value why i need to put ':-word'?, maybe indicating that "word" belongs to yprueba?

Preceding a name within a procedure with the ':-' symbol, essentially means get the global instance, even if there is a local instance of the same name within the procedure. See the help at ?The :- Operator

4. If i want to declare more than a single parameter, i have to type:  parameters=[theta,a,b,c] on sol, when declaring desolve, for example? 

Yes - see the help at ?Interactive features of numeric ODE/DAE solutions

5. And for last, what is Hardware Floats?

Suggest you read the help at ?Numeric Computation in Maple. A floating point number in Maple is generally a software float (which iis what allows arbitrary precision - think lots and lots of digits). It is possibel to use hardware floats (the same kind of floating point representation which would be used by a "normal" programming language, such as C# etc. Using hardware floats can speed up some calculations

Try the attached

plotPhasors.mw

@acer 

I rewrote a certain amount of the OP's code, mainly so that I could understand/follow it. Basically I wrote a procedure which, when given a launchAngle, would return the distance travelled. The ultimate intention was then to use the Optimization package to maximise the distance travelled (also I wasn't sure I could make the Optimization package work with the OP's original code (cos it was a little "untidy")

However when I attempted to use the Optimization package, it produced *obviously* incorrect results, and I could not figure out why - the only part of the attached worksheet which "fails" (so far as I can tell), is the Optimization:-Maximize() call.

If I supply the angle (0.4722555220) you obtained above, then my procedure returns the same distance as you obtained - so why can't the Optimization:-Maximize() execution group find it: and why does it return an obviously nonsensical answer??? After all this is a *convex* problem and should be simple for any optimiser.

To make things worse you didn't even restrict the "launch angle" in any way - you could have launched to the left (angle = -Pi..0), downwards (angle=[-Pi..-2*Pi]), or multiples of angle to the right (eg angle=[2*Pi,,5*Pi/2]) and yet still the correct answer "appeared"

I'd be really grateful if you could look at the attached and tell me what I got wrong - cos I can't figure it out

projProc2.mw

When you use dsolve/numeric, Maple does not perform any calculations: all it does is return a set of procedures which allow you to perform subsequent calculations.

It is up to you to determine how to use these procedures in any subsequent calculation.

A possible alternative is to add equations to the ODE system to create a DAE system, so that further quantities of interest may be calculated.

It probably won't help much but I have attached a "proceduralized" version of the calculation so far. This just accept launch angle (and optionally initial velocity) and returns distance. It is a bit tidier than your original

projProc.mw

Probably because there is a difference between the equation you supply, ie

exp(B*x)*w''+A*w=0

and the equation

exp(B*x)*(diff(w(x),x,x)+A*w(x))=0

The latter will return the answer you seem to expect - the former will not.

Try running the following (and think!)

restart;
deqn1:= exp(B*x)*diff(w(x),x,x)+A*w(x)=0;
sol:=dsolve(deqn1);
limit(rhs(sol), B = 0);

restart;
deqn2:= exp(B*x)*(diff(w(x),x,x)+A*w(x))=0;
sol:=dsolve(deqn2);
limit(rhs(sol), B = 0);

Can't work out what you want

1. If you want 'distancia' for a given value of theta then distancia(Pi/4) will work - obviously you can choose any argument (other than Pi/4)

2. If you just want to return the matrix being plotted, without actually displaying the plot, then you could just use

   pdata1:= plottools[getdata](plot(distancia, 0 .. (1/2)*Pi))[3];

When you say

"i need to express that matrix from the plot data like a procedure to finally call it like a numeric function"

Well to call it like a numercial function, then you need an expression of the form

returnValue:=function( argument(s) )

So what are the argument(s) and what is the expected returnValues?

Try

Explore(plots[arrow](Vector([cos(delta), sin(delta)])), delta=-Pi..Pi);

It is not clear to me which "table" you want.

If you just want the data which Maple is using to produce the plot of 'distancia' against 'theta', then the simplest way is probably just to query the plot structure. Since Maple's plotting algorithms are adaptive, this data will not be equally-spaced

If you actually want to specify the range/spacing of theta-values, and force equal spacing then you can use a seq() command

Both options are illustrated in the attached worksheet - obviously you only need one of them

proyectil-1Corr.mw

Since the starting equations were so obviously incorrect, I did not read your new worksheet past this point.

You seem to believe that acceleration in the x-direction ie diff(x(t),t,t,) will depend on velocity in the y-direction ie diff(y(t),t) - NO - Physically impossible!

Similarly you seem to believe that acceleration in the y-direction ie diff(y(t),t,t,) will depend on velocity in the x-direction ie diff(x(t),t) - Equally, NO!

I suggest you check the Wikipedia page

https://en.wikipedia.org/wiki/Trajectory_of_a_projectile

and scroll down to the section titled

Trajectory of a projectile with air resistance

#######################################################

The basic equations for projectile motion which I posted in my original worksheet, ie

dsys :=  m*(diff(x(t), t, t)) = -k*diff(x(t), t),
             m*(diff(y(t), t, t)) = -m*g-k*diff(y(t), t)

are correct for the case where the drag is considered to linearly dependent on the projectile's velocity. As the Wikipedia article states, this assumption generally allows analytic solutions to be calculated for all quantities of interest. The Wikipedia article shows how to calculate most of these (as does my original worksheet)

If you want to consider the case where the drag is assumed to depend on the square of the velocity, then the starting equations should be

dsys :=  m*(diff(x(t), t, t)) = -k*diff(x(t), t)^2,
             m*(diff(y(t), t, t)) = -m*g-k*diff(y(t), t)^2

In general these can only be solved numerically.

And if you want to be really, really accurate, then you should probably be using equations with both linear and quadratic drag terms, as in

dsys :=  m*(diff(x(t), t, t)) = -k₁*diff(x(t), t)-k₂*diff(x(t), t)^2,
             m*(diff(y(t), t, t)) = -m*g--k₁*diff(y(t), t)-k₂*diff(y(t), t)^2

So the first thing you need to do is decide on the equations you want to solve!

The reason that the Optimization package does not wotk with complex numbers is for the simple reason that the concepts of "less than" or "greater than" simply do do exist for complex numbers. For example, is the complex number 3+4*I less than or greater than the complex number 5+0*I (or 0+5*I for that matter)???

For the concepts of "less than" or "greater than" to be vaguely applicable to complex numbers, then you need to be considering one of the following

1. magnitude of a complex number
2. phase of a complex number
3. real part of a complex number
4. imaginary part of a complex number

Note that all of the above are "reals"

Once you decide what you mean by the concept of greaterThan/lessThan for complex numbers, then your problem can probably be appropriately reformulted to provide the solutin which want

If you want to use the inbuilt solver, as in

pdsolve({PDE[111], PDE[222], PDE[333]}, {bcs}, numeric)

then you will get an error, because PDE[333] uses the variable 'omega' which is undefined - so you will have to fix that as well

You cannot enter Mathematica commands and syntax into Maple and expect them to be interpreted/parsed/executed correctly. This make about as much sense as writing a program in BASIC and expecting it to compile in C++

Different software has different syntax, different inbuilt commands etc etc

Now if you have have  a standard Mathematica mma file, then you *might* be ablel to import/translate it to Maple syntax using the Maple command MmaTranslator[FromMmaNotebook], although I wouldn't bet on it. Such translators usually only work well whe the source (in your case the Mathematica code) has been written in a very clear well-defined way. Since your Mathematica code seems to be pretty sloppy (although maybe functional), I suspect that this translation will probably fail.