tag:blogger.com,1999:blog-8781383461061929571.comments2017-09-20T19:44:56.207-04:00OR in an OB WorldPaul Rubinhttps://plus.google.com/111303285497934501993noreply@blogger.comBlogger1482125tag:blogger.com,1999:blog-8781383461061929571.post-90089194717128506952017-09-20T19:44:56.207-04:002017-09-20T19:44:56.207-04:00Thanks for taking the time to document this fix Pa...Thanks for taking the time to document this fix Paul :-)Unknownhttps://www.blogger.com/profile/14953877927244156390noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-36279887224829230002017-09-19T13:20:42.768-04:002017-09-19T13:20:42.768-04:00If you're willing to do some additional coding...If you're willing to do some additional coding to experiment, you might try bypassing OMPR and working directly with ROI and the Symphony plug-in for it. It's possible this is a bug in ROI (which means Dirk can't fix it).Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-47268875061599155292017-09-19T12:56:24.869-04:002017-09-19T12:56:24.869-04:00Definitely feasible, I assume it is optimal since ...Definitely feasible, I assume it is optimal since the verbosity on the console says so (and it looks very similar to the console output when I've used Rsymphony before). Some more digging and I found that this only occurs when I have additional arguments in solve_model. When my argument is just (solver='symphony'), no issue. But whenever I try to add additional arguments to pass to symphony (verbosity, time limit, gap limit) then the returned object says infeasible. I've logged a issue with Dirk on github.Ralph Asherhttps://www.blogger.com/profile/02417642533841862576noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-47828129148470452832017-09-19T11:51:15.556-04:002017-09-19T11:51:15.556-04:00I've only used OMPR with CPLEX (and I've n...I've only used OMPR with CPLEX (and I've never used Symphony for anything), so I don't really know. It's common for solver libraries to provide a "getter" method to get a status code of some kind (optimal, feasible but maybe not optimal, infeasible, ...). If ompr::get_solution grabs a status code first, and if the status code for some reason says infeasible, that would explain the outcome. Are you sure that what you are seeing in the console is the optimal solution (and is in fact feasible in the original model)?Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-19320334016478487972017-09-19T09:12:37.981-04:002017-09-19T09:12:37.981-04:00I'm using OMPR to call Symphony and have a wei...I'm using OMPR to call Symphony and have a weird circumstance. I put the Symphony solver arguments to be verbose, so I know that the problem solves to optimality because the R console shows the optimal decision variable values. Yet when I use ompr::get_solution, the solution object says that the problem is infeasible. Any idea why this may be happening?Ralph Asherhttps://www.blogger.com/profile/02417642533841862576noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-20037775929682474702017-09-04T17:46:22.830-04:002017-09-04T17:46:22.830-04:00excellent! ... right ... dam computer geeks creat...excellent! ... right ... dam computer geeks creating models in functions and all. glad you were able to grok the issue and make the code more robust!!https://www.blogger.com/profile/06160980387388674624noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-71507870104917668632017-09-04T15:16:58.858-04:002017-09-04T15:16:58.858-04:00Okay, I've sorted this out. The issue arises c...Okay, I've sorted this out. The issue arises consistently if (and only if) you define your models inside a function, rather than in the global environment. I've never done that, which is why the bug didn't bite me, but I can definitely reproduce it. So I've added a unit test for it and posted a new version of the notebook with the fix (as above, for both fm and im) in it.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-42308961759941359292017-09-01T15:08:59.925-04:002017-09-01T15:08:59.925-04:00You're welcome, and you're correct about i...You're welcome, and you're correct about it not being an issue for me (for some reason). I just reran my unit tests, and none of them printed out "" even once. I'm glad you're set now.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-31194914198605475632017-09-01T08:51:43.320-04:002017-09-01T08:51:43.320-04:00cheers paul. for some reason i need to add this t...cheers paul. for some reason i need to add this to the 'showEnv=F' to 'fm <- as.formula(capture.output(print(full.model)))' but it sounds like you don't. i got it working so all is well. thanks for all your help!!https://www.blogger.com/profile/06160980387388674624noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-63081160761664615122017-08-31T14:14:17.568-04:002017-08-31T14:14:17.568-04:00Yes, I get an environment identifier in the output...Yes, I get an environment identifier in the output for the first formula (but not the second). Note that you can suppress that if you wish. Change print(gg) to print(gg, showEnv = F) and see what you get.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-51832429496885413252017-08-30T05:50:31.126-04:002017-08-30T05:50:31.126-04:00sorry about the formatting ... can't wait for ...sorry about the formatting ... can't wait for the 'here is my new way' wars to end .... so i'm curious what you get as output when running the following from the command line (i'm also curious how to get mathjax to indent a line ... first two options from their web page failed, so i gave up :( ) anyway here is the code: <br /><br />#!/usr/bin/env Rscript<br /><br />bar <- function(gg, ff)<br />{<br /> print(gg)<br /> print(ff)<br />}<br /><br />doit <- function(f)<br />{<br /> g <- "A ~ B"<br /> bar(as.formula(g), f)<br />}<br /><br />f <- "C ~ D"<br />doit(as.formula(f))<br /><br /><br />$ x.R<br />A ~ B<br /><br />C ~ D<br /><br />so for the formula (f <- C ~ D) created in the 'global' space there is no attached environment printed, but for the formula created in function doit ( g <- A ~ B), the printing (of A ~ B) includes an environment. i'm guessing its part of the closure, but i'm not sure ....https://www.blogger.com/profile/06160980387388674624noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-68151338261253128952017-08-28T16:48:47.403-04:002017-08-28T16:48:47.403-04:00I should add that the quotes around the formula in...I should add that the quotes around the formula in the first instance (when it is type "character") are expected and nothing, I think, to worry about.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-87401255296998144352017-08-28T16:47:31.188-04:002017-08-28T16:47:31.188-04:00Reminder: Because this site uses MathJax for rende...Reminder: Because this site uses MathJax for rendering LaTeX math notation, you need to escape dollar signs to avoid messes like that above. I'm not sure if you need to escape tildes; I'm doing so below just to be safe.<br /><br />I substituted your code (print statements etc.) into the stepwise function, created a dummy data frame "d" with some random data, and ran "stepwise(f, f, 0.05, 0.05)". The output (excluding the actual stepwise output) was:<br /><br />[1] "R version 3.4.1 (2017-06-30)"<br />[1] "character"<br />[1] "d\$evals \~ d\$Min + d\$Max + d\$Mean"<br />[1] FALSE<br />good<br /><br />(This is on Linux Mint, by the way, although I doubt the OS matters.) Then I ran "stepwise(as.formula(f), as.formula(f), 0.05, 0.05)" and got the following:<br /><br />[1] "R version 3.4.1 (2017-06-30)"<br />[1] "language"<br />d\$evals \~ d\$Min + d\$Max + d\$Mean<br />[1] TRUE<br />bad<br /><br />followed by, again, the correct stepwise output. I got no error messages from R.<br /><br />I'm using the current version of R, so maybe that makes a difference?Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-6616428863198827262017-08-28T04:04:18.592-04:002017-08-28T04:04:18.592-04:00hey paul! i get the environment printed out ... o...hey paul! i get the environment printed out ... ok, only when the formula is created in a function:<br /><br />#!/usr/bin/env Rscript<br /><br />bar <- function(gg, ff)<br />{<br /> print(gg)<br /> print(ff)<br />}<br /><br />doit <- function(f)<br />{<br /> g <- "A ~ B"<br /> bar(as.formula(g), f)<br />}<br /><br />f <- "d$evals ~ d$Min + d$Max + d$Mean"<br />doit(as.formula(f))<br /><br />outputs<br /><br /> A ~ B<br /> <br /> d$evals ~ d$Min + d$Max + d$Mean<br /><br /><br />so when i run the following as part of stepwise<br /><br />print(R.version.string)<br />print(typeof(full.model))<br />print(full.model)<br />print(is.language(full.model))<br /> if (is.character(full.model)) {<br /> # if (is.language(full.model) | is.character(full.model)) {<br />cat("good\n")<br /> fm <- as.formula(full.model)<br /> } else {<br />cat("bad\n")<br /> fm <- as.formula(capture.output(print(full.model)))<br /> }<br /><br />i get an error<br /><br />[1] "R version 3.2.3 (2015-12-10)"<br />[1] "language"<br />d$evals ~ d$Min + d$Max + d$Mean + d$Count<br /><br />[1] TRUE<br />bad<br />Error in parse(text = x, keep.source = FALSE) :<br /> :2:1: unexpected '<'<br />1: d$evals ~ d$Min + d$Max + d$Mean + d$Count<br />2: <<br /> ^<br />Calls: doit ... formula -> formula.character -> formula -> eval -> parse<br />Execution halted<br /><br />this is under linux. i get the same thing on a mac with<br /> version.string R version 3.2.4 (2016-03-10)<br /><br />i gather that you don't get the "" as part of the printed output.<br /><br />adding 'is.language(full.model) |' solved my problem. i've got stepwise is doing what i need. i certainly don't expect you to keep hacking on my account. on the flip side, i'm happy to dig deeper if such would bring you value!<br /><br />sorry this got kinda long ....<br /><br />https://www.blogger.com/profile/06160980387388674624noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-47098286753678193772017-08-27T14:19:09.334-04:002017-08-27T14:19:09.334-04:00You're welcome for the update ... but you lost...You're welcome for the update ... but you lost me here. I created a data frame "d" with the five variables you used, computed f as above and computed mx both as written (using as.formula(f) as the model arguments to stepwise) and using just f as the model arguments. Both ran fine, produced the same results and generated printed output with no glitches I can see.<br /><br />If you use as.formula(f) as a model argument, its class is "formula", which causes as.language(as.formula(f)) to return true. So your hack basically says "if he entered a formula or if he entered a string, set fm to as.formula(full.model)", which pretty much guarantees the condition will evaluate to true and the line will execute. I think that will cause problems if you have a collision between a variable name in the model and a variable name used in the function, which is why I needed the goofy looking else clause in the first place.<br /><br />You said that, when printed, objects of type language include that caused problems. Did you mean a comma, or did something not print in your comment?Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-20056521881665655842017-08-27T06:49:43.875-04:002017-08-27T06:49:43.875-04:00hey paul
fianlly found time to play with the upda...hey paul<br /><br />fianlly found time to play with the update. worked like a charm with one minor modification (likely caused by my not truely grokking R's type system).<br />i call your code with<br /><br /> f <- "d$evals ~ d$Min + d$Max + d$Mean + d$Count"<br /> mx <- stepwise(as.formula(f), as.formula(f), 0.05, 0.05)<br /><br />thus in stepwise.R full.model (and initial.model) are of type 'language'. when printed objects of type language include , which did not parse well later on.<br />The following change seemed to sort the issue.<br /><br /> if (is.language(full.model) | is.character(full.model)) {<br /> fm <- as.formula(full.model)<br /> } else {<br /> fm <- as.formula(capture.output(print(full.model)))<br /> }<br /><br /> if (is.language(initial.model) | is.character(initial.model)) {<br /> im <- as.formula(initial.model)<br /> } else {<br /> im <- as.formula(capture.output(print(initial.model)))<br /> }<br /><br />thanks again for the update ... saved me bookoo time!!<br />https://www.blogger.com/profile/06160980387388674624noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-68169424146919158062017-08-23T17:09:26.016-04:002017-08-23T17:09:26.016-04:00Thanks for the explanation and the references. Sho...Thanks for the explanation and the references. Shooting from the hip, I suspect that this would be hard to extend to discrete problems ... but I could be wrong. (It would not be the first time.)Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-52598148616815482832017-08-22T11:49:39.500-04:002017-08-22T11:49:39.500-04:00The update is tucked in just below the scrollable ...The update is tucked in just below the scrollable code window; the link is the word "posted". I have to admit it's a tad inconspicuous. Anyway, the link (to a recent post that explains changes and links to the new code) is https://orinanobworld.blogspot.com/2017/08/updated-stepwise-regression-function.html.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-77454047653592290942017-08-22T08:49:45.600-04:002017-08-22T08:49:45.600-04:00Hi Rubin, the proofs of optimality basically prove...Hi Rubin, the proofs of optimality basically prove that from a certain point onwards, the optimal policy will not change anymore. Two great papers on this topic are:<br /><br />- Mayne, Rawlings, Rao, Scokaert (2000) Constrained model predictive control: Stability and optimality (http://www.sciencedirect.com/science/article/pii/S0005109899002149) <br /><br />- Scokaert and Rawlings (1998) Constrained linear quadratic regulation (http://ieeexplore.ieee.org/abstract/document/704994/).<br /><br /><br />The general assumptions there are linear dynamics and constraints and equal weighting on all horizon steps. In practice however (at least in MPC), one is more interested in stability, i.e. that any control action taken will end up in the same feasible space of the state variables, and thus enable stability of the controller.Richard Oberdieckhttps://www.blogger.com/profile/03386871665462162276noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-64385267013025983672017-08-22T08:36:26.330-04:002017-08-22T08:36:26.330-04:00hey paul, alas, i proving inept at finding the lin...hey paul, alas, i proving inept at finding the link to the update :( <br />likely about as good as my budget milking, but i'm not sure that is causal ;-)https://www.blogger.com/profile/06160980387388674624noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-80636734814542510342017-08-21T15:29:33.078-04:002017-08-21T15:29:33.078-04:00Thanks for the comment, Richard. I'm particula...Thanks for the comment, Richard. I'm particularly curious about proofs of optimality (or even near optimality), since intuitively I would think that results would depend on how "clever" one was setting boundary conditions. For some classes of problems, I think you can replace boundary conditions by setting the temporary horizon reasonably far out and apply a discount factor to results (so that the solution is progressively less sensitive to what's going on as you approach the horizon). My gut feeling is that might be more amenable to proofs of optimality (or at least near optimality). Have you seen optimality proofs that don't require discounting?Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-88675090234248784932017-08-21T14:50:09.627-04:002017-08-21T14:50:09.627-04:00Forgot to ask: did you ever try to milk a badger? ...Forgot to ask: did you ever try to milk a badger? Probably even worse than milking a duck (although badger are at least mammals).Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-44483980068932868842017-08-21T14:49:12.249-04:002017-08-21T14:49:12.249-04:00Check the tail end of the post above for a link to...Check the tail end of the post above for a link to the update.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-14219247282589973282017-08-21T14:48:46.710-04:002017-08-21T14:48:46.710-04:00Check the tail end of the post above for a link to...Check the tail end of the post above for a link to the update.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.comtag:blogger.com,1999:blog-8781383461061929571.post-86791073022180869712017-08-21T10:21:19.443-04:002017-08-21T10:21:19.443-04:00When you're back, I would suggest taking this ...When you're back, I would suggest taking this to one of the help forums listed in the margin of this post. The comment stream on a blog is an awkward place for an extended discussion.Paul Rubinhttps://www.blogger.com/profile/05801891157261357482noreply@blogger.com