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

Note the similarity in the two quoting styles: In both cases, both of the functions which must initially remain unevaluated get a pair of quotes. The difference is whether just the function names (Kitonum's Answer) or the whole function calls (my Answer) are quoted. I cannot explain the efficiency difference, nor have I thought much about it.

In either case, the square brackets are superfluous. They're just a red herring for this Question. If they improve the readability of your code, feel free to use them. (Warning: Generally extra square brackets are erroneous; this is a special case.)

Like Acer, I think that most nasty multiple-quoting situations should be and can be more gracefully and more robustly handled by using procedures.

Thanks, Acer.

By making a few modifications to only the first procedure, Params, (once again, fewer modifications than I was anticipating), I was able to include support for the end-of-parameters marker $. (Another thing that I love about Maple is that the final code is usually shorter than I was anticipating.) Including support for keyword parameters is also possible, but I don't see how they could be meaningfully used in this iteration scheme. Anyway, here's just the new  procedure:

Params:= proc(f::procedure)
description 
    `Extracts a procedure's parameter names, safely localized`
;
option remember;
local 
    PSq:= op(1, ToInert(eval(f))), #_Inert_PARAMSEQ(...)
    r:= [op(map(Param, PSq))], #parameter names as strings
    `$`:= evalb(r[-1] = "$") #Is end-of-parameters `$` used?
; 
    if `$` then r:= r[..-2] fi; #It's not really a parameter.
    return   
        convert~(parse~(r), `local`), #localized parameter names 
        PSq,  #exact inert parameter sequence
        `$` or hastype(PSq, specfunc(_Inert_ASSIGN)) #Is `proc` needed?
end proc
:    

@auliani3 Oops, you're right: Brian's posted worksheet does not use LPSolve to solve the integer linear program (ILP) for the 2- or 3-route cases. (It's easy to miss a detail like that while scanning a three-year-old thread.) I'll see if I can do something with it. But note that a small number (substantially less than the number of deliveries but greater than one) of routes (or truckloads) is computationally harder than the one-route case, which is known as a travelling salesman problem (TSP); so I don't know if LPSolve is up to the task. Ad hoc combinatorial solutions such as VV's do not use the huge number of decision variables that an ILP uses, and thus they're often more practical for small problems.

The posted textbook pages are incomplete and difficult to read, so maybe you can answer this for me: Does the cost of a trip include driving the empty truck(s) back to the warehouse? It seems that cost is equivalent to distance in this problem (which is likely a reasonable approximation of reality). But both storing the empty truck(s) near their final delivery point(s) (as with a one-way van rental) or driving them back to the warehouse seem like realistic cost-effective possibilities.

@acer The same factoring trick works for the next Fermat prime, 257:

factor(convert(cos(Pi/257), RootOf), sqrt(257));

Now you have two degree-64 polynomials (FWIW).

With a few modifications (fewer than I was anticipating), we can preserve the exact parameter sequence of the input procedure, meaning that the output procedure will include any parameter type declarations and default-value parameter assignments from the input. This involves a "transplant surgery" of the parameter sequence between the inert forms of the input and output procedures.

Params:= proc(f::procedure)
option remember;
local 
    PSq:= op(1, ToInert(eval(f))), #_Inert_PARAMSEQ(...)
    r:= [op(map(Param, PSq))]
; 
    if r[-1]="$" then
        error "end-of-parameters marker $ not allowed"
    else
        convert~(parse~(r), `local`), 
        PSq, 
        hastype(PSq, specfunc(_Inert_ASSIGN))
    fi
end proc
:
#This didn't need any changes. I just changed the indentation:    
Param:= (e::function)->
    if e::specfunc({_Inert_NAME, _Inert_ASSIGNEDNAME}) then 
        op(1,e)
    elif e::specfunc({_Inert_ASSIGN, _Inert_DCOLON}) then 
        op(thisproc(op(1,e)))
    elif e::specfunc(_Inert_SET) then
        error "keyword parameters not allowed", FromInert(e)
    else 
        error "unknown InertForm", e
    fi
:
Iter:= proc(f::procedure, n::nonnegint, p::posint:= 1)
local P, PSq, proc_flag, body, form;
    if n=1 then return eval(f) fi;
    (P, PSq, proc_flag):= Params(f);
    body:= 
        `if`(n=0, P[p], f(P[..p-1][], thisproc(f, n-1, p)(P[]), P[p+1..][]))
    ;
    form:= `if`(proc_flag, proc(_P) _F end proc, _P-> _F); 
    FromInert(subsop(1= PSq, ToInert(subs(_P= P[], _F= body, eval(form))))) 
end proc
:
#Examples:
y:= 1: #Global assigned value, for testing

for k from 0 to 3 do
    Iter((x::{name, function}, y, z)-> f(x,y,z), k) 
od;  
     (x::{name, function}, y, z)-> x 
     (x::{name, function}, y, z)-> f(x, y, z)
     (x::{name, function}, y, z)-> f(f(x, y, z), y, z)
     (x::{name, function}, y, z)-> f(f(f(x, y, z), y, z), y, z)

#If there are parameters with default values, then both the input and
#return procedures must be in proc form:
for k from 0 to 3 do 
    Iter(
        proc(x::{name,function}, y, z::{name,function,posint}:= 3) 
            f(x,y,z) 
        end proc, 
        k, #kth iterate
        2  #Iterate on the 2nd position
    ) 
od;
proc (x::{name, function}, y, z::{name, posint, function} := 3) 
    y 
end proc
proc (x::{name, function}, y, z::{name, posint, function} := 3) 
    f(x, y, z) 
end proc
proc (x::{name, function}, y, z::{name, posint, function} := 3) 
    f(x, f(x, y, z), z) 
end proc
proc (x::{name, function}, y, z::{name, posint, function} := 3) 
    f(x, f(x, f(x, y, z), z), z) 
end proc

@auliani3 There are 2- and 3-route solutions both in Brian Bovril's integer linear programming worksheet and in VV's "brute force" plaintext code.

@acer If by "nice form" you mean with no "large" square roots (i.e., no square roots of non integers), I can get that for sin(Pi/7) with evala(Normal(simplify(...))). In the following worksheet, `CPi/14` stands for cos(Pi/14), etc.
 

Download sin_Pi_over_7.mw

I don't know how it could happen, but it looks like displayprecision was set to 7, but only inside the plot window. Yeah, it could be a bug, but there's much less chance of fixing it if it's not known how to reproduce it.

@tomleslie Thank you, Tom, for stepping up.

@Stretto Using 1D Input (aka Maple Input), enter the command that I originally gave, a %/ b * c. If you don't know what 1D Input means, I'll explain later. 

This should work in any input mode: 

`%/`(a,b)*c

but hopefully you won't need to "go there".

My comments about needing parentheses and needing to see the worksheet pertained to your examples with 3s and exponents, not to your original Question.