In the instructions, it says that a[0] and a[1] should probably need to be assigned before the fact. So, do that, because otherwise an open-ended while-do method may not terminate. (This problem can be solved with only a[0] preassigned, but that can also depend on how you code it.)

It mentions a[0] and a[1]. That is a hint to use indexed names. So do that, using a[n] and a[n-1] rather than using `an` and `an--1`. And enter the initial values as floats up front, like 1.0 for a[0], etc.

You'll probably want to use a counter, like n (or i). If you use a while-do loop then you'll need to increment the counter explicitly inside the loop. And you'll need to assign the counter (to, say, the non-float integer value 1) before the loop code.

Your candidate `while` condition tests |an-a1|<10^(-5). But, really, you instead want it to continue looping if |an-a1| >= 10^(-5), so that it terminates only when the less-than form is satsified. So you probably want to switch than from < to >=. Then  the code is equivalent to, "while my stopping condition is not satisfied, keep iterating...".

Inside the loop, the assignment should be to a[n], and the formula to which it that  gets assigned should use a[n-1], assuming that `n` is your counter.

A potential problem with a while-do loop is that if coded wrongly it may run away, without terminanting and putting Maple into tight spin. You may choose to add in a safeguard against this, with a conditional if-then-break if the counter exceeds some large value (ie. runaway due to miscoding, or it's not converging).

ps. There is also a nice short solution using `a` as a recursive procedure (with option remember, to get fancy). That alternate solution, using a procedure for a instead of indexed names like a[n], is cute because only the single a[0] needs assignment up front and because nothing need happen inside the loop except incrementing the counter and safeguarding against runaways. The "work" to compute each iterate gets computed during the while-check.

acer

The quote placement in `c:/test||i.eps` is not right. You might have meant something like,

> for i from 1 to 3 do
>   "c:/test/"||i||".eps";
> end do;
                                "c:/test/1.eps"

                                "c:/test/2.eps"

                                "c:/test/3.eps"

or,

> for i from 1 to 3 do
>   `c:/test/`||i||`.eps`;
> end do;
                                 c:/test/1.eps

                                 c:/test/2.eps

                                 c:/test/3.eps

If you place name quotes around the Maple || concatenation operator and the  i then it won't do anything. Also, you were probably missing a / directory separator.

acer

I suspect (but am not 100% sure) that the submitter wants to select the purely real solutions from solve's output, and not just to extract the real part of the returned solutions. Apologies, if I've interpreted that incorrectly.

Zro85, the Re() command will extract the real component. But the real component of any of the complex solutions may not also be a solution. It's not clear that you realize this, about Maple's Re() command. Is it clear?

If you search this site for the pair "RealDomain" and "solve" you will find other posts that discuss the question of getting only purely real solutions to an equation or system of equations.

acer

Apart from what Doug wrote, I wonder whether there is another mistake.

(-1)^(n+1), for n odd, may not be what you want. It's always 1, isn't it?

acer

> simplify( signum(1,Q) ) assuming Q::real, Q<>0;
                                       0

Note that the assumption that Q<>0 does not in itself imply that Q is real. But the assumption Q>0 does imply that Q is on the real line.

Will this pair below prompt a lecture about types vs properties? Use the second one below, if you wish.

> simplify( signum(1,Q) ) assuming 'Or'(Q>0,Q<0);
                                       0

> simplify( signum(1,Q) ) assuming OrProp(Q>0,Q<0);
                                       0

acer

The first surface is not a plane.

plots[intersectplot](1/2*(x+y)+5=z, x^2+y^2=z, x=-3..3,
                     y=-3..3, z=-10..10, axes=BOXED);

Getting fancier,

pli := plots[intersectplot](1/2*(x+y)+5=z, x^2+y^2=z, x=-3..3,
                   y=-3..3, z=-10..10, color=red):
p1 := plot3d(x^2+y^2,x=-3..3, y=-3..3, color=cyan):
p2 := plot3d(1/2*(x+y)+5,x=-3..3, y=-3..3, color=green):
plots[display]([p1,p2,pli]);

acer

What is the data assigned to? What is assigned to x, y, and z?

I'm guessing that you have assigned to `x` the Vector of the first independent variable's values, and to `y` the Vector of the second independent variable's values, and to `z` the Vector of the dependent variable's values.

Did you instead mean something like this?

Fit(a+b.x+c.y+d.x^2+e.x.y+f.y^2, Matrix([x,y]),z,[x,y]);

acer

Try this,

> with(student): with(RealDomain):

> F := int(sqrt(u),u=0..t^10);
                                            5   15
                             F := 2/3 csgn(t ) t

> simplify(F) assuming t::real;
                                           15
                                  2/3 | t |

> df := diff(F,t);
                                     5   15            5   14
                  df := 2/3 csgn(1, t ) t   + 10 csgn(t ) t
 
> evalc(df);
                                           5  14
                               10 signum(t)  t

> simplify(%) assuming t::real;
                                         13
                                 10 | t |   t

Maple also came up with the following, though it took much longer than it ought to have done.

> F := int(sqrt(u),u=0..t^10) assuming t::real;
                                      15
                            F := 2/3 t   signum(t)

I originally gave a flippant answer to this question. But, under the RealDomain environment, the assumption that t is real doesn't seem strained. Also, Maple didn't seem able to simplify(df) nicely and immediately under the assumption that t was real. Hence I made intermediate use of evalc. Having to use `assuming` and evalc underneath RealDomain doesn't look so good.

acer

What happens when x<0 ? What about when x>=0 and x<1?

> limit(f,s=0) assuming x>=1;
                                       0

acer

It could be that the Float(infinity) result you see is due to the working precision. In such a case, it might help to increase the working precision. For example,

> 1/(1.000000000001 - 1.0);
                                Float(infinity)
 
> Digits:=20:
> 1/(1.000000000001 - 1.0);
                                                   13
                          0.10000000000000000000 10

Or it may be that the result is a good representation of the answer, in some limiting concept. Consider,

> evalf(Int(1/(2-x),x=1..2)); # or int()
                                Float(infinity)

Note that in the above, the integrand cannot be evaluated at the end-point value of 2. You might think of that input as a shorthand notation for,

> evalf( limit(Int(1/(2-x),x=1..b), b=2, left) );
                                Float(infinity)

That's a mathematical way of saying that the area under the curve 1/(2-x) from 1 to b tends to infinity as b tends to 2 from the left. To replace maple's result of infinity by some large finite value M would be wrong, because there is always some b~ closer to 2 for which the area from 1 to b~ would be greater than M.

Nobody can write down explicitly a number with an infinite number of digits, or draw an infinite area (unscaled). But there are lots of mathematical problems for which infinity is nevertheless the best way to represent the answer (as a limiting concept).

Without knowing your example, it's hard to say more that may be of help to you.

acer

> V := Vector(10,i->3*i+11);
                                        [14]
                                        [  ]
                                        [17]
                                        [  ]
                                        [20]
                                        [  ]
                                        [23]
                                        [  ]
                                        [26]
                                   V := [  ]
                                        [29]
                                        [  ]
                                        [32]
                                        [  ]
                                        [35]
                                        [  ]
                                        [38]
                                        [  ]
                                        [41]

> V1,V2 := V[1..5],V[6..-1];
                                       [14]  [29]
                                       [  ]  [  ]
                                       [17]  [32]
                                       [  ]  [  ]
                             V1, V2 := [20], [35]
                                       [  ]  [  ]
                                       [23]  [38]
                                       [  ]  [  ]
                                       [26]  [41]

See ?interface and the item on rtablesize, for controlling the dimension above which Vectors/Matrix get printed compactly. Eg,

interface(rtablesize=9);
Vector[row](10);
interface(rtablesize=10);
Vector[row](10);

See ?LinearAlgebra,General,MVextract for more about Vector "extraction".

Sorry, I don't have any ideas about problems specific (only) to printing. You might consider contacting support@maplesoft.com to ask Technical Support.

acer

> simplify(rationalize(d));
                                       1/2
                                      2
                                    - ----
                                       2

> radnormal(d);
                                       1/2
                                      2
                                    - ----
                                       2

acer

You create a module, which you give the name you want for the package. And you give it 'option package'.

For example,

foo := module()
option package;
export f1, f2;
  f1 := proc() "stuff" end proc;
  f2 := proc() "other stuff" end proc;
end module:

with(foo);
f1();
f2();

acer

The awful results from this particular posted use of the GlobalOptimization toolbox are due to the fact that, as the problem was originally set up, the solver would only be able to do a relatively small number of global search evaluations before it timed out. The reason for this is because dsolve(...,numeric) was being called an enormous number of times. The act of setting up the dsolve/numeric solver was itself being done inside the objective function, at each evaluation of the objective.

Joe's responses show how the dsolve calls may be brought outside the evaluation routines, to be done just once as a set-up step.

Once the objective is made fast enough, and can run enough times to to the global optimizer a chance to do enough evaluations, it can find decent results.

I consider Joe's responses to be excellent.  I also feel that these techniques could be better documented in the product. A worksheet could illustrate the ideas nicely. And that might be usefully referenced from the help-pages of both dsolve/numeric, Optimization, and GlobalOptimization. One could construct a problem for which the numeric DE solving was involved within a root-finding problem, and thus the parametrized numeric DE solver needed to be called from fsolve.

acer

If you don't mind waiting for the entire worksheet to re-execute, then the "!!!" button or top menubar's "Edit"->"Execute"->"Worksheet" actions should suffice.

However, some key parts of a worksheet might take a great deal of time to execute, if heavy computations are involved. And re-execution of the whole worksheet might then be undesirable. Sometimes one would like to be able to change certain values, or plot options, etc, and re-run only some subset of an existing worksheet.

So, there's a distinction, between expensive parts that you don't want to re-execute, and interactive parts that you might like to call once again. Re-executing the entire worksheet doesn't allow for this distinction.

The commands `save` and `anames` can be used to save Maple's "state" (or parts of it). The state can be saved into a file, and then re-read quickly back into a new session with an explicit `read` command. But such state files are distinct from worksheets. The worksheet itself doesn't have the complete state bundled up within it.

The Standard GUI can prompt you about whether to bundle large amounts of plot data (that sit behind the scenes) into a worksheet. That's a bit of an exception to the rule.

Hmm. I wonder whether one could create an auto-opening .mla archive, whose load action reads a .m state file as well as opens a worksheet. Maybe it'd have to rely on -kp or a shared kernel.

acer