The ode has a singularity at x=0.

If you look at the solution to the command

dsolve(ode)

the denominator is x, which means that at x=0, y(0)->infinity, which cannot be reconciled with your boundary condition that y(0)=1.

To get a solution, you will need a boundary condition at a different x-value, and then make sure that you avoid the point x=0 in any subsequent work

@Axel Vogt 

Do people really have browser issues on this site????

Can't comment on IE, cos I wouldn't touch it with a bargepole

My default is FireFox with pretty tight security settings (because I'm paranoid and even have  Kaspersky's Total Security running on top). Don't ask why, but I occasionally use Chrome (also with Kas)

I have only ever had one "security" issue when posting to this forum - namely that both FF and Kas object if I want to insert a hyperlink to a different thread within the forum. Not completely sure why this is considered a "threat" but since it is something I do very rarely, and can be circumvented by typing the appropriate address in plaintext, I have never considered it much of an issue. Other than the fact that rather than clicking a hyperlink, readers would have to copy/paste the plaintext to their browser address window - can't say this bothers me overmuch

@Carl Love 

Since my original cock-up on this question I've been following the responses with interest, because once I appreciated what the OP actually wanted, I was unable to produce the code to produce it. Everything I tried broke because at some point the call to frem() would insist that its argument should be of type float.

However I found it rather unsatisfactory that in the code

eqns1:= diff(x(t), t) = eval
                         ( piecewise
                           ( 0 <= t and t < 10/3,
                             60,
                             10/3 <= t and t < 13/3,
                             0
                           ),
                           t=irem(t,13/3)
                         ),
         x(0)=0:
eqns2:= diff(y(t),t) = eval
                       ( piecewise
                         ( 0 <= t and t < 4,
                           50,
                           4 <= t and t < 5,
                           0
                         ),
                         t=irem(t,5)),
        y(0)=0:
sol1:= dsolve( { eqns1 }, numeric, output=listprocedure):
odeplot(sol1,t=0..50,gridlines=true,thickness=2);
sol2:= dsolve( { eqns2 }, numeric, output=listprocedure ):
odeplot(sol1,t=0..50,gridlines=true,thickness=2);
sol3:= dsolve( { eqns1, eqns2 }, numeric, output=listprocedure );
odeplot(sol3,t=0..50,gridlines=true,thickness=2);

the first two solutions (sol1,sol2) would always work and the third (sol3) would always fail. So I thought that the OP had a justified complaint

Don't get me wrong, I (now) sort of understand why it is happening - the "simplifications" which dsolve performs when presented with a "non-trivial" ODE system of equations means that eventually (however many uneval quotes are used) this will eventually fail because because of the insistence of correct argument types for frem()

However all "solutions" I have seen are based on the premise: please don't check the arguments to frem() until floats are actually presented. To my simple mind, if frem(x,y) when presented with one or two symbolic arguments. simply returned frem(x,y), then the issue would be avoided.

I'm probably mssimg some fundamental reason why this cannot be achieved, but I keep going back to the original code above and being rather unhappy that sol1 and sol2 are unconditionally correct and that sol3 is unconditionally wrong.

I still think that the OP has a legitimate gripe

Given the paucity of the information whcih you provide, I can only suggest the following from school calculus

1. Perform the integration
2. Differentiate the result and set equal to zero in order to find the stationary points (most will see integration followed by differentation as redundant, and even I wouln't do it this way, but I am trying to be pedantic about the term "minimize")
3. Differentiate again and backsubstitute the stationary points found in (2) above). You have a minimum whenever the result of this step is >0

If this isn't what you want then I suggest you make your question (much, much) clearer

@Carl Love 

Aitken's (note spelling) method is a means of improving the next estimate based on the previous two estimates.

It is generally considered as a "wrinkle on" or an "improvement to" a moree basic method of finding roots.

Hence the staring point for a procedure into which Aitken's method might be incorporated is to write a routine performing something like the basic Newton-Raphson Method (sometimes just called Newton's method) - other iteration procedures are possible but let's not vcomplicate matters unnecessarily

Once you have written a Newton-Raphson method, then you can consider the ways of updating the estimate using Aitken's method (rather than the basic Newton-Raphson approach).

My interpretation of a few of Carl's comments (above) is that you were thinking about about performing a basic Newton-Raphson - but then gave up, because you really don't understand the problem you are trying to solve. So there are various things which you compute but don't use, such as this whole subsection

p:=problemm:
      d:=diff(f,x);
      e:=abs(subs(x=x[0],d));
      if e>1 then
           p:=problemm:

I'll give you a futher hint: the following is a (very) basic Newton-Raphson method.  Before the gurus here shoot it down, I said it was very basic and is certainly sub-optimal under all sorts of conditions, but will generally work if f() is a "nice" function

myNewt:=proc(f, x0)
                      local i:=0, eps:=1.0e-06, x;
                      x[0]:=x0;
                      while f(x[i]) > eps do
                              x[i+1]:= evalf(x[i]-f(x[i])/D(f)(x[i])): # you are interested in this line
                               i:=i+1:
                      od;
                      return x[i], i, f(x[i]);
              end proc:

If you define f(x) as (for example)

f:=x->x^2-3*x+1:

and then execute

myNewt(f,10);

it will return the root you require, the number of iterations and the value of the function at the computed root (which you can consider as the error term)

As the comment in the procedure identifies, you are looking for a "better" way of performing the x[i+1] update which is given by Aitken's method. Once you understand what Aitken's method actually is, substituing it into the above procedure should not be too difficult

In case you are wondering why I don't just do your homework, it's probaby because no-one ever did mine

Your procedure uses a function call g() in a couple of places, for updating x[i] - however g() is not defined anywhere. Need a definition of g() befrore anything else

@Carl Love 

Possibly looking for an implementation of Edmond's algorithm for finding a "spannig arborescence" which wikipedia describes as "the directed analog of the minimum spanning tree problem"

@Alejandro Jakubi 

1. Whilst reading your (helpful?) advice on how I should write functions in Matlab, I completely missed the fact the fact that you were not the OP, for which I apologise unreservedly
2. My remarks were addressed primarily to the OP who appears to think that writing ~500 lines of Matlab, and then stitching a function wrapper around it, rerpresents reasonable programming practice
3. My criteria for writing functions/procedures are strictly mine. Does it surprise me that many applications contain functions/procedures which violate my criteria - well, no (regrettably). Does that make such functions/procedures examples of good programming practice - errr, no. Just because they exist doesn't make them good

@rlopez 

"From my 15-years experience using Maple with students in this environment, I think anyone who admits to being a new user deserves more help than simply being pointed to a Maple help page."

They will probably get more help if they can demonstrate any sign of having at least tried to do their own homework. That is, over and above just typing their homework questions on to this site and asking for a solution.

And if you get an answer between 14 and 15 you are probably getting it right

@spark1631 

Help for the DirectSearch package is included with the download. However it is in the deprecated hdb format (or at least it was when I downloaded it). In order to be compatible with Maple 18 or later this help database has to be converted to .help format. For conversion, check out ?HelpTools[Migrate]

@Alejandro Jakubi 

Thank you for your link. I prefer to read the Matlab help documentation which I have installed locally as part of my ongoing subscription.

Actually both programs promote more-or-less the same programming practices - they just do it in slightly different ways. In the case of variable scope, associated defaults and warnings, I can live with either. This is probably because my programming practice is so different from yours, but is the essentially same for both Maple and Matlab. This can be summarised as

1. Never use global varibles
2. Never use a function/procedure where the active code section is more than a screenful in my default editor. This restricts me to about 50 lines of active code. Actual sizes of .m and .mpl files which I produce are often about twice this size, but that is just becaue I write a lot of comments.

if you put

myProcName:= proc( arguments )

                        500 lines of crap code

                      end proc;

then you will have the procedure you require. Tou can then call it using myProcName( arguments )

Notice that Maple (like Matlab) will give you all sort of warnings about local/global variables, and any additional procedures will have to be defined/loaded externally.

You will of course have produced something which probably cannot be used in any other context, although since you have such a cavalier attitude to variable scope, encapsulation, or any other decent programming practice, I doubt if this will bother you very much

I suppose the alternative is that you actually read the ?Procedures help page which will assist you in doing it properly.

PS. the answer to your statement

"It is not easy for a long program with many variables to write them in local or global variables."

is that you should not be writing a program in such a way.

1. Any "long" program can be subdivided into a number of short programs which are easier to maintain/transfer/debug - it's generally called good programming practice
2. If you cannot handle the above as well as something so basic as variable scope, then you are free to write such garbage for your own amusement, but please don't inflict them on the rest of us

@al-faraj 

You original post stated that you had done a power fit and obtained the answer

Now, I did this. I got this  ^{1,18971*x*0,38480}

Notice the existence of two multiply signs (ie *) and no exponentiation (ie ^).

Your latest post says that you have evaluated

f(x):=1.8971*x^(0.38480):
f(17);

Notice the existence of an exponentiation and the fact that the multiplicative coefficient has changed from 1,18971 to 1.8971 - examine the first digit to right of the decimal point very carefully!!!!

Therefore one or both of these two posts is completely wrong and because you are incapable of presenting consistent, accurate data, we are reduced to guessing what it is that you want. Based on your posts so far, there are at least four possibilities, which are

1.8971*x^(0.38480):
1.18971*x*(0.38480):
1.8971*x*(0.38480):
1.18971*x^(0.38480):

Just imagine how much easier it would be for those responding on this site if you could work out the question!!
************************************************************************************

Somewhat depressingly, you have also stated that this equation arose as a power fit of the data

X: 2,   3,   6,   10,  14
Y: 2.5, 2.9, 3.7, 4.5, 5.1

As the worksheet I posted originally clearly demonstrated, performing a power fit on this data results in

1.93692314754707*x^.365641019049509

which corresponds to none of the fits you claim to have obtained, so either your data is incorrect or all four of the possible fits above are incorrect

I suggest you read/execute the worksheet I posted originally and tell me exactly which statement/evaluation is incorrect

@yellowcanary 

"should I save it in a word file and upload then"

No!! save it as a Maple worksheet (ie a xxxxxx.mw file) and upload the .mw file. We can load and work with such files immediately.

"Could you please explain when should I use 2D input? I dont know the difference between 1D input and 2D input in maple."

Well you could start probably start a small war here by asking whether you should be using 1-D or 2-D input. They each have advantages/disadvantages, so before I comment I will state that I never use 2-D input. Now that you know my prejudice, I will make the following observations:

1. Maple has been around for a long time. The "experts" here probably started using Maple before there was a choice of input mode - it was 1-D or nothing. When one has spent many years working this way, changing to a different working method looks like a waste of time, unless there are some *seriously significant* benefits. My own view is that the benefits are not sufficient, and are primarily aesthetic rather than practical, which I do not consider to be significant, so I experimented with 2-D input when it became available, but decided not to change. (I have no doubt that others will disagree)
2. I find code written in 1-D input easier to debug. In your particular example, I suspected a difference between P_B(p-w) and P_B (p-w), but I was essentially guessing, based on the typography. I don't have any difficulty seeing the difference between the 1-D equivalents P_B*(p-w) and  P_B(p-w)
3. So far as I can tell, the main reason/justification for using 2-D input is that such input will *look* like material presented in a textbook. It is therefore simpler to compare your input with a textbook, which can be quite valuable - after all, if your input *looks* the same as a texbook, then you must be correct - whether or not it will be parsed the same way as your textbook implie is a separate issue
   
4. My ultimate view is that you have a choice between
1. 1_D input: looks ugly, but easy to debug - pragmatic
2. 2-D input: looks pretty but difficult to debug - aesthetic
   

           pick one!