If you are using solve, you can use the maxsols=# option (see ?solve,details ) to limit the number of solutions returned:

(**) nops( [solve(x^100-1, x, maxsols=10)] );
                                      10

I would use showstat instead of print. Then you don't have to change any kernel or interface settings (but you do get line numbers):

(**) showstat(Student[NumericalAnalysis][Newton]);             

Student:-NumericalAnalysis:-Newton := proc({method::identical(newton) := 'newton'})
   1   return Roots(args,(':-method') = method)
end proc

(**) showstat(Student[NumericalAnalysis][Roots]);
...

To create safe subscripts use ctrl-_ instead of just _.  In the following (1) was made with _, while (2) was made with ctrl-_:

(2) is safe to assign to.  In (1) you'll have this problem, (shown in 1-D input):

> omega := 1; 
                                  omega := 1

> omega[1] := 2;
                                 omega[1] := 2

> omega;
                                     omega

> eval(omega);
                                table([1 = 2])

A first step would be to try the built in importer ?Matlab[FromMFile]

Just define things as expressions. It will make your life easier:

p := 10*x-20*piecewise(x < 2, 0, 2 <= x, x-2);
F := -int(p, x);

Use eval if you want to specilize at x:

eval(F, x=2);

John

What you are seeing are perfectly normal, and expected, artifacts of converting between hardware floating point numbers stored in base 2, and Maple software floats stored in base 10.

(**) evalf[18]( HFloat( HFloat(858/1000.)*HFloat(1000.) ) ); 
                              858.000000000000114
(**) evalf[18]( HFloat( 858. ) );
                              858.

Or:

(**) restart; (SFloatMantissa,SFloatExponent)( HFloat( HFloat(858/1000.)*HFloat(1000.) ), 2 ); 
                             7547047813054465, -43

(**) restart; (SFloatMantissa,SFloatExponent)( HFloat(858.), 2 );
                             7547047813054464, -43

The round off in the hardware loses one binary digit of precision, so back it base 10 it is only accurate to 15 digits.

To avoid the automatic conversion to hardware floats, you can set the enviroment variable ?UseHardwareFloats :

(**) restart: UseHardwareFloats:=false:
(**) a:=Matrix(1..5,1..5,(rand(1..1000))/1000.): b:=a*1000: dismantle(b[4,4]);
FLOAT(3): 858.0000000
   INTPOS(2): 8580000000
   INTNEG(2): -7 

(**) evalf[18](b[4,4]);
                              858.0000000
(**) restart: UseHardwareFloats:=deduced: 
(**) a:=Matrix(1..5,1..5,(rand(1..1000))/1000.): b:=a*1000: dismantle(b[4,4]);
HFLOAT(2): 858.

(**) evalf[18](b[4,4]);
                              858.000000000000114

Looking at the help page ?ImageTools,PlotHistogram I wonder if you are getting larger numbers than you expect because the default is to report the raw numbers of pixels in each bucket.  If so then:

ImageTools:-PlotHistogram(img, 'autorange', 'normalized');

might give you something more like what you expect.

John

This question is asked a lot.  I think the best advice is to use the Standard GUI with different defaults: http://www.mapleprimes.com/questions/95574-Where-Is-The-Classical-Worksheet-maple-10-#comment95582

John

You might take a look at ?plots[matrixplot] and ?plots[listplot3d] those are two different methods for creating plots from coordinate data.

John

You might try generating the points yourself and then using ?plots[pointplot3d] to build the plot.

Here is the shortest way I could think off the top of my head:

(**) WTable := Matrix(40,9,(i,j)->i*1000+j):
(**) WTable := WTable([seq(i,i=1..40,2)],..);

It is also possible to use `$` instead of 'seq' but the above is probably better Maple (esthetically):

(**) WTable := Matrix(40,9,(i,j)->i*1000+j):
(**) WTable := WTable([(2*i-1)$i=1..20],..);

I should back up a second and address this:

Writing some code in the "Startup Code" via Edit > Startup Code. The good thing here is that this code follows the document, meaning that it can be used by another person. The bad thing is: it does not seem to work after a restart, only at startup.

As fas as I can tell (at least in Maple 14), the code in the startup code area does execute every time the "Restart Maple Server" button is pressed or the "restart;" command is given (this is the expected behavior).  Here is a small test of that: startup_restart_tes.mw

For details on initialization files you can see ?CreateMapleInitializationFile

You could try to make a worksheet script for your students.  I know the following Maple code works in Linux to set up the init file so that it will automatically run 'with' after each restart. I think it works in Windows, but I have not tested it.

 # Uncomment the approriate line below:
 #mapleinitfile := cat(kernelopts(homedir), kernelopts(dirsep), ".mapleinit"); # Linux, Solaris, and Mac
 #mapleinitfile := cat(kernelopts(homedir), kernelopts(dirsep), "maple.ini"); # Windows (untested)

 FileTools:-Copy(mapleinitfile, cat(mapleinitfile, ".mpl.bak"));
 FileTools:-Text:-Open( mapleinitfile, 'append');
 FileTools:-Text:-WriteLine(mapleinitfile, "with(PackageName):");
 FileTools:-Text:-Close( mapleinitfile );


In many cases ?isolve can handle these sorts of problems. But for the specific problem of finding integral points on curves I suspect that it only works in the genus 0 case.

John

A slightly simpler solution than the one Acer proposes would be to use the parametric sytem tool added to SolveTools in Maple 14:

sol := SolveTools:-PolynomialSystem( {a*b^2-b+c-d-3, a^3*b^2-b+c-d^3+4, 
    a^4+b^3-b^2+c-d+2, 2*a*b^2-b+c-d-1-X}, {a,b,c,d}, domain=parametric);

sol[1] will be a (large) generic solution in terms of X. while sol[2] is a condition on X which must hold for the sol[1] to be a valid solution. In this case:

(X^4-8*X^3+24*X^2-33*X+20)*(X^4-8*X^3+24*X^2-33*X+24)*(X-2) <> 0