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

@mmcdara Okay, you're correct that what you want can be handled by types; properties are not needed, but instantiation still is^[*1]. The type that I wrote for RV was ad hoc---it covered the situation that I wrote it for, but not significantly more-complicated situations.

Would it suffice if the type covered any polynomial combination of one or more random variables? Then you can use this:

TypeTools:-AddType(
    RVP, #random-variable polynomial (non-constant)
    Or(RandomVariable, specop(Or(constant, RVP), {`*`, `+`}), RVP^posint)
);  

Or do you need it to cover some non-polynomial cases also?

Note that a type can be recursive, as the above. When you do this, make sure that the base cases are on the left side of an Or clause with recursive cases on the right side to prevent infinite loops. I think that an infinite loop in a type evaluation could lead to a kernel crash.

[*1] Note that in your example Z:= X+Y with X and Y being random variables that it is the structure assigned to Z, rather than the name Z itself, that has the type RV.

So, to directly Answer your titular Question: No, a name (or variable) can't "have" a nontrivial type before it's instantiated. It can only have properties. The complexity and subtlety of Maple's property system is trivial compared to that of its type system.