About RobPratt

RobPratt · ‎04-30-2012

1. The QP solver is production in 9.3, so that is another reason to upgrade. 2. I am still not sure what you were running before, but I'm glad to see that you are getting run times in seconds now. 3. It is OK not to drop the rc and avgc constraints when solving the MILP, but keeping them unduly stresses the MILP presolver. The QP step finds an optimal continuous solution. The MILP step finds the closest integer solution to that QP solution and doesn't need to know that the first solution came from the QP solver. If you drop the constraints, you will need to recompute the std after the MILP solve. If you use IMPVAR instead, this computation is automatically computed for you. 4. On my machine, I see about a 2-fold speedup between 9.2 and 9.22. I get another 2-fold speedup from using IMPVAR, for a 4-fold speedup in total. 5. If you change the objective from quadratic to something non-quadratic nonlinear, then you need to use one of the NLP solvers. 6. The default MEMSIZE is typically too small for optimization problems. You can set it explicitly, as described here: http://support.sas.com/documentation/cdl/en/ormpug/63975/HTML/default/viewer.htm#ormpug_optmodel_sect065.htm By the way, some of your observations have missing values. I replaced them with 0 to avoid errors, but you probably want to do something else.

RobPratt · ‎04-27-2012

You almost had it correct. It should instead be: var r {i in VSET}; con rc {i in VSET}: r = sum {j in WSET} values[i,j] * weights - margins; var avg; con avgc: avg = sum {k in VSET} r / NOBS; By the way, to invoke the QP solver, you should explicitly specify solve with QP; instead of just solve; I realize my tom022012_heur.sas code had just SOLVE, but SOLVE WITH QP is more efficient since otherwise you get the default NLP solver instead of the more specialized QP solver. And be sure to drop the rc and avgc constraints if want to then solve the subsequent MILP. This takes only a few seconds to solve with 20000 observations in 9.2 on my machine. But I'm a bit confused about your run times---how did you run this without impvar and without correct var/con replacement? Can you please post the code you ran?

RobPratt · ‎04-26-2012

Please provide your input data with 1000 observations, and I will take a look.

RobPratt · ‎04-25-2012

Can you please provide your data and code? Also, what version of SAS are you running?

RobPratt · ‎04-03-2012

Yes, the positive value of Infeasibility indicates that the final solution does not satisfy the constraints. In 9.1, you should get better results with the IPNLP solver and/or the linearized formulations I sent. Also, you should initialize der to 1 (or something positive) since otherwise the default initial value of 0 leads to division by 0 at the starting point.

RobPratt · ‎04-03-2012

Yes, that is a very old version. We have had several SAS/OR releases since then, and implicit variables were introduced in SAS/OR 9.22. You should definitely upgrade to 9.3, but until then here is a workaround. If you have an implicit variable: impvar x {i in ISET} = some function of other variables; Then replace with an explicit variable and constraint: var x {i in ISET}; con x_con {i in ISET}: x = some function of other variables;

RobPratt · ‎04-03-2012

Your m = 0 should be m = 1, and you haven't used p anywhere. Here are three approaches that should help you proceed. The first approach is closest to your model: proc optmodel PRESOLVER=NONE; set I; number ID{I}; number r{I}, p{I},m{I},a1{I}, a2{I}; var der{I} init 1; read data test into I = [_n_] ID = _n_ r = r a1 = a1 a2 = a2 p=p m=m; var d >=-1000 <=1000; con der_con {j in I}: der = if m =1 then 1+(r +d)/3 else der[j-1]*(1+(r +d)/3); impvar der1 {j in I} =(a2 -a1 )/der ; impvar value=sum{k in I} der1 ; min g=abs((value/2)-1); solve; print d; quit; The second approach avoids the absolute value function, which is nondifferentiable and causes difficulty for smooth NLP solvers. proc optmodel PRESOLVER=NONE; set I; number ID{I}; number r{I}, p{I},m{I},a1{I}, a2{I}; var der{I} init 1; read data test into I = [_n_] ID = _n_ r = r a1 = a1 a2 = a2 p=p m=m; var d >=-1000 <=1000; con der_con {j in I}: der = if m =1 then 1+(r +d)/3 else der[j-1]*(1+(r +d)/3); impvar der1 {j in I} =(a2 -a1 )/der ; impvar value=sum{k in I} der1 ; var gplus >= 0; var gminus >= 0; con g_con: (value/2)-1 = gplus - gminus; min g = gplus+gminus; solve; print d; quit; The third approach linearizes the absolute value using inequalities instead of equality: proc optmodel PRESOLVER=NONE; set I; number ID{I}; number r{I}, p{I},m{I},a1{I}, a2{I}; var der{I} init 1; read data test into I = [_n_] ID = _n_ r = r a1 = a1 a2 = a2 p=p m=m; var d >=-1000 <=1000; con der_con {j in I}: der = if m =1 then 1+(r +d)/3 else der[j-1]*(1+(r +d)/3); impvar der1 {j in I} =(a2 -a1 )/der ; impvar value=sum{k in I} der1 ; var gabs >= 0; con g_con1: gabs >= (value/2)-1; con g_con2: gabs >= -(value/2)+1; min g = gabs; solve; print d; quit;

RobPratt · ‎04-03-2012

Can you please post what you tried, including the input data set?

RobPratt · ‎04-03-2012

You are trying to use der, der1, and value as decision variables but have instead declared them as numeric parameters. Use either VAR or IMPVAR instead.

RobPratt · ‎04-02-2012

You almost got it, but you still need to force g[1] = 0. The following works: con gg {i in w}: g = if i = 1 then 0 else s1*f[i-1] + s1*g[i-1]; Or you could keep your version and then also include: fix g[1] = 0; When you use IMPVAR, PROC OPTMODEL does the algebraic substitution for you, and the solver does not see an explicit variable or constraint.

RobPratt · ‎04-02-2012

Recursive IMPVAR is not supported until the next release of SAS/OR, due out later this year. The correct syntax will be: impvar g {i in w} = if i = 1 then 0 else s*f[i-1] + s*g[i-1]; Until then, you can instead use an explicit variable and constraint.

RobPratt · ‎03-31-2012

The second version (with fewer variables and no constraints) is more efficient. Also, depending on how different your hundreds of runs are, you might be better off doing all the looping within one PROC OPTMODEL session, instead of calling PROC OPTMODEL hundreds of times.

RobPratt · ‎03-31-2012

No, the names do not have to be the same. If they are different, say org1 and dep1 in the data set, then you can use org=org1 dep=dep1 in the READ DATA statement.

RobPratt · ‎03-30-2012

I don't see anything wrong with s[1] = ... = s[8] = 0. That is feasible to your bounds and constraints. You can use the following CON statement to declare your constraints: con c {i in w diff {card(w)}: mod(i,8) ne 0}: s = s[i+1]; Alternatively, you can omit the constraints and declare only three s variables in the first place: var s{1..ceil(card(w)/8)} >= 0 <= .8 init 1; impvar ads{i in w} = org * s[ceil(i/8)];

RobPratt · ‎03-26-2012

In program 2, you have declared ads as a numeric parameter, so the resulting objective is constant. Instead, you should declare ads as an implicit variable (and omit the FOR loop) as follows: impvar ads {i in w} = org * s;

Online Status	Offline
Date Last Visited	Monday