@Kasp262e Don't you mean k_1 = 1, k_2 = 2, k_3 = 3?

@vv Could you please give an example of a "not complicated" formulation for a 2-D problem? You may even make these simplifying assumptions:

• Stock is always identically sized rectangles.
• Output is always rectangles (but not necessarily identically sized).
• Cuts are guillotine style, i.e., all the way across and orthogonal to the dimensions.
• No optimization need to be made with respect to the kerf. Just assume that the kerf is waste on all four sides of each output piece (in other words, 2*kerf is added to both dimensions of every output piece). (A true optimal solution would recognize that kerf only needs to be wasted for 2 or 3 sides of most pieces.)

The problem is NP-hard, so there's no possibility of getting to the true optimum (in general) by means substantially simpler than "try all possibile arrangements". But computationally simpler practical solutions exist (and it's an active area of research), which aren't necessarily truly optimal.

@Christopher2222 The guillotine method only produces rectangles, both for the waste pieces and the used pieces. The non-guillotine solution would often produce less total waste, with highly irregularly shaped non-convex waste pieces. Due to mechanical limitations of industrial processes, cutting all the way across is often the only way. In these cases, the guillotine solution has the added benefit of being computationally simpler.

Vote up. I can reproduce this new-to-Maple-2019 behavior. I had noticed it before you mentioned it. It is a nuisance because there should be an easy way to convert output to 1-D input.

@vv You asked:

• Could you please tell what are the benefits of using objects in this case? An advantage seems to be the possibility to have several graphs. But the module could be adapted for this.

Yes, you have correctly identified the primary benefit of using objects in this case. And yes, a similar effect can be achieved by writing it as a procedure that returns a module (a so-called "module factory"), and this was common before the introduction of objects in Maple 16. A significant benefit of an object over a module factory is that with objects the dynamic memory allocation only applies to the module locals (including exports) that are not declared static.

A minor benefit in this case is that object procedures automatically recognize their own objects. That is, I can call Path(FW, ...) rather than FW:-Path(...). This benefit is much more significant when the object procedures are infix operators.

There are a few other factors not related to the object/module distinction that make my code more complicated than yours:

1. My Next matrix stores the actual vertex labels rather than their indices, so that the paths are listed by the actual vertex names. (Although I now see an easier way that I could've handled this.)
2. I packed all the dynamic object data into a Record. The only benefit of this is that it shortens the ModuleCopy, and the code doesn't need to pay any attention to the order of the data. The drawback of this is the need to use the double :- syntax in several places. (It would be trivial to get around this drawback by exporting access procedures.)
3. I initialize directly from the edge set rather than the adjacency or weight matrix. Though, I do prefer the way that you handled this issue. It just hadn't occured to me yet.

@Scythor The procedure Path that you show is not specific to unweighted graphs. The implementation of Path that I give in an Answer below works for any graph regardless of whether it's connected, directed, or weighted.

Please give your articles meaningful titles. For this one, I suggest "Statistics fails to reject invalid parameter values". With a generic or meaningless title, the chance that someone will be able to find your article in the distant future is substantially reduced.

@tomleslie If the shortest path between any two vertices were length 1, the graph would be complete. The OP didn't say it was complete.

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.