Your idea about how to go about showing it is good.

Write the equation of the line in parametric form, using say the parameter name t.

Now, substitute the formulae(in terms of t) for x, y, and z of that parametric form in for the x, y, and z that appear in the equation for the sphere. That results in a quadratic equation in the parameter t. Now solve that quadratic equation, to get two solutions for t. Plug each of those two values of t into the parametric form of the equation of the line, and those results are the two intersecting points.

Here's how to do those steps in Maple. First, create the points, line, and sphere.

with(geom3d):
point(a,-3,-10,2),point(b,5,14,8):
line(L,[a,b]):
_EnvXName := x: _EnvYName := y: _EnvZName := z:
sphere(s,x^2+y^2+z^2 = 36,[x,y,z]):

Maple can now give the answer right away,

intersection(P,s,L):
coordinates(P[1]);coordinates(P[2]);

Or you can do each step in Maple,

eL:=Equation(L,'t'); # equation of line
es:=Equation(s);

# substitute components of line form into sphere's equation
teq:=expand(eval(es,[x=eL[1],y=eL[2],z=eL[3]]));

# solve the quadratic equation
tsols:=solve(teq,t);

# plug both t values into the line (parametric form).
seq(eval(eL,t=tval),tval in [tsols]);

acer

What is the output from the shell command,

file try_it.so

What is your machine, a G5? And the OSX, is it 10.5? (I'm wondering whether there's a 32/64bit mismatch between the shared library and the Maple binary. I'm wondering whether the shared object needs to be compiled/linked with a -arch flag to force its architecture to match Maple's. Just an idea...)

acer

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