In particular I'm thinking of problems introduced by implicit multiplication:
x y means x*y, but xy is a single name; x(y+z) is the function x applied to y+z, while
sin (x) is sin*x.  See e.g.
www.mapleprimes.com/forum/how-do-i-get-rid-of-unable-to-match-delimiters-error-message (starting with Doug Meade's first comment) and
www.mapleprimes.com/forum/solvingvariable.

Actually what they can control is whether the expression looks like it has been written correctly.  Unfortunately, that is not the same thing as "has been written correctly".  This area is full of traps for the unwary, as has been discussed here many times. 

Actually what they can control is whether the expression looks like it has been written correctly.  Unfortunately, that is not the same thing as "has been written correctly".  This area is full of traps for the unwary, as has been discussed here many times. 

Aha!  What I didn't realize was that your eqn1 was (up to roundoff error) a multiple of the determinant of eigen1.   So you can disregard what I wrote in the previous comment. 

But now, what are m[1], ..., m[4] in your bdydet?  Are they the same as m?

Aha!  What I didn't realize was that your eqn1 was (up to roundoff error) a multiple of the determinant of eigen1.   So you can disregard what I wrote in the previous comment. 

But now, what are m[1], ..., m[4] in your bdydet?  Are they the same as m?

You assigned arr as a one-dimensional Array of floats.  convert(arr, listlist) actually just makes this into a list, as it is just a one-dimensional structure.   See the second example in the help page ?convert,listlist, which also produces a list rather than a listlist.  Hmm, this is indeed rather strange.  I have an old Maple V Technical Reference Manual, where the same example B is given, but with a different result: [8, 7, 6, 12].  Apparently the functionality of convert(..., listlist) was changed at some point without changing the help page.

The incorrect C translation of iquo is obviously a bug.  I hope you'll submit an SCR.  Of course you could try

> p := iquo(p,2);
  r := p mod 2;

Random can be done easily.  On the other hand, there are only five regular polyhedra, and thirteen Archimedean solids (other than prisms and antiprisms).

> N := 100:
  X,Y,Z:= seq(Statistics:-Sample(Normal(0,1), N), i=1..3);
  Pts:= <seq(<X[i]|Y[i]|Z[i]>/sqrt(X[i]^2+Y[i]^2+Z[i]^2), i=1..N)>; 
  plots[pointplot3d](Pts,colour=black,symbol=box,symbolsize=4);

Random can be done easily.  On the other hand, there are only five regular polyhedra, and thirteen Archimedean solids (other than prisms and antiprisms).

> N := 100:
  X,Y,Z:= seq(Statistics:-Sample(Normal(0,1), N), i=1..3);
  Pts:= <seq(<X[i]|Y[i]|Z[i]>/sqrt(X[i]^2+Y[i]^2+Z[i]^2), i=1..N)>; 
  plots[pointplot3d](Pts,colour=black,symbol=box,symbolsize=4);

Random can be done easily.  On the other hand, there are only five regular polyhedra, and thirteen Archimedean solids (other than prisms and antiprisms).

> N := 100:
  X,Y,Z:= seq(Statistics:-Sample(Normal(0,1), N), i=1..3);
  Pts:= <seq(<X[i]|Y[i]|Z[i]>/sqrt(X[i]^2+Y[i]^2+Z[i]^2), i=1..N)>; 
  plots[pointplot3d](Pts,colour=black,symbol=box,symbolsize=4);

It sounds like you have two equations in two unknowns, r and x.  If they are polynomials in both variables, Maple should be able to handle this using solve, getting the solutions in terms of the roots of a polynomial in one variable (probably of high degree).  Even if they are not polynomials, it should be possible to locate the solutions, at least using fsolve.  I could say more if I could see your actual equations.

It sounds like you have two equations in two unknowns, r and x.  If they are polynomials in both variables, Maple should be able to handle this using solve, getting the solutions in terms of the roots of a polynomial in one variable (probably of high degree).  Even if they are not polynomials, it should be possible to locate the solutions, at least using fsolve.  I could say more if I could see your actual equations.

Perhaps this is an improvement:

> analyticReconstruct:= proc(U,X,Y,Z)
    if simplify(diff(U,X$2)+diff(U,Y$2)) <> 0 then 
       error "%1 seems not to be harmonic", U
    end if;
    limit(eval(U - I*int(diff(U,Y),X), X = Z - I*Y), Y=0)
   end proc;

For example:

> analyticReconstruct(
     (sin(x)*cosh(y)*x+cos(x)*sinh(y)*y)/(x^2+y^2),x,y,z);

sin(z)/z

Perhaps this is an improvement:

> analyticReconstruct:= proc(U,X,Y,Z)
    if simplify(diff(U,X$2)+diff(U,Y$2)) <> 0 then 
       error "%1 seems not to be harmonic", U
    end if;
    limit(eval(U - I*int(diff(U,Y),X), X = Z - I*Y), Y=0)
   end proc;

For example:

> analyticReconstruct(
     (sin(x)*cosh(y)*x+cos(x)*sinh(y)*y)/(x^2+y^2),x,y,z);

sin(z)/z

The roots of a quartic polynomial can be obtained "analytically", or more precisely as expressions involving radicals, but these are usually too complicated to be of much use.  For example, try

> solve(x^4 + x - 3 = 0, explicit);

If there is only one variable, and you want numerical values for the roots, use fsolve instead of solve.  Thus

> fsolve(x^4 + x - 3 = 0);

I'm curious about how determinant=0 corresponds to a unique solution.  Usually
it's the opposite: determinant=0 means the solution, if any, is nonunique.

The roots of a quartic polynomial can be obtained "analytically", or more precisely as expressions involving radicals, but these are usually too complicated to be of much use.  For example, try

> solve(x^4 + x - 3 = 0, explicit);

If there is only one variable, and you want numerical values for the roots, use fsolve instead of solve.  Thus

> fsolve(x^4 + x - 3 = 0);

I'm curious about how determinant=0 corresponds to a unique solution.  Usually
it's the opposite: determinant=0 means the solution, if any, is nonunique.