There are no solutions to that system, you might try solving for all variables. For example, solve({eq});

Try solving for all the variables (note, gamma is considered a constant).

Is there some way to copy and paste these equations? Can you repost them as text?

For details of what algorithm was being used, I consulted the GMP documentation at http://gmplib.org/#DOC As for igcd, you have to know a little bit about how Maple does things internally. Basically, large integers are stored as GMP integers, and GMP routines are called.

For details of what algorithm was being used, I consulted the GMP documentation at http://gmplib.org/#DOC As for igcd, you have to know a little bit about how Maple does things internally. Basically, large integers are stored as GMP integers, and GMP routines are called.

Maple needs speed. It needs to be a computational platform where users can code efficient algorithms and work with very large sets of data - symbolic and numeric. It needs asymptotically fast algorithms, new tools for visualization, and a focus on efficient primitives so that Maple programs are fast. This will make the library fast. Wherever possible, these primitives should be parallelized so that sequential code achieves some parallel speedup. There is no sense in building just a pretty system. Maple has to handle the big problems of the day, or its usefulness and popularity will decline. That means any problem that can conceivably be done on a workstation, whose capacity is rapidly approaching O(10^10).

i use a 2.4 GHz system (core duo, does maple 11 take advantage of multi-core systems?). Not typically. Thanks for your worksheet. Robert Israel is correct, in this case gcd(A,B) = A, so the Euclidean algorithm is only doing one division.

i use a 2.4 GHz system (core duo, does maple 11 take advantage of multi-core systems?). Not typically. Thanks for your worksheet. Robert Israel is correct, in this case gcd(A,B) = A, so the Euclidean algorithm is only doing one division.

Maple basically just copies the input (289KB and 504KB) and calls GMP's mpz_gcd function. How is your version of the Euclidean algorithm implemented, and what are the specs of your computer ? I find it surprising that an O(n^2) algorithm runs so fast on those inputs. Magma takes .160 sec using Schoenhage's algorithm on a 2GHz Opteron. Maple's igcd is calling GMP's mpz_gcd function, which uses Weber's algorithm which is O(n^2).

Maple basically just copies the input (289KB and 504KB) and calls GMP's mpz_gcd function. How is your version of the Euclidean algorithm implemented, and what are the specs of your computer ? I find it surprising that an O(n^2) algorithm runs so fast on those inputs. Magma takes .160 sec using Schoenhage's algorithm on a 2GHz Opteron. Maple's igcd is calling GMP's mpz_gcd function, which uses Weber's algorithm which is O(n^2).

Also, Maple's performance on 64-bit Windows is currently subpar, mostly due to issues affecting GMP.

Actually, PolynomialIdeals won't work for that.  I'm not sure what would.

Actually, PolynomialIdeals won't work for that.  I'm not sure what would.

Garbage collection in Maple is automatic. Your program runs, intermediate objects are created, and then when objects are no longer referenced their memory is collected to be reused by the system. For example, when you do the following: f := x+1; f := f+1; Maple creates the object x+1 in memory, then it creates a new object (x+1)+1 = x+2 in memory, and since the original object is no longer referenced x+1 may be garbage collected. However, there is a catch. Garbage collection in Maple is "generational", which means that memory may not be recovered inside of a large complex routine until the routine terminates. One solution is to make a subroutine to perform a memory intensive part of the computation. For example, make a new procedure which executes 10 iterations of your loop. To avoid passing too many arguments, you can use lexical scoping. For example:

foo := proc(x)
local f, c, bar;
  f := x;
  c := 1;

  bar := proc(f1)
  local f;
    f := f1;
    to 10 do
      f := f+c;
    end do;
    return f;
  end proc;

   to 10 do
      f := bar(f);
   end do;
end proc;

This is a slightly long example so bear with me. The subroutine bar executes 10 iterations of f := f+c; The variable c is from foo, it is lexically scoped into bar. This way you can avoid passing a lot of variables around. We execute f := f+c; 100 times and create 100 intermediate objects, but 90% of them are created in bar and these can be garbage collected after each call to bar terminates. 10% of them are in foo and can not be garbage collected until after foo terminates. This may or may not solve your memory problem. It may be that the objects themselves are too large. But if it helps, there it is.

Garbage collection in Maple is automatic. Your program runs, intermediate objects are created, and then when objects are no longer referenced their memory is collected to be reused by the system. For example, when you do the following: f := x+1; f := f+1; Maple creates the object x+1 in memory, then it creates a new object (x+1)+1 = x+2 in memory, and since the original object is no longer referenced x+1 may be garbage collected. However, there is a catch. Garbage collection in Maple is "generational", which means that memory may not be recovered inside of a large complex routine until the routine terminates. One solution is to make a subroutine to perform a memory intensive part of the computation. For example, make a new procedure which executes 10 iterations of your loop. To avoid passing too many arguments, you can use lexical scoping. For example:

foo := proc(x)
local f, c, bar;
  f := x;
  c := 1;

  bar := proc(f1)
  local f;
    f := f1;
    to 10 do
      f := f+c;
    end do;
    return f;
  end proc;

   to 10 do
      f := bar(f);
   end do;
end proc;

This is a slightly long example so bear with me. The subroutine bar executes 10 iterations of f := f+c; The variable c is from foo, it is lexically scoped into bar. This way you can avoid passing a lot of variables around. We execute f := f+c; 100 times and create 100 intermediate objects, but 90% of them are created in bar and these can be garbage collected after each call to bar terminates. 10% of them are in foo and can not be garbage collected until after foo terminates. This may or may not solve your memory problem. It may be that the objects themselves are too large. But if it helps, there it is.