There are two factors at play here, in the multivariate Newton's method solver. One is the number of iterations that get done, for a given starting point. Another is the number of different starting points from which iteration gets done.

Try setting,

> _EnvTry:='hard':

This line in `fsolve/sysnewton` hints that the number of allowed iterations gets affected by this.

> showstat(`fsolve/sysnewton`,41);

  41     for it to `if`(_EnvTry = ('hard'),max(Digits-7,50)*n+60,(Digits-7)*n+16) do
end proc

As you can see, the value of Digits also affects that maximal number of allowed iterations. You had said that increasing Digits (and hence increasing the number of iterations allowed) didn't help much. So this may not suffice.

The number of different starting points from which it begins iterating isn't an option that can be set, however.

The very brave might try to surgically alter the routine, to change the maximum number of starting points,

> showstat(`fsolve/sysnewton`,20);

  20   maxguess := 20;

In this post Jacques did live surgery on another routine.

I would advise not tightening the bounds too much. I realize that it seems intuitive that doing so would assist the solver. But there may be bounds check going on, which (inappropriately) short-circuits a guess/iteration-loop if an intermediate value steps out of bounds. So with very tight bounds such early cut-out can actually prevent a root from being located.

acer

When you pass S(n) as an argument to plot, it is evaluated right away. Ie, it evaluates with the unassigned n, just as if you'd entered S(n) on its own.

 S(n);
Error, (in F) final value in for loop must be numeric or character

Try plot('S'(n),n=1..10) or plot(S,1..10) instead.

ps. There are ways to speed up the sampling, if you're interested...

acer

I won't go into efficiency. But, given what you have so far,

> with(Statistics):
> S:=Sample(Bernoulli(0.5),2):
> S := 2*(S-<0.5,0.5>);
                                S := [1., -1.]

acer

You have declared pos as a local variable of procedure treach. And treach doesn't assign to the pos variable. So when treach runs it cannot figure out the conditionals involving the pos[n] term.

acer

> restart:
> simplify( abs(3*x-24) - 3*abs(x-8) ) assuming x::real;
                          | 3 x - 24 | - 3 | x - 8 |
 
> simplify( convert( abs(3*x-24) - 3*abs(x-8), piecewise ) );
                                       0


> restart:
> f := -cos(2*x - 4)/sin(2*x - 1):
> s1 := diff(f, x):
> s2 := 2*cos(3)/sin(1-2*x)^2:
> simplify(s1-s2);
      2 (-sin(2 x - 4) sin(2 x - 1) - cos(2 x - 4) cos(2 x - 1) + cos(3))
      -------------------------------------------------------------------
                                               2
                              -1 + cos(2 x - 1)
 
> simplify(convert(s1-s2,expln));
                                       0

acer

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