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

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