@Scot Gould Moderators can and do change Posts to Questions and vice versa.

1. I don't see any boundary or initial conditions. Without these, a complete solution isn't possible.
2. You should post your code as plaintext or a worksheet so that we don't have to retype it.
3. Your system seems suitable for Maple's numeric PDE solver. See ?pdsolve,numeric for the syntax.

@Robert Israel Thank you, Robert. It's nice to see you on MaplePrimes. I've missed you, although I do occasionally see your posts on StackExchange.

This distinction between the probabilities in the continuous and discrete cases is what I was trying to capture with the word "infintesimal". Perhaps that word has a more-precise mathematical definition and I'm using it incorrectly.

@Christopher2222 

I converted it back to a Post.

It's an interesting question. I'd be impressed to see an algorithmic solution. Here's an ad hoc solution that gives 6": Your first fold essentially marks off a 2-1/2 x 8-1/2 rectangle of paper. If you fold down a corner of this, it marks off a 2-1/2 x 6 rectangle.

Doing it again reduces it to 2-1/2 x 3-1/2; and then again reduces it to 2-1/2 x 1. Now that we have 1", we can get any multiple of 1, although not necessarily by folds.

The general pattern is that if it's an a x b rectangle, a diagonal fold-down of a corner can produce a min(a,b) x (max(a,b) - min(a,b)) rectangle. Here's a procedure:

FoldRectangle:= proc(a::numeric, b::numeric, maxfolds::posint:= 9)
local r:= [min(a,b), max(a,b)-min(a,b)];
   if a=b then NULL 
   elif maxfolds=1 then r
   else r, thisproc(r[], maxfolds-1)
   end if
end proc:

FoldRectangle(17/2, 11);

   [17/2, 5/2], [5/2, 6], [5/2, 7/2], [5/2, 1], [1, 3/2], [1, 1/2], [1/2, 1/2]

These are just the sizes possible by a sequence of diagonal fold-downs of corners. If we allow folding in half, there are many more.

My procedure above is akin to a primitive subtraction-only form of Euclid's GCD algorithm. Compare with finding the GCD of 17 and 22.

This reads like it was intended to be a Post instead of a Question. If it's a Question, I don't see what exactly the question is.

@Earl If you feel that way, then you should give Kitonum's Answer a Vote Up, as I have.

@vv Brian wrote:

• I modified the objective using this methodology:.... I'd like to make a procedure out of it....

I understood the challenge to be to take the StackExchange post and make a procedure of it. That is, a procedure that takes an objective that contains abs but is otherwise linear and converts it into a new linear objective plus additional constraints. The procedure that I wrote is generally useful could easily be made a part of Optimization; it isn't just ad hoc this problem.

Regarding the integer option: Solving this as an LP produces the correct integer results. This often happens with an ILP. It is interesting that this problem when solved as an ILP by Optimization:-LPSolve actually uses significantly fewer iterations. This may just be because of the "toy" size of the problem.

@Lali_miani Your worksheet only contains the output of your expression, and for reasons that I don't understand, I can't copy-and-paste it to an input region to work with it. Would you please edit it so that it contains your input, and upload it again?

You said that you want the "sign" of this expression as well as its simplification. "Sign" has many meanings in Maple, so could you be more precise? Its principal meaning in Maple is the sign of the leading coefficient of a polynomial; however, this isn't usually what people want when they say "sign".

@brian bovril Your challenge is solved in a new Answer below.

@neek 

a) The procedure ifactor has something called a "remember table". It remembers whatever results it has computed up until the next garbage collection. The procedure ifactors simply calls ifactor and reformats its output. So the factorization isn't being redone.

b) You generally want to suppress the implicit printing of the output of the interiors of loops, and explicitly print just the output that you want. The suppression is done by ending the whole loop with a colon rather than a semicolon. The printing is done by one of Maple's four explicit printing statements: print, printf, lprint, and userinfo.

c) Yeah, that center-justified thing is a nuisance! Formatted printing is a bit awkward in Maple 11. It's a little bit easier with the modern Typesetting package. Here's one option that generates 1D ASCII output, which means that the exponents won't be raised:

ifactor_sorted:= (n::integer)-> 
   sort(ifactor(n), map(``, sort(map2(op, 1, ifactors(n)[2]))))
:
f:= n-> n!:

for j to 23 do
   printf(
      "%-5d %s\n", 
      j, 
      StringTools:-Remove(
         c-> evalb(c in {"`", "(", ")"}),
         sprintf("%a", ifactor_sorted(f(j)))
      )
   )
end do: #Remember the colon!

1     1
2     2
3     2*3
4     2^3*3
5     2^3*3*5
6     2^4*3^2*5
7     2^4*3^2*5*7
8     2^7*3^2*5*7
9     2^7*3^4*5*7
10    2^8*3^4*5^2*7
11    2^8*3^4*5^2*7*11
12    2^10*3^5*5^2*7*11
13    2^10*3^5*5^2*7*11*13
14    2^11*3^5*5^2*7^2*11*13
15    2^11*3^6*5^3*7^2*11*13
16    2^15*3^6*5^3*7^2*11*13
17    2^15*3^6*5^3*7^2*11*13*17
18    2^16*3^8*5^3*7^2*11*13*17
19    2^16*3^8*5^3*7^2*11*13*17*19
20    2^18*3^8*5^4*7^2*11*13*17*19
21    2^18*3^9*5^4*7^3*11*13*17*19
22    2^19*3^9*5^4*7^3*11^2*13*17*19
23    2^19*3^9*5^4*7^3*11^2*13*17*19*23

@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.