@Earl I just noticed that the Question header says Maple 2016. I don't know why that is, because the OP has said previously that they have Maple 2019. The code I gave works in 2019. My 3rd example also doesn't work in 2016.

Can you give a meaningful example of legend entries that you would want on an inequal plot? (I wouldn't consider a one-entry legend meaningful; there must be at least two entries.)

We've been telling you for years now: Stop using evalm! Stop using linalg! But you never learn. You ask essentially the same handful of Questions over and over, year after year. 

@Carl Love Three addenda to my Answer:

1. As Acer pointed out, the tabs bar that I speak of doesn't appear if only one worksheet is open. Since the chance that I have only one open at the time of a kernel crash is near nil, this isn't an issue for me.

2. I think that the stop button on the tool bar will only interrupt Maple-level code, not compiled code (I'm not absolutely sure about this). If you press it while compiled code is running, the interruption doesn't occur until control comes back to Maple-level. But you can always kill a kernel the from the OS, such as with WIndows Task Manager.

3. If there's a long queue of screen output to display after the kernel has finished with your code, the stop button unfortunately does nothing. In that case, you're out of luck and need to kill the GUI (from, say, Windows Task Manager).

I remember old user interfaces / OSs (pre-Windows, pre-Maple) for which there was a control key (such as Ctrl-O) to discard the rest of the output queue. Something like that is needed.

@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