Do you want to test whether a matrix is a partition matrix, or do you want to construct a partition matrix?

I don't see any problem

It's not just for Library routines, it also works for procedures you write yourself. The "line number" in this case is what Maple's showstat considers to be the line number, without regard to how you formatted the procedure.

> f:= proc(x) local y; y:= 0; x/y end proc;

   f(1);

Error, (in f) numeric exception: division by zero

> tracelast;
 f called with arguments: 1
 #(f,2): x/y
Error, (in f) numeric exception: division by zero

 locals defined as: y = 0

It's not just for Library routines, it also works for procedures you write yourself. The "line number" in this case is what Maple's showstat considers to be the line number, without regard to how you formatted the procedure.

> f:= proc(x) local y; y:= 0; x/y end proc;

   f(1);

Error, (in f) numeric exception: division by zero

> tracelast;
 f called with arguments: 1
 #(f,2): x/y
Error, (in f) numeric exception: division by zero

 locals defined as: y = 0

You may have intended that alpha and omega are the real and imaginary parts of s, but you didn't tell Maple that!  invlaplace sees something that doesn't have the variable s in it, and considers it as a constant.

You may have intended that alpha and omega are the real and imaginary parts of s, but you didn't tell Maple that!  invlaplace sees something that doesn't have the variable s in it, and considers it as a constant.

Actually for periodic functions you would use a Fourier series, not a Fourier transform.  A (classical) Fourier transform would require a function that is integrable or square-integrable, although the Fourier transform in the sense of tempered distributions can handle functions bounded by polynomials.  The Laplace transform works for a function on [0, infty) that is bounded by an exponential, which is a much weaker condition.  For example, exp(t) does not have a Fourier transform, but it has a Laplace transform.

Actually for periodic functions you would use a Fourier series, not a Fourier transform.  A (classical) Fourier transform would require a function that is integrable or square-integrable, although the Fourier transform in the sense of tempered distributions can handle functions bounded by polynomials.  The Laplace transform works for a function on [0, infty) that is bounded by an exponential, which is a much weaker condition.  For example, exp(t) does not have a Fourier transform, but it has a Laplace transform.

mod has lower binding strength (on the left) than the arithmetic operators, so i + j mod M is parsed as (i + j) mod M.

mod has lower binding strength (on the left) than the arithmetic operators, so i + j mod M is parsed as (i + j) mod M.

@kpassi : The reason you see nothing about this on the help page ?eval is that this ~ construction actually has nothing to do with eval.  It's a general mechanism for making a function operate elementwise over a ist, set, table, Array, Matrix, or Vector.

Thus  x =~ [9,10] produces [x=9, x=10], and f~(a, x =~[9,10]) produces [f(a,x=9), f(a,x=10)].

See the help page ?operators,elementwise

@kpassi : The reason you see nothing about this on the help page ?eval is that this ~ construction actually has nothing to do with eval.  It's a general mechanism for making a function operate elementwise over a ist, set, table, Array, Matrix, or Vector.

Thus  x =~ [9,10] produces [x=9, x=10], and f~(a, x =~[9,10]) produces [f(a,x=9), f(a,x=10)].

See the help page ?operators,elementwise

Once you have lists of digits, comparing them with `=` within a procedure should be very fast (because it's really just a question of comparing the addresses), as long as you're careful not to evaluate the lists more than once. The inefficient part is the conversion to a list of digits, if you do it with convert(..., base, 10).  Much faster: convert to a string, then to a list of characters.  Thus:

Perms:= proc(x,y)
   evalb(sort(StringTools[Explode](convert(x,string)))=sort(StringTools[Explode](convert(y,string))))
  end proc;

Once you have lists of digits, comparing them with `=` within a procedure should be very fast (because it's really just a question of comparing the addresses), as long as you're careful not to evaluate the lists more than once. The inefficient part is the conversion to a list of digits, if you do it with convert(..., base, 10).  Much faster: convert to a string, then to a list of characters.  Thus:

Perms:= proc(x,y)
   evalb(sort(StringTools[Explode](convert(x,string)))=sort(StringTools[Explode](convert(y,string))))
  end proc;

1000. and 1e+4 are floats, 1000 is an integer.  These are two of the basic data types in Maple (and, with some variations, in most other computer languages).