I have added a couple of extra boundary conditions (launch angle and launch velocity) to your original problem , and inserted plausible numerical values for the various constants, You can try alternative values for the parameters, or set up differetn boundary conditions if you wish

The attached worksheet solves the problem, plots the trajectory, and computes the range, maximum height achieved and the flight time

projectile.mw

Setting Digits=50 in Maple 2015.1 produces

                                                     
[1, 1] = 1.5225020546182152261855196206979650376760893953048*10¹⁶ 
[1, 2] = -3.7467167447000268318131469586230331742508508317549*10¹⁵ 
[1, 3] = -1.5032864265474452623394233692730974191988408472354*10¹⁵ 
[2, 1] = -3.2103946461617960030511268014361120653823339891834*10¹⁵ 
[2, 2] = 7.0865787723587903718119898691970016025491237643485*10¹⁵ 
[2, 3] = 2.5427430830133274932738168597695610408390766252464*10¹⁵
[3, 1] = -1.2891876057433559257562017805423581044844891533956*10¹⁵ 
[3, 2] = 2.5427430830133274932738168597695610408390766252464*10¹⁵ 
[3, 3] = 2.6407833618943003869047623455952129523631794201951*10¹⁵+
             3.0282290358625112599882975867853992191658778348910*10^-10*omega²_{[1, 1]}



As Carl has aready indicated, changing Digits to 100, doesn't change the above much

I just ran this in Maple2016.1 and the output from your final execution group was

[1, 1] = 1224.800184
[1, 2] = -7294.842206
[1, 3] = -0.2044264751e45
[2, 1] = 0.3182902746e17
[2, 2] = -0.1783916829e58
[2, 3] = 0.6182861070e16
[3, 1] = 0.8919584142e57
[3, 2] = 0.6182861070e16
[3, 3] = -0.1782366737e58+0.1782366737e33*omega[1, 1]^2

No RootOf and no Float(undefined): so the obvious question is whihc Maple version are you running

Consider the equation provided by the OP

dy/dt = (-k/m) (y srqt(x^2 + y^2)) - g

I suppose we can assume that 'g' is the acceleration due to gravity, ie it is an acceleration. Hence the left-hand side of this equation must be an acceleration: hence 'y' must be a velocity. Really clear from the original post, isn't it!!??

For those who are interested in this problem, the actual position equations (x(t), horizontal and y(t), vertical) for a projectile of mass 'm' and drag coefficient 'k' are

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

Defining the above as a system of ODES, and applying dsolve(), as in

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)
         ];
dsolve(dsys);

willl generate a solution with (four, as expected) arbitrary constants. The solution can be reduced to one containig only two arbitrary constants by inserting the boundary conditions x(0)=0 and y(0)=0, as in

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),
           x(0)=0,
           y(0)=0
         ];
dsolve(dsys);

Beyond this point, a further two numeric boundary conditions will be necessary. OP suggest one further boundary condiion as "it's initial velocity on x is 3 times it's initial velocity on y ", whihc effectivel specifies the launch angle. However one further boundary condition will be necessary; eg the magnitude of the launch velocity>>>

Even given a fiuther boundary condition, values for 'm' and 'k' will be necessary in order to obtain complete numeric solutions.

@vv 

Memo to self - check output a little more carefully

Well, if you execute

eq:=5*lambda*tan(lambda)-1;
plot(eq, lambda=-100..100);

you will be able to see how many roots there are!

Student[Calculus1][Roots]( eq, 0..10);

will return all of the roots for lambda between 0 and 10

Whilst it is true that

"you cannot use the formal parameter as loop variable. Fix:"

the situation is "more general". Basically you cannot modify the value of a passed parameter within a Maple procedure., whether as a loop variable or anything else.

The simplest way round this (as ThU has indicated), is to create a local copy of the passed parameter, using

local i_local:=i_passed

and then manipulate the local parameter.

One of the tricky things about providing answers on this site is that responders have no way of determing the technical expertise of questioners. So basically I/we try to ensure that all of the simple stuff is covered first.

But since you are a self-declared technical expert, I have no doubt that you will be able to do what the rest of the world can do - namely work out what what is preventing you from uploading files to a desired destination

When you say

"I already know I can upload files in DropBox or in other cloud facilities"

You are avoiding the issue of who can download from them! If you are uploading to a "corporate" dropbox site, then you might find that only those with certain email addresses can download. Try uploading a test file to DropBox then asking your mother/neighbour/trusted_friend whether they can download.

In other words - how public is it?

If your mother has access - then the chances are that anyone on this site will also be able to access. So if you post the appropriate link then we will be able to access the necessary info. Clunky, but possible.

You should be aware that even trying this may violate your company security policy - so think about it before you try it!

I was surprised to see this - cos when I try it with Maple 2016.1 on 64-bit Win7 SP1 then plot attributes (like size on screen) seem to be remembered. (Ditto for Maple 2015.2 on the same OS)

Can only conclude this is a MAC-OS issue - which I can't check :-(

Your example illustrates the point I was trying to make.

1. You have a BVP, which (in the absence of the continuation parameter) fails to converge.
2. You use a continuation parameter so that Maple can produce an approximate solution, effectively by creating a "simpler" problem.
3. Maple then automatically iterates from this approximation to the exact solution.
4. There is a sense in which using a continuation parameter is a simpler(?) alternative to using the 'approxsoln' option.

Consider the case of a problem where basic physics perhaps does not include all the effects you wish to model, but for which the BVP is numerically solvable. Intuition would suggest that as you include more and more terms in your model, in order to get more detail/accuracy, then the solution of the BVP probably won't change too much - but you *might* experience convergence difficulties.

It then may be worth trying the solution of the simpler problem as an argument to the 'approxsoln' option for the more complicated problem.

In general, many numerical algorithms will perform much better if the user can provide a "reasonable" initial guess for the solution. The 'continuation' and 'approxsoln' options in dsolve/numeric are just a couple of ways of coming up with this initial "guess"

Since (as Joe has said it is almost impossible to understand what you are doing), I'm prepared to make a random guess. Becuase it is a guess, the rest of this post may be complete crap

*******************************************************************************************

The most common place I have seen the use of 'continuation' is with the numeric solution of differential equations, where the dsolve/numeric/bvp, accepts an option called 'continuation': and as the manual states

'continuation'= name
Argument that allows solution of a BVP via a continuous transformation from an easier problem to the desired problem. This method is used in obtaining an initial solution profile, and is most helpful for problems for which the Newton iteration for the initial solution approximation does not converge. The continuation option provides the name for the continuation parameter for the problem. The continuation problem must be constructed so that the parameter c, when varied from 0 to 1, defines a different BVP for each value of c, where c = 0 represents the simpler problem, and c = 1 represents the problem to be solved. The continuation parameter can be present in the differential equation, the values for the boundary conditions, or both. Two examples of the use of continuation for the solution of BVP problems can be found in dsolve[numeric_bvp,advanced].

For best results, the continuation problem should be constructed so that the BVP solutions vary continuously with the parameter, and so that the rate of change of the solution, with respect to the parameter, is very roughly constant over the range c = 0 .. 1.

So suppose (for example) you have a BVP which does not initially converge. Sometimes you can isolate a term in the BVP which is causing the problem. (My own favourite is just to pick the differential term with the highest order!) An obvious way to deal with this issue is to multiply the troublesome term by the continuation parameter 'c'. This means that a preliminary solution will be obtained with c=0 ( so the awkward term is zeroed out), and then Maple will try to iterate to the actual solution, by slowly increasing the value of 'c', using the previous solution as an initial estimate.

There are many variations on this theme of trying to obtain an approximtes solution and then slowly iterating towars the actual solution by using the continuation parameter. In your case of using (101-100λ), with λ the continuation parameter, theen an approximate solution woul first be obtained for λ=0, so the factor starts at 101, and slowly decreases to 1. This is almost the opposte case from that which I described in the previous paragraph. You have now selected a parameter which you widh to "dominate" to solution because it has an effective coefficient of '101' and as the coninuation parameter increases, will reduce to '1'. In physical (aka real world) terms I can see a justification for this approach: one wants to ensure that some theoretical term dominates all possible error correction terms, but that the latter eventually become comparable in magnitude to the theoretical solution.

In either of the two scenarios described above the use of the continuation parameter allows an "approximate" solution to be generated, and then modified to generate the actual solution

Some observations on this code (none of which are related to your original problem)

1. The cat() function returns a name, not an integer (see manual). The list B contains only integers (and leading zeros on elements will be discarded).
2. Thus every SearchAll() command will always return 0. (Because the name ij is different from the integer ij). Hence A will be given as 0 - 0 every time this statement is executed.
3. If one fixed (2) above [ say by using parse( cat() ] to convert to an integer, then each of the SearchAll() commands would return a sequence of indexes (see manual). It is not meaningful to subtract one sequence from another sequence (particularly when the two sequences might not even be the same length!). If OP knows that there can only be one occurrence, then (s)he should be using Search() rather than SearchAll()
4. The inner loop uses the index 'k' which does not occur anywhere within the loop. Thus the inner loop executes identical code numelems(K) times - and obviously produces the same answer each time
5. The inner loop contains the variable 'j' twice. This quantity is undefined. Might be a typo for k
6. Each loop iteration overwrites the previous value of 'A' so on exit from both loops 'A' will contain only the results of the last iteration - deliberate????

None of this illustrates how/why the OP managed to print the contents of A in a column???

the version shown in the attached. As Acer suggested, all of the '.' symbols need to be replaced with a multiply symbol - which will be a 'dot', but midline, rather than baseline. Use '*' when entering rather than '.'

This works (although the output is a bit lengthy!)

EgV.mw

Hmmmm

The output of your print command indicates that A does not seem to be a simple 1D table,  list,  set, Vector or array, because none of these would print in column fashion. Even a column vector would print with braces.

Yet the fact that the 'for i in A' actually does something, indicates that it is either a set or list. I think we need to know what the structure of A actually is!

Either post the code whcih generates A, or the results of

whattype(A);

or

op(A)

or I suppose you could just try

convert(A, list)

which (depending on what A actually is) just might do the conversion for you