@acer You wrote:

• I ... save the worksheet by closing the GUI using the top corner icon (window decoration button from the OS, which often looks like an X as Carl points out). 

I was referring to closing the worksheet alone---not the whole GUI---by clicking the X that appears to the right of the worksheet's name on the tabs bar, which is the bar below the main toolbar and above the context toolbar in the Standard GUI (in Windows, at least). Not closing the GUI is a major timesaver, especially if you have several worksheets open.

• When I do this the GUI still offers me the choice to save the worksheet, even though the kernel has crashed.

And the same things happens for me when I click my X. 

@Stretto If you put the for-loop in parentheses, then it's an expression, not a statement, and printlevel truly does nothing. It's akin to the distinction between if and `if`(...). 

I'm not claiming that printlevel will completely solve your problem. But it will let you see the results of statements at all levels of nesting, including within Maple's own procedures. 

Except for top-level statements, there's no difference between separating statements with colons or semicolons. Indeed, if you view the code (for example, with showstat if it's a procedure), you'll see that all statement separators are semicolons and redundant ones are eliminated.

@Christian Wolinski I don't know what you mean. For me, your code produces simple algebraic number solutions for the 4 variables. What do you mean by "incomplete"?

Could you provide an example worksheet showing what you're looking for for at least one of your problems? You can attach a worksheet to a Reply by using the green uparrow on the toolbar.

@ddaigle321 Yes, I think that using sets of two-element lists is the better option. And yes, they would be immutable, thus identical when mathematically equal. And because of that, there'll be significant savings when those recursive structures are saved as .m files rather than text files. 

@acer I was rushing to post my Reply "Not reliable" before my battery died, and then I went to sleep. I forgot to mention that saving MultiSets to text files doesn't work either, and that's where a ModuleDeconstruct could help. I was willing to accept that .m would never work. 

@ddaigle321 

It's looking like MultiSet is not, as you said, "reliable". In particular, it doesn't have a ModuleDeconstruct, which would make saving to a file easier. Your saved-file-reading problem is indeed a flaw of MultiSet. A primitive deconstructor would be

MSD:= MS-> subsindets(MS, 'MultiSet', e-> %MultiSet({convert(e, list)[]}));

The % creates an inert form and the value command can then be used for reconstruction. I don't think that that'll automatically deconstruct the embedded levels of a recursive MultiSet; if you need that, I can work on it.

That deconstructor has the side benefit of converting the MultiSet into an immutable structure, so mathematically equal copies will be automatically identified (to the same address).

If you have a question about what you just posted, then state that question.

If the attached worksheet was created with a beta-test version of Maple, then it's not appropriate to post it in a public forum, and it must be deleted.

Giving your Post/Question an appropriate title such as "Maplesoft internal testing: Do not read" would help avoid confusion.

@vv @brian bovril

There's apparently some randomization used by the ILP solver, and it doesn't always give the true optimum. (If it always found the true optimum, it'd be solving an NP-hard problem.) I've found randomize keys (aka "seeds") that work for each case, and I'll post a worksheet that makes use of those after I make some retrofits (for Maple 15, ugh). Also, the solution, whether any solution is given, and the time taken is very senstive to the options feasibilitytolerance, integertolerance, and assume= nonnegative and also somewhat sensitive to depthlimit. Those are the options that I've played with; it may be sensitive to others as well.

@vv 

1. If your comment about the triangle inequality is because I need to recheck the whole matrix after making any changes: Yes, I realize that, and I'll recode it; but, in this case, it happens that one pass through the matrix is enough. If your comment is about another aspect, please explain.

2. Do you know what the artificial variables u[i] represent in the physics of the problem? Should they be allowed to go negative? Your formulation of them is not the same as the anti-subtour variables and constraints shown in the VRP Wikipedia article.

@auliani35 What is your Maple version?

@Carl Love Using the same worksheet for 3 loads (by setting K:= 70), I obtained the following solution. I also removed the constraint assume= nonnegative, which only affects the artificial variables. Those are the only changes to the worksheet. 

LPSolve: calling ILP solver
LPSolve: number of problem variables 360
LPSolve: number of general linear constraints 319
LPSolve: feasibility tolerance set to 0.1e-4
LPSolve: integer tolerance set to 0.10e-4
LPSolve: infinite bound set to 0.10e21
LPSolve: iteration limit set to 3395
LPSolve: depth limit set to 540
LPSolve: node limit set to 0

memory used=12.00MiB, alloc change=6.92MiB, cpu time=6.59m, 
real time=6.59m, gc time=0ns

That memory usage seems incredibly low!

Final solution (capacity = 70  =>  loads = 3):

Routes:= [entries(Tour)];
      Routes := [[1, 4, 3, 7, 1], [1, 5, 8, 6, 9, 11, 10, 1], [1, 2, 1]]
COST = Sol[1];
                          COST = 3804

@auliani3 Your cost matrix jarak has a violation of the triangle inequality. Specifically, jarak[1,3] + jarak[3,4] < jarak[1,4]. You should check the data. In the meantime, I can correct the anomaly and proceed by assigning

jarak[1,4]:= jarak[1,3]+jarak[3,4]:

That also changes position [4,1], because it's a symmetric matrix.

The other violating triples are [1, 7, 11], [1, 9, 11], [2, 7, 8], [2, 9, 11], [3, 4, 6], [3, 4, 11], [3, 7, 8], [3, 9, 11], [4, 7, 8], [6, 9, 11], [7, 9, 11], [8, 9, 11].

@vv wrote:

• I don't know what you mean by "not well posed" in this context.

Perhaps "not standardly posed" would be better terminology.

Vote up for the interesting solution. If you persist with simplifying the sum of the derivatives of the piecewise expression, and apply the domain assumptions, Maple eventually confirms your solution.

@nm I agree that it's much better to not give a solution than to give an incorrect one.

I agree that the answer is wrong. But regarding whether it's well posed: Is it proper to have a boundary condition with a differential order the same as the highest differential order of the same independent variable as appears in the PDE?