About RobPratt

RobPratt · ‎05-09-2012

That is correct. Declarations (IMPVAR, VAR, NUM, etc.) cannot be nested in other statements (DO, FOR, etc.). See http://support.sas.com/documentation/cdl/en/ormpug/63975/HTML/default/viewer.htm#ormpug_optmodel_sect019.htm.

RobPratt · ‎05-09-2012

1. Yes, you can have multiple statements within a DO loop. 2. No, you cannot update the formula for an IMPVAR after the declaration. I gave correct syntax for the updatedRisk IMPVAR declaration in the previous reply. I think you just need a second IMPVAR statement for actualRisk. I'm not sure, but it looks to me like you might be trying to calculate your objective function by writing a DO loop. In OPTMODEL, objectives are instead declared with a single algebraic expression. In your case, you might need to use the SUM operator with multiple-dimensional indices, something like: sum {i in 1..n, j in 1..i, k in 1..j} mynum[i,j,k] * myvar[i,j,k]. If you write out your objective function on paper as a single algebraic expression, the conversion to the corresponding OPTMODEL code will be immediate.

RobPratt · ‎05-09-2012

Regarding linear interpolation, PROC OPTMODEL does not have anything built in. But you can try some of the ideas suggested in this blog posting: http://blogs.sas.com/content/iml/2012/03/16/linear-interpolation-in-sas/ and this Usage Note: http://support.sas.com/kb/24/560.html You can do the interpolation outside of OPTMODEL and then read the results into an OPTMODEL array.

RobPratt · ‎05-09-2012

I will reply to #1 first and #2 in a separate post. If you want to use IMPVAR, you have to include the formula in the declaration. You cannot update it later. The other problem is that the SUM operator has different syntax than what you tried. Here's what I think you wanted (a dot product of two vectors): impvar updatedRisk {i in 2..n} = sum {j in 1..i-1} calculatedRisk * newRisk[n-i+1+j];

RobPratt · ‎05-08-2012

Yes, you can do all of these things, but it will likely be inefficient to introduce new variables whose values are equal to existing variables. Instead, you can express everything in terms of calculatedRisk for different values of i. For example, to achieve #1, you can do the following: num n = card(OBS); impvar calculatedRiskReverse {i in OBS} = calculatedRisk[n-i+1]; But you can avoid introducing a new variable by just using calculatedRisk[n-i+1] everywhere you need it: for {i in OBS} put calculatedRisk[n-i+1]=; For #2: impvar newRisk {i in OBS} = (if i = 1 then calculatedRisk[1] else 0); For #3: calculatedRisk * newRisk[n-i+1] Again, I think you will be better off not introducing additional variables unless you need to. If you write out the full expression for your objective, I suspect you will find that you can eliminate the additional variables by using logical conditions in the SUM operator.

RobPratt · ‎05-08-2012

You cannot currently call PROC IML from within PROC OPTMODEL. In release 12.1 due out later this year, you can use a SUBMIT block to call generic SAS code from within PROC OPTMODEL. But even that functionality will not enable you to implement a black-box objective function. Instead, you can indicate matrix multiplication by using the SUM operator: c[i,j] = sum {k in 1..n} a[i,k] * b[k,j]

RobPratt · ‎05-08-2012

Thanks for the clarification. If I understand your example correctly, the following code solves the problem in one PROC OPTMODEL call, without using any macros. Maybe your more complicated objective can be handled similarly. data bounds; input lower upper; datalines; 0.4 8 0.05 1000 ; proc optmodel; set OBS; num hours {OBS}; num actualRisk {OBS}; read data test into OBS=[_N_] hours actualRisk; set VARS; var x {VARS}; read data bounds into VARS=[_N_] x.lb=lower x.ub=upper; impvar calculatedRisk {i in OBS} = CDF('WEIBULL',hours,x[1],x[2]); min SSE = sum {i in OBS} (actualRisk - calculatedRisk)^2; solve; print x; print actualRisk calculatedRisk; create data x_sol from [var] x; quit;

RobPratt · ‎05-07-2012

Yes, your objective function should be expressed in terms of your decision variables, as in this "Getting Started" example: http://support.sas.com/documentation/cdl/en/ormpug/63975/HTML/default/viewer.htm#ormpug_optmodel_sect003.htm But it is still not clear to me whether your x and y are decision variables or input data. Maybe it would help to describe your optimization problem mathematically, without code. What is your input, and what is your desired output?

RobPratt · ‎05-07-2012

You can do something like the following in OPTMODEL: proc optmodel; set OBS; num x {OBS}; num y {OBS}; num n = card(OBS); read data test into OBS=[_N_] x y; num z {j in OBS} = sum {i in 1..j-1} x * y[n-j+i]; create data want(drop=i) from x y z; quit; But that just calculates z from the given values of x and y. Are x and y intended to be the decision variables in your optimization problem? Do you have any constraints on x and y? And do you want to minimize or maximize z?

RobPratt · ‎05-07-2012

Yes, the use of IMPVAR seems critical for your problem. I'm not familiar with the internals of Excel Solver or that algorithm. You could certainly implement it yourself by using the programming language features of OPTMODEL. But I would recommend upgrading to 9.3 instead.

RobPratt · ‎04-30-2012

3. Right 5. I tried your new objective with 10000 observations. With explicit var/con, runs out of memory. With IMPVAR, solves in one second. 6. There is currently no such feature, although that idea is a possibility for a future release. But if you use IMPVAR, your problem has only 10 variables and 1 constraint, so it shouldn't be an issue.

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?

Online Status	Offline
Date Last Visited	Wednesday