Do you need to make each cut all the way across whatever piece you're cutting? Or can you pull out the saw at a precise location and then finish with a perpendicular cut? The former is computationally easier because the remaining pieces are always rectangles, but also may lead to more wasted pieces. This simplification of the 2-D cutting-stock problem is known as the guillotine problem (named after the familiar simple manual paper-cutting machine, not the neck-cutting machine).

@ajfriedlan I am not sure why they aren't cleared from memory, but I suspect that it's global variables and/or remember tables internal to dsolve.

You could reduce your calls to dsolve to just 1. I think that that would save memory. Make the 4 dsolves into a single system with 4 dependent variables. Use option parameters to make i and j parameters of the system. Then for each i and j, you'd integrate all four at the same time.

@acer Thanks for catching that. I forgot about type `^`, and now I've included it with type function in the code in the Answer.

@ajfriedlan You wrote:

• So in short, square brackets are preferable to round brackets. Do I have that correct?

I wouldn't generalize it to that extent. When you're assigning to a Matrix entry, you should use square brackets.

@Moh Huda Do you have enough familiarity with this subject to say whether the input parameters used in the paper are realistic? In particular, I'm bothered by b = 5e6 mg = 5 kg of chemo drugs! Also c2 = 1e-13 and rho.= 1e-12 seem very small.

@Teep What is the significance of the weights being unique?

@Daniel S the hkoog I think that implementing weights by making multiple copies of the data is a crude and very inefficient hack that might be useful if you don't have access to the source code. If you do have access, it should be easy to multiply the distances by the weights.

@dbauer Here's my guess: Since there would be little reason for the existence of MapleTA if it didn't accept formulas, I'd guess that it always has accepted them. 

@nm Make a temporary substitution of 0, like this

selectremove(has, (lhs-rhs)~(subs(0= _0, ode)), diff(y(x),x));
ode_new := subs(_0= 0, %[1] = - %[2]);

This works regardless of whether there is a 0. If there's no 0, it changes nothing. The bug only occurs when there's 0 on one side and a single term on the other.

@Teep By weights, do you mean that the focal point of each cluster should be its center of mass?

While trying to add a Product tag to your Question, I discovered that MaplePrimes has no check box for MapleTA. That should be fixed.

You're beating around the bush. If you want help, just post your files here.

@deniscr Obviously my Answer can't be applied to the a=b case. I should've said something about that in my Answer.

Yes, SolveTools:-SemiAlgebraic is often extremely slow.

@Moh Huda I am a mathematician, not an oncologist, so I can only offer some guesses to answer your questions.

1. Why after around 75 mg/day chemo infusion the immun infusion rate do not have any effects?

Because the higher chemo doses kill too many of the immune cells.

2. Also for the time cured, why in the long term after 10^3, the immuno rate infusion for s_inf=7*10^5 behaves weird (comparison plot 5a and 5b)?

At the higher infusion rate, the cure is in under 3000 days (approx.). That explains the tail on the right in 5b. Since they're cured, the amount of time on chemo is reduced, so total amount of drugs used D__chemo is reduced. That explains the tail on the left in 5a.

Does that make sense?

@Mac Dude But there are nontrivial solutions, for example 

{j= 1, m= 1, a= 1, b= -1, z=1, t= 1, x= -1, y= 0}