Thanks Dave. Here is a first pass

----maple----
#!/bin/bash

theargs="\"$0\"";

for var in "$@"
do
    theargs="$theargs,\"$var\""
done

# replace with your maple
/usr/local/maple12/bin/maple -q -s <<__EOM__
  NARGS:=$#-1:
  ARGS:=[$theargs][3..-1]:
  read("$1");

__EOM__
----maple----

Then

----script----
#!/usr/bin/env maple

printf("This is an example of using Maple for scripts\n");
print(NARGS,ARGS);
----script----

This is okay for "./script foo bar" and should be right for "./script 'foo bar'" too

John

An example might be choosing the the vertex of a parabola as parameters. Least squares can't fit to a and b directly:

y = (x-a)^2 + b

since the fitting equations will depend on a non-linearly. For each point on the parabola e.g. (x,y)=(-1,1) you get a quadratic equation like 1 = (a+1)^2+b.  Least squares only works on a set of linear equations.

solve does not do any numeric root finding.  If you give it a polynomial with floating point coefficient, it will convert them to complex rational numbers and compute exact representations of the roots.  Before returning the answer, it will call evalf on them so that you get floating point answers.

In the case of exact polynomials solve will factor: f(x)=g(x)*h(x) and decompose: f(x) = g(h(x)) to get polynomials of smallest degree possible.  It will then try to compute roots in terms of radicals for degrees 3 and less (or 4 and less if you use the Explicit option) and some other simple cases.  If it cannot compute the root in terms of radicals, it will return the root in RootOf representation. 

When evalf is called on a RootOf structure, it calls fsolve to numerically compute a value for the root.  fsolve uses the global root finder in RootFinding:-Isolate for real polynomials if I recall correctly and the algorithms it uses are described in the papers at the bottom of its help page.

John

If you are using Maple 12, a double integral can be entered in 1D input as a single call to int:

int(1/x, [x = y..1, y = 0..1]);
 

John

If you are using Maple 12, a double integral can be entered in 1D input as a single call to int:

int(1/x, [x = y..1, y = 0..1]);
 

John

Oops, wrong version.  I was running the example with some development code loaded.  When I run with a clean Maple 12, I definitely see memory blow up.

I suspect Acer is probably right that you can get around a lot of a the memory issues by using Arrays instead of arrays, and by avoiding repeated calls to int.

John

I ran this worksheet in Maple 12, and I did not get any memory blow up.  Memory usage seems to hold more or less constant through the loop (there was a lot of alloc and gc but total usage didn't seem to rise).

John

I can't say for sure, but unless you are doing something like very large matrix computations where you know you are going to need more than 2 GB of RAM for the computation, it is unlikely more RAM is going to help.  Like Robert says, I find that most computations that shoot up to 2GB and crash the kernel are due to combinatorical explosions of memory use and would not be satisfied with only a couple more gigabytes of RAM.

More often than not, the solution is a new algorithm, not new hardware.

John

There are not actually options to control some of the environment variables in solve but that should change eventually.  _SolutionsMayBeLost is a little harder to replace but we have been thinking about it.

John

I think, as a rule, our newer code favours named optional parameters over environment variables for user level interfaces.  I know integration and solve  have been modified in recent releases to support most of the control originally provided via environment variables through options as well with the documentation being updated to steer users to the options.

John

evalc will do the same (it implicitly assumes that variables are real):

 evalc(abs(z));

 evalc(argument(z));

John

evalc will do the same (it implicitly assumes that variables are real):

 evalc(abs(z));

 evalc(argument(z));

John

In theory, I guess one could make a forget all function doing something like:

for p in {anames('procedure')} do
      forget(p);
end do;

Things get more fiddly when one wants to make sure any remember tables of functions stored in modules are also cleared (especially if they are local module members).  But it should be possible. All the extra fiddly stuff is probably why we don't have such a function already.

John

It is already kind of possible to do that:

f(x) := 456:f(y) := 12:  f(x), f(y);

forget(f,x); f(x), f(y);

But it is quite limited.  If f has multiple arguments, you need to specify all of them; it doesn't use wildcards.  forget also cannot be called on all functions with remember tables since that information is not stored centrally: each defined function would have to be individually inspected.

However, as acer pointed out, the deeper issue here is that remembers tables should not be used on obects with last name evaluation.  That is,  we shouldn't need to have such a selective 'forget' at all.

That with problem int and functions should be fixed in the next release of Maple.

John

forget(int);  would be more appropriate here.   `int/int` has the option 'system' which means:

Option system serves to identify procedures in the Maple library that are
  considered to be "system functions", meaning functions for which the
  remember table may be deleted at garbage collection time. If this option is
  not specified for a procedure that has the remember option, the remember
  table survives garbage collections.

So gc() isn't necessarily guaranteed to work here.

John