@neek Yes, InertForm doesn't exist in Maple 11.

@mbras You wrote:

•  Solutions so far when they exist have had relatively small entries in numerator and denominator < 25.

I think Modular with float[8] is still probably the fastest way. To get rational solutions, Chinese remaindering is done with (IIRC) a variety of large distinct prime moduli such that their product is greater than the LCM of all denominators. Anyway, 8-byte IEEE-754 computations are likely faster than 4-byte integer computations simply due to the tremendous engineering effort that has been put into the former.

• I have been using Matrix, does this effect the use of LinearSolve or just construction?

It only effects the construction time. The objects that are constructed are identical regardless of which constructor is used, so the constructor has no effect on the time of subsequent computations.

• The construction has been relatively quick, with LinearSolve being the bottleneck.

Using Matrix(...) only has a measurable effect on performance when it's used repeatedly, like in an inner loop.

When you say LinearSolve, do you mean LinearAlgebra:-LinearSolve or LinearAlgebra:-Modular:-LinearSolve?

• Do you know much about the modular method?

Yes.

• Is it also quick at verifying when a solution does not exist?

I don't know; it's certainly worth exploring. Like Axel, I suggest that you check the rank; I suspect that's the fastest way. A solution X to A.X = B exists iff the rank of A equals the rank of the augmented matrix < A | B > (and that notation is a reasonably good way to create the augmented matrix in Maple, although I'd use an inplace construction if I was doing it repeatedly).

@mbras So, you want to know whether an exact rational solution exists; floating-point arithmetic is not sufficient? AFAIK, Maple hasn't implemented any sparse exact-rational solvers. LinearAlgebra:-Modular is superbly fast for dense exact problems; I wouldn't be surprised if it were the best in the world.

There are three fine-tuning tricks that I know for getting more speed from Modular:

1. Declare all matrices with order= C_order.
2. Declare all matrices/vectors with datatype= float[8]. This is counter-intuitive. It works because processors have been extremely optimized for IEEE-754 double precision. The computations are still exact integer if the modulus is less than 2^25 (approximately the square root of the IEEE-754 mantissa). Modular takes care of keeping it exact; you don't have worry about it.
3. Avoid using the constructors Matrix(...) or Vector(...). Instead, use rtable(...) or the angle-bracket constructors <...>, `<,>`(...), and `<|>`(...). The former are coded in high-level Maple; the latter are kernel operations.

@brian bovril You wrote:

• I think your problem is likely non-linear...

Why do you think so? My experience with logistics problems, which is probably less than yours, is that they are usually either LP, ILP, or intractable/combinatorial (NP-complete or NP-hard) such as the classic travelling salesman problem. I don't recall seeing many that are classic NLP, i.e. nonlinear with differentiable objective and constraints.

@ Yes, this is because the command

Y:= Matrix((m,n), symbol= y);

creates a Matrix filled with variables y[i,j], 1 <= i <= m, 1 <= j <= n. It is not necessary that the symbol be the lowercase of Matrix's name, but I usually do it that way to avoid confusion. Once the Matrix has been created thus, it can be used for matrix multiplication, and the final answer can be compactly stated by evaling the Matrix over the solution.

You should use userinfo instead of print: It gives you finer control over the format, and you can turn it on and off externally. Once a program is instrumented with userinfo statements for debugging, they'll never need to be removed. 

Egads, that's horrible. The command should be simply deleted ASAP until it can be replaced by a competent command. This crap serves no useful purpose in this state, and it's doing more harm than good. Not only does it give the wrong idea about limits, it also gives the wrong idea about symbolic computation. Perhaps Maplesoft should have a review panel of professional educators, and any "tutor" would need to be approved by them before being released . 

A vote up for your muck-raking efforts. 

@Kitonum The function to be plotted doesn't need to be a procedure if you nullify the true labels by including the option labels= [``$3] in the plot3d command.

@Muhammad Usman Use the three-argument form of coeff:

for i from 0 to Equation do
   C[i]:= coeff(u, x, i) = coeff(f, x, i)
end do:

@umar khan There are no real values of r such that v is also real.

@Joe Riel There's also ArrayTools:-IsZero.

The index spec in the rtable_scanblock command can be shortened to [i, ..].

@vv I modifed the code for the animation so that the memory usage is only 20M.

@Christopher2222 No, is won't work in this case. AFAIK, there are no cases where the default boolean evaluator returns a truefalse result and is returns a different result. Sometimes is can make finer distinctions in cases where the default evaluator returns an ambiguous result. That's not the case here: The default evaluator returns false because the addresses of the vectors are different; it couldn't care less about the contents of the vectors---it only checks addresses. The situation would be different if one were comparing lists rather than vectors. The evaluator still just checks addresses, but because of the way that Maple stores lists, lists that are equal are necessarily stored at the same address. How's that? When new lists (and many other structures) are created, they are compared against existing lists for matches in a part of Maple called the "simplification table." (See the "Simplification Table" section in Appendix A of the Maple Programming Guide.) That's part of the reason why it's inefficient to iteratively lenghten lists (or sequences, or sets).

@student_md You wrote:

• limit(sum(diff(Fn,Xn)*Xn,n=1..N),N=infinity)

If this expression makes sense at all, then it's equivalent to

sum(diff(F[n], X[n])*X[n], n= 1..infinity);

But I think that having an infinite number of X's is quite odd.

@umar khan You say that you want to "iterate" P(r) to find the root. That type of low-level operation is usually not necessary in Maple. The main command for finding roots is fsolve. It does the iterating in the background.