First of all, x^2 + y^2 + z^2 = 4 is a sphere of radius 2 centred at the origin, and has no points with z >= 4. But let's suppose you want z >= 0 which would be a hemisphere. I presume you want to use Flux in the VectorCalculus package. Since Sphere would give you the whole sphere, which you don't want, you need to use Surface, and give it a parametric representation of the hemisphere. Although you're using cartesian coordinates for your vector field, it's most convenient to specify the hemisphere in spherical coordinates. You didn't say whether you want the normal pointing inward or outward; I'll assume it is outward. For inward, reverse the order of the phi = ... and theta = ... arguments. Then:

  with(VectorCalculus):
  SetCoordinates(cartesian[x,y,z]);
  hemisphere:= Surface(<2,phi,theta>,
     phi = 0 .. Pi/2, theta = 0 .. 2*Pi,
     coords=spherical[r,phi,theta]):
  Flux(VectorField(<3*x*z,2*y,0>), hemisphere);

You can use implicitplot with the option filledregions=true. Thus:

 with(plots):
 implicitplot(abs(x-y)+abs(x)-abs(y)-2, x = -3 .. 3, y = -3 .. 3,
   filledregions = true, coloring = [blue, white]);

The region where the first argument to implicitplot is negative, i.e. |x-y|+|x|-|y| < 2, is blue, while the region where it is positive, |x-y|+|x|-|y| > 2, is white.

1) evalr 2) Tolerances package 3) ScientificErrorAnalysis package 4) Interval Arithmetic package IntpakX from the Maple Application Center

Basically this limit (as sigma -> 0+, as Doug mentioned) can be done for a particular V(t) if Maple can do the integral in closed form, but usually not otherwise. For the general case, a change of variables helps.

> J := student[changevar](t=mu+s*sigma, MyFunc1(t,sigma,mu),s) 
assuming sigma > 0;

J := int(1/2*V(mu+s*sigma)*2^(1/2)/Pi^(1/2)*exp(-1/2*s^2),s = -infinity .. infinity)

> limit(J, sigma = 0);

V(mu) Of course, as Doug mentioned, the result is not really true for arbitrary V: we don't even know the improper integral converges, and V might not be continuous. But, as is often the case, Maple is quite happy to give an answer on the formal level.

1) What is the equation of the cone? 2) What are the parametric equations of the line? 3) Substitute (2) into (1) and solve.

Your code uses multiplication to combine several different things into one formula:

Set(AaBc=`
b[1]:=`*b1*
            `& NewLine;b[2]:=`*b2*
            `& NewLine;b[3]:=`*b3*
            `& NewLine;`);

In general that's a dangerous thing to do, because Maple treats multiplication as commutative. In particular, a number (which is what b3 is in this case) will always be put before any other factors in the product. What I would use would be a vector of equations. Thus:

Set('AaBc' =  < (b[1] = b1),
              (b[2] = b2),
              (b[3] = b3) >
            );

I think it's not really a matter of Document vs Worksheet, but rather 2D math input vs 1D Maple input. I was rather surprised to see that

(9950 <= SG1[i] <= 10050)

worked in 2D math input. The 1D input that this corresponds to is

(9950 <= SG1[i] and SG1[i] <= 10050)

BTW, your code doesn't quite do what you say you want it to. To get the closest list entry to 10000 and its index, I might use this:

> dmin := infinity:
  for i from 1 to nops(SG1) do
    d := abs(SG1[i]-10000);
    if d < dmin then
       dmin := d;
       imin := i;
    end if;
  end do:
  SG1_10K := [SG1[imin], imin];

Curious wrote:

int(Sec^2*x dx)

which is interesting for several reasons. Of course this is not the actual Maple input, which would just produce a "wrong number (or type) of arguments" error. Presumably it was actually int(Sec^2*x, x). I don't know if Curious actually used the * here rather than implied multiplication, but on quite a number of occasions I've seen * used in this context (in 1D input) by students who should know better. I try to discourage the use of notations such as sec x in my calculus classes, partly to try to reduce the likelihood of this kind of error, but I doubt that we can stamp it out. From time to time there have been discussions of a "novice mode" for Maple, that would attempt to catch likely errors such as this. I think it would be a good idea. The errors we've seen here should be high on the list of things to look for.

Only some Maple procedures work well with assumptions, and assuming an equality usually doesn't work well. I tried it with a = RootOf(_Z^2+b^2-1), which I think ought to work, but it didn't: this may be a bug. With a = sqrt(1-b^2) it does seem to work. Of course, you could also use a = -sqrt(1-b^2). The results are rather complicated, but seem to be correct. It may be possible to simplify them somewhat. Using sqrt does not assume that anything is real, and these results should be valid for either real or complex values of a and b. Certainly assuming that something is _not_ real is not likely to make it simpler.

The PieChart procedure from my

I don't know if Maple can take advantage of a block Toeplitz structure. A Toeplitz matrix can be stored very efficiently. But when it comes to computing eigenvalues and eigenvectors, I don't know if there is any specialized algorithm: Maple treats it as just an ordinary Matrix. For example:

> with(LinearAlgebra):
  infolevel[LinearAlgebra]:= 5:
  A:= ToeplitzMatrix([seq(i,i=1..199)],compact=true,
     outputoptions=[datatype=float[8]]);


ProcessOptions:   "Option: compact = true"
ProcessOptions:   "Option: outputoptions = [datatype = float[8]]"

      [ 100 x 100 Matrix                                     ]
 A := [ Data Type: float[8]                                  ]
      [ Storage: empty                                       ]
      [ Shape: Toeplitz[false,[1,2,3,4,5,6,7,8,9,10,11,12,...]
      [ Order: Fortran_order                                 ]

> length(A);

753 (so this is taking up very little memory)

> Eigenvectors(A);

Eigenvectors:   "calling external function"
Eigenvectors:   "using hardware external library"
Eigenvectors:   "CLAPACK"   hw_dgeevx_

    [ 100 Element Column Vector ]  [ 100 x 100 Matrix     ]
    [ Data Type: complex[8]     ], [ Data Type:complex[8] ]
    [ Storage: rectangular      ]  [ Storage: rectangular ]
    [ Order: Fortran_order      ]  [ Order: Fortran_order ]

BTW, for a symmetric Toeplitz matrix you can have the eigenvalues and eigenvectors calculated using a CLAPACK algorithm for symmetric matrices (which is much more efficient than that for general matrices), but only if the "compact" option is not used. Thus:

> B:= ToeplitzMatrix([seq(i,i=1..100)], symmetric,
    compact=false, outputoptions=[datatype=float[8]]);

ProcessOptions:  "Boolean option: symmetric"
ProcessOptions:  "Option: compact = false"
ProcessOptions:  "Option: outputoptions = [datatype = float[8]]"

                      [ 100 x 100 Matrix           ]
                 B := [ Data Type: float[8]        ]
                      [ Storage: triangular[upper] ]
                      [ Shape: symmetric           ]
                      [ Order: Fortran_order       ]

> Eigenvectors(B);
Eigenvectors:   "calling external function"
Eigenvectors:   "using hardware external library"
Eigenvectors:   "CLAPACK"   hw_dspevd_

       [ 100 Element Column Vector ]  [ 100 x 100 Matrix     ]
       [ Data Type: float[8]       ], [ Data Type: float[8]  ]
       [ Storage: rectangular      ]  [ Storage: rectangular ]
       [ Order: Fortran_order      ]  [ Order: Fortran_order ]

int(f(x),x) produces an antiderivative of f(x). Adding a constant to an antiderivative gives you another antiderivative. So Maple and Maxima are both right. Which answer you prefer is a matter of taste.

The equation in question is

> Eq16:= 2*EllipticE(beta,k)-EllipticF(beta,k)
    =tan(beta)*sqrt(1-k^2*sin(beta)^2);

Normally, to plot an equation (rather than a function) we use implicitplot in the plots package.

> with(plots):
  implicitplot(Eq16,beta=-Pi/2..Pi/2,k=-1..1,axes=box);

However, that doesn't work in this case. This is a bug. I think the problem is that implicitplot tries to use hardware floats, which doesn't work on the elliptic functions. It would work if you used a higher setting of Digits, which would prevent evalhf from being used. However, the following works:

> contourplot(lhs(Eq16)-rhs(Eq16),beta=-Pi/2..Pi/2,k=-1..1,
    contours=[0]);

The result looks strange (although it would be better if you added the option view=[-Pi/2..Pi/2,k=-1..1]): it really should be the straight line beta = 0, but since the difference between the two sides is only O(beta^3) as beta -> 0, there are numerical problems in trying to interpolate the crossing points.

> kernelopts(version);

There's an example on the help page ?implicitplot:

> implicitplot(x^2+y^2-1, x=-1..1, y=-1..1, coloring=[blue, 
     green], filledregions=true);