You specify that H(t) is a column vector and A is a row vector. Under those conditions, H(t).H(t)^%T.A doesn't make sense. Please clarify.

This Reply is not meant to accuse you of anything, but the error that you show has commonly been reported here for the past few months, and it's been associated with invalid license issues. So, you'll need to contact customer service to resolve it.

The failure is a more-complex issue (which I don't understand) than just the name of the constant. Even if the constant is replaced with an explicit constant, such as 1, the odetest will still fail.

Basic set theory tells us that A=B implies f(A)=f(B) for any f, and simplify should recognize this triviality. So, I'd call it a bug.

I see that I've been removed from your "special request" list.

Do you need to know the numbers of the duplicates? Or is it sufficient that the duplicates simply be removed?

@mmcdara It seems to me that Acer's Answer still applies perfectly to your modified Question. Is there still anything to clear up?

@Kasp262e Then what's the point of your 10^(n-i)? They make the equation 100*k_1 + 10*k_2 + k_3 = 123, not k_1 + k_2 + k_3 = 123 (assuming that you've corrected your indexing syntax from k_i to k_||i as instructed by Mmcdara; it's impossible to index k_i by i).

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