@Adam Ledger I don't see your point. The goal is to get a square wave, not a staircase.

@acer Shouldn't your `mod/ceil` procedure have ceil(a) where it now has ceil(x)?

@Rouben Rostamian  There are a few more problems:

1. The last two initial/boundary conditions aren't orthogonal to the boundary, i.e., they should each specify the other independent variable.
2. With these conditions, you need to specify the range of the space variable. One of the two endpoints of the range must be 0.
3. You may need to specify which of the independent variables is the time variable; not sure. It certainly wouldn't hurt to do so.

The diagram in the link says nothing about A and B other than that they are on that circle of intersection. More-specific information is needed.

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.