are pretty easy: couldn't find any complex ones. Not saying the latter don't exist, just that I couldn't find them over the search areas I tried.

See the attached

Download getRoots.mw

Plot is the "wrong way round" - surely more common to have the y-axis be the dependent variable, so a minor revision of the above

Download odeProb2.mw

@Kitonum 

The reason you have supplied an "extra" boundary condition is because you have not defined a value for the quantity 'C', Surely it would be better to assign 'C' a value, and only use the boundary conditions which the OP supplied, as in the attached

Download odeProb.mw

in the toolbar to post you worksheet here

@das1404 

As a general rule, one does not want to print the result of any calculation which happens in a procedure. One is only interested in the data which is returned, when the procedure is called.

Realistically, the 'printlevel' command is a kind of "poor person's debugger" - it will enable the printing of output which would normally be suppressed. It should not be used to produce "desired output" from a procedure. - that's what a 'return' statement is for.

Even fixing the above, I still think that your algorithm is unnecessarily complicated for what you are trying to achieve. However I have cleaned it up as much as I can.

The makeY() procedure now calculates a single 'frame' of the desired animation. I have also used the left/right symmetry on the upper 'arms' of the calculation - you don't have to calculate bot arms explicitly.

These 'frames' are called/displayed in a separate display() command to produce the desired animation. See the attached

A caveat - this was produced in current Maple - it *might* not work in Maple 7. I have no realsitic way to check this

Download doY.mws

@Carl Love 

OP has the first couple of statements in the 'for' loop defined as

for i from n-1 do
     k0=f(x, u[i])

Leaving aside (for the moment), that 'f' is undefined: since n is defined as 20 - where is u[19] defined??.

Now if the 'for' loop were

for i from 0 to n-1 do
     k0=f(x, u[i])

everything would be hunky-dory - assuming a defintion of f() is forthcoming

Try this simple extension od Acer's code

restart;
v := 1: L := 12:
PDE := (D[2, 2](u))(x, t) = v^2*(D[1, 1](u))(x, t):
BC := u(0, t) = 0,
           u(L, t) = 0:
IC := u(x, 0) = 3*exp(-(x-6)^2)-3*exp(-36),
         (D[2](u))(x, 0) = sin(x):
sol := pdsolve( PDE, {BC, IC},
                          numeric,
                          spacestep = 1/200,
                           timestep = 1/100
                       ):
sol:-plot(u(x,t), t=10, x=0..10);
#sol:-plot(u(x,t), t=10, x=0..10, size=[700,400]);  # bug
plots:-display
            ( sol:-plot
                      ( u(x,t),
                         t=10,
                         x=0..10
                      ),
                     size=[700,400]
           );
plots:-display
           (  [ seq
                 ( sol:-plot
                           ( u(x, t),
                              t = j,
                              x = 0 .. 10
                           ),
                    j = 1..10
                 )
              ],
              size = [700, 400],
              insequence = true
          )

in my earlier response

The only maple code you can run in a console window is a plaintext file (in Maple_Speak, this would be a .mpl file).

Forget any idea of running a .mw or .mws file in a console window - it is never going to happen

Generally speaking it is not too difficult to convert a .mw.mws file to .mpl format, although a decent text editor may be required. Once you create the .mpl file, then follow the instructions in my previous post.

If you don't know how to convert the .m/.mws file to .mpl, then I can only suggest that yu upload the former here, and sone kind soul may do it for you

Since Maple 7 was superseded sixteen years ago, and I no longer have access, you'd probably be better reading the help page, becasue  I have to guess

The obvious suggestions are either

1. omit the variable to be solved for, or
2. if you wish to supply the variable(s), then supply it/them as a list

see my notes below

@das1404 

" Maple 7 does not have the provision in the seq command to increment by floating point values"

No way I can verify this: Maple 7 was superseded in April 2002 - as in 16 years ago. I just don't have any Maple releases which are that old.

The attached does exactly the same as the original, except with integer values in the seq() command

Download morph2.mw

@Bosco Emmanuel 

See the wroksheet belo

Download toMat.mw

Use the above link to download/run it

if one changes 'floor' to trunc, as in

 restart;
  f:=x->1-2*(1/x-trunc(1/x))+1/x;
  x:=50100;
  A:=Array(0..20):
  for j from 1 to 100000 do
        tmp:= f(x);
        p:= trunc(evalf(tmp));
        A[p]:= A[p]+1;
        x:=tmp
  od:
  A;

The code I supplied

1. iterates the sequence x=f(x)
2. it generates the floor(), so for example, 3.1234567, will become 3
3. having generated the floor, the corresponding entry in the Array A will be incremented by 1, so for exmaple A[3} will become A[3]+1

The effect of this algorithm is that

A[0] containes the count for values in the range 0..1

A[1] containes the count for values in the range 1..2

and so on. As I explained before, the iteration sequence will return values in all ranges from 0..1, up to 16..17. Hence all entries in the array from A[0] to A[16] are non-zero

to generate a "block" matrix from a list of sub-matrices is with LinearAlgebra:-DiagonalMatrix(), as in the following "toy" example

with(LinearAlgebra):
A:= [seq( RandomMatrix(2,2), j=1..3)];
DiagonalMatrix(A);

The sub-matrices, don't evan have to be the same size - check the help for  DiagonalMatrix()

Before I do that I'd just like to thank Sergey Moiseev  for providing the DirectSearch package in the first place. Also for taking the time to comment on this thread

I learned a couple of things about DirectSearch while working on this problem

1. I was unaware that, that I could set Allsolutions=true and follow it with some kind of "sub-option" like solutions=1, or solutions=2. I don't think this sub-option is documented anywhere, but it is very useful
2. As I explained in my previous responses, the OP's problem has two valid solutions, since the cardioid always intercepts the y-axis in two places - the trick is to pick the one which results in the positive y-intercept. In an earlier response I stated

The third execution group uses DirectSearch() with limited constraints and the option AllSolutions=true, solutions=2. This returns both solutions for one angle in 1.8sec. So about 60X slower than the fsolve() process in (2) above - and I still have the overhead of figuring out which of the two returned solution is valid. This overhead would be minimal, so I'm not even going to count it.

Now this is the method which Sergey adopted in his worksheet: ie generate two solutions and then use some additional code to determine which of these two possibilities results in the positive y-intercept.

However as I stated in the same post, it is possible to achieve the same result directly, by supplying the requirement for a positive y-intercept as an additional constraint to the DirectSearch:-Solveequations()  command.

Theonly problem is that adding the "positive y-intercept" constraint to the DirectSearch:-SolveEquations() command, increases the solution time for one angle from 1.8secs to 47.5secs. I really don't think this is reasonable. If I can generate both solution in 1.8secs, I'm pretty sure I could check which gives a positive y-intercept in <0.1sec - it is just two expression evaluations. So why does the exectuuon time explode if I add the positive y-intercept requirement as a constrain with the DirectSeacrh:SolveEquations command? This I really don't get!