This is a bit of a random guess, but a for loop can only extend acros a single execution group (AKAIK). So if your original code extends across multiple execution groups, then a simp;e cut and paste won't work. If your code has mutiple execution groups, then try selecting all of the code you need for the body of your "for" loop and use

Edit->Split or Join->Join Execution Group

to create this code within a single execution group

Having done this, put a

for........do

****body****

end do

wrapper around the result

Your basic problem is that by using the quantity 1.5 - ie a float - then you are implicitly telling Maple to do floating point arithmetic. For your specific example, you can get (more or less) the answer you want by

restart;
y:=x->(3/2)^x:
diff(y(x),x);

Of course this will only work when the coefficient can written as a rational :-(

If I add

indets(EQ);

to the end of your worksheet, Maple tells me that the unknowns in EQ are

Luckily if I check the number of equations in EQ by using

numelems(EQ);

It returns 11 - meaning that you have 11 equations in 11 unknowns - so looking good so far. However if I try to solve this system of equtions for the unknowns, using

fsolve(EQ, indets(EQ));

then Maple returns

{P = -2.214980447207460142384437982552893015581,
  b[1] = 0., b[2] = 0., b[3] = 0., b[4] = 0., b[5] = 0., b[6] = 0., b[7] = 0., b[8] = 0., b[9] = 0., b[10] = 0.}

Although I have no doubt that this answer is correct, I have the strangest feeling that it is not the answer you want!

Not sure what you mean by "I cannot put the ruler on the sides of my worksheet". Maple does not have rulers on for its worksheets. If you want to change the size of a plot, just select it (mouse right-click) and then drag the appropriate window handle

If you want to do this in a somehat more programmatic way, then you can use the 'size' option to the plot command. Consider the following

plot(x^2, x=-10..10, color=red, size=[0.5,"square"]);

This will produce a plot whose size is given by a fraction of your screen size - in the above case, about 1/2. Any number less than 10 will be interpreted as a multiplier on monitor size, so

plot(x^2, x=-10..10, color=red, size=[2,"square"]);

will produce a plot which is around twice the size of you screen and "scroll bars" will appear on your Maple window, so that you can move around the whole plot.

The way Maple interprets the first numerical argument to the size option is as follows

1. If it is less that 10, then it is a multiplier on you monitor size
2. If it is greater then 10, it is interpreted as a fixed number of pixels

Thus if you want to produce the same plot in 5 different sizes, run the following

restart;
for j from 0.2 by 0.2 to 1 do
    plot(x^2, x=-10..10, color=red, size=[j,"square"]);
od;

The default size which Maple uses seems to be around 0.25, which you can see by comparing the output of

plot(x^2, x=-10..10, size=[0.25,"square"]); # specified size
plot(x^2, x=-10..10); # default size

The second entry to 'size' opotion controls the shape (ie aspect ratio) of the plot window. I advise you to read the size entry in the plot options - see ?plot/option

What do you hope to gain when someone does your homework for you???

The more intersting part of you problem is the part

Use the IVT to prove existence of a root to the equation x^3 +10x^2 -100x +50=0 in the interval [-20,10]. Use again the IVT to show that there is a 1st root in [-17,-15], a 2nd toot in [0,1] and a 3rd root in [ 5,6].

If you can do this, then you will get most of the marks available: becuase the final part

Find or approximate those roots with Maple. (the bolded is what I need help).

is trivial. In fact it is so trivial that in this case I don't mind doing your homework - you just have to bea ble to explain why it works, because I'm not going to

f:= x-> x^3 +10*x^2 -100*x +50:
r:=-20:
for i from 1 to 3 by 1 do
    r:=RootFinding[NextZero](f, r);
od;

Maple has been around for a very loonngggg time. As a result, the user interface has developed/evolved over (at least) the last 20 years. As a consequence there are three main user interfaces

1. Command line: you probably don't want to go here because entering Maple commands at a DOS prompt is just going too far into history
2. Classic: this was the first step up  from entering Maple commands in a DOS window. It was restricted to  using what you now know as 1-D math input. The perceived drawback with this interface is that the 1-D math inpu doesn't *look* like the kind of math input you woud see in a textbook. So it was efficient, but ddn't look pretty
3. Standard: this is the latest and greatest. The biggest "improvement" is that one can now use 2-D math input. The biggest drawback is that (sometimes?), 2-D math input can be ambiguous and cannot be successfully parsed. However one can still use 1-D math input (as in the Classic mode above), which is unambiguous, nut the penalty is that that this interface has a bigger memory footprint and is probably a little slower, due to an extra layer of parsing. It is unlikely that you will notice the latter because generrsally the computation times, greatly outweigh the parsing times.

So you are using the Standard input mode and experiencing some of the differences between 1-D input and 2-D input within this mode. Essentially you have decide which option is better for you! No-one can make this decision for you!

You have to decide whether "pretty" input, whose format may be difficult to control (for some structures) outweighs unambiguous, non-pretty input

You should probably also be aware that the majority of respondents (Including me) on this site havng been using Maple for a long time, have been coding in a certain way for a long time, and as a result  tend to be suspicious of newer developments (wwhihc they perceive as not offering much)

For what it is worth, I exclusivley use the Standard worksheet mode with 1-D math input. If I ever need to pretify this, then I simply use this method until everythin is working perfectly, then select and convert to 2-D input

It is pretty obvious that x=0 is a root so one can find successive roots along the positive x-axis using

f:=x->x*cos(x)-sin(x)*sin(x/1000);
r:= 0:
for i from 1 by 1 to 20 do
    r:=RootFinding[NextZero](f,r);
od;

In the revised worksheet (attached), I have coinverted your plots to 3d, just in case anything interesting happened for x-values other than 1. As stated, your problem is 3d, so I thought it was worth looking at the 3d solutions - although not a lot seems to happen for any (x,t) values

I added an execution group at the end which uses the Statistics[Fit] command to fit a generalised version of your suggested model function. I went for  a*exp(-b*t)-c*t, with [a,b,c] as fitting parameters. I wouldn't say that the fit is very good or very bad, and with three parameters for such a slowly-varying function, I guess I'd expect to do better.

However "guessing" a function which *might* fit some numerical data is a pretty random sort of thing to do. If you want  to keep trying, then I guess you can insert other model functions in the Statistics[Fit] command to see if you can come up with something better

pdeProbMod.mw

Here's three

f:=x->1/4*x^3-x^2-x+4;
map( j->[j,f(j)],[solve(f(x))])[];
map( j->[j,f(j)], Student[Calculus1][Roots](f(x)))[];
map( j->[j[1],f(j[1])], roots(f(x)))[];

I'm not an expert with the Physics[Vectors package, but a simple alias() command seems to work. Consider

   restart;
   with(Physics[Vectors]):
   Setup(mathematicalnotation=true):
#
# Define an arbitrary vector function
# and evaluate. Note use of "default"
# unit vectors
#
   f_:= (x,y,z)-> x*i_+y*j_+x*x*k_:
   f_(x,y,z);
#
# Set up three aliases and evaluate the
# function again
#
   alias(x_=i_, y_=j_, z_=k_):
   f_(x,y,z);

There are some notational niceties associated with using the Physics[Vectors] package.

In particullar, because both the Divergence() and Laplacian() commands expect their arguments to be vectors, you have to indicate that f(x,y,z) is a vector-valued function. In your worksheet, f(x,y,z) is a "simple" scalar function.

The simplest(?) way to denote a vector function within the Physics[Vectors] package is to use a postfix underscore (ie _) on the function name, so f_(x,y,z), denotes a vector function.

Thus

restart;
with(Physics[Vectors]):
Setup(mathematicalnotation=true):
Gradient(Divergence(f_(x,y,z)))+K*Laplacian(f_(x,y,z))=0;

ought to get you started. Whether or not your equation can be solved will ( I assume) depend on the nature of f_()

For the solution to this problem, I came up with

restart;
sys := { diff(x(t), t) = y(t),
         diff(y(t), t) = -(1+(1/100)*t)^2*x(t),
         x(0) = -1,
         y(0) = 2}:
dsn := dsolve( sys, numeric, output=listprocedure):
E:=  (a, b, w)->0.5*(a^2+w^2*b^2):
II:= (a, b, w)-> E(a, b, w)/w:
plots[odeplot](dsn, [  [t, E(  diff(x(t),t), x(t), 1+t/100), color=red],
                               [t, II( diff(x(t),t), x(t), 1+t/100), color=blue]
                           ],
                    t=0..10
       );

The resulting graphs disagree slighlty with Rouben's. I think that the discrepancy is due to the fact that Rouben's solution defines the function E() as

E := 1/2*(y(t)^2 + w^2*x(t)^2);

whereas the OP defined it as (my Highlight)

E(t)=0.5*(diff(x(t),t)^2+w^2*x(t)^2)

I have followed the OP's definition

Like Acer has already said, I have no idea why you would want to do this in the way which you specify.

You claim that

I don't want to set the result to mat in the loop to avoid memory issues while the terms in mat are calculated.

But if you have a "memory issue" then this will also show up on the read.

If you really, really want to do this (and I simply do not understand why??), then something like the following ought to work

#
# Toy example for write: Note that this does *not*
# assume that what is being written is a matrix: it
# simply writes each entry on a new line
#
# The target file (fname) is a location specific to
# my machine - OP will have to use something which works
# on his/her machine
#
   restart:
   fname:="J:/Users/TomLeslie/ThisIsATest":
   for i from 1 by 1 to 2 do
        for j from 1 by 1 to 3 do
             fprintf( fname, "%a\n", x^i+2*y^j):
        od;
   od:
   close(fname);
#
# Toy example for read. This just does a sequential
# read of the entries in the file and allocates
# them to a matrix entry, essentially based on the
# position in the specified file
#
   restart;
   fname:="J:/Users/TomLeslie/ThisIsATest":
   A:=Matrix(2,3):
   for i from 1 by 1 to 2 do
        for j from 1 by 1 to 3 do
             A[i,j]:=fscanf( fname, "%a")[]:
        od;
   od:
   A;

One way is to use the objects from the geom3d package, as in

   restart;
   with(geom3d):
#
# Define required objects, using a small
# sphere at the intersection point
#
   plane(p1,x-2*y+z=0, [x, y, z]):
   plane(p2,2*y-8*z=8, [x, y, z]):
   plane(p3, -4*x+5*y+9*z=-9, [x, y, z]):
   sphere(s, [intersection(pt, p1, p2, p3), 1]):
#
# return cordinates of intersection point
#
   ip:= coordinates(pt);
#
# draw planes and point
#
   draw( [ p1(color=red),
              p2(color=blue),
              p3(color=green),
              s(color=black)
           ],
           view=[ seq( j-10..j+10,
                             j in ip
                          )
                   ],
           axes=boxed
        );

Gave your problem a quick try and couldn't generate an "exact", ie symbolic,  solution.

Solving the ODE numerically is OK over the range 0..1, but solver hits a singularity at ~1.008

See attached

deProb.mw

What makes you thin an "exact" solution exists?