Dear R-users, I am trying to port to R something that I wrote in Matlab to perform model parameter optimization using the Nelder-Mead simplex method (fminsearch). I read the help on ?optim (which seems to be the way to go) as well as a bunch of posts on the topic, but I would like to make sure about something before I spend to much time trying to reproduce something that is not possible. The Matlab fminsearch has some nice features allowing the user to pass the optimization status (i.e., iteration number, objective function value, parameter estimate, algorithm porcedure,etc...) at each iteration to a custom function. In turn, this allows to save the data to file or print something to the shell. Did anybody manage to get optim similarly output the optimization status at each iteration to a function? The control=(trace=...) argument seems only to return partial data to the shell. Some post on the list also suggested to include some code inside the objective function, but this implies the execution of the code at each function evaluation rather than at each iteration. Any feedback on the topic would be appreciated. Sebastien [[alternative HTML version deleted]]
S?bastien Bihorel <pomchip <at> free.fr> writes:> > Dear R-users, > > I am trying to port to R something that I wrote in Matlab to perform model > parameter optimization using the Nelder-Mead simplex method (fminsearch). I > read the help on ?optim (which seems to be the way to go) as well as a bunch > of posts on the topic, but I would like to make sure about something before > I spend to much time trying to reproduce something that is not possible. The > Matlab fminsearch has some nice features allowing the user to pass the > optimization status (i.e., iteration number, objective function value, > parameter estimate, algorithm porcedure,etc...) at each iteration to a > custom function. In turn, this allows to save the data to file or print > something to the shell. > > Did anybody manage to get optim similarly output the optimization status at > each iteration to a function? > > The control=(trace=...) argument seems only to return partial data to the > shell. Some post on the list also suggested to include some code inside the > objective function, but this implies the execution of the code at each > function evaluation rather than at each iteration. > > Any feedback on the topic would be appreciated. > > Sebastien >I think that what you see is more or less what you get with optim() in this case. As I've mentioned in an earlier thread, I've translated Nelder-Mead from _Numerical Recipes_ code into R, which would allow you to instrument it however you wanted. (Indeed, I translated it in order to allow me to create a picture of N-M updating that showed which points were being visited and which updating rules executed.) I could send it if you wanted. The output-function hook is a nice idea, though -- might be worth mentioning to John Nash, who is working on a project (optimx on R-forge) to extend R's optimization capabilities.
Thanks Ben for your reply, I would very much appreciate if you could share your code. That would be great! Sebastien PS: As suggested, I will forward this email to John Nash. Sébastien Bihorel <pomchip <at> free.fr> writes:>**>* Dear R-users, *>* *>* I am trying to port to R something that I wrote in Matlab to perform model *>* parameter optimization using the Nelder-Mead simplex method (fminsearch). I *>* read the help on ?optim (which seems to be the way to go) as well as a bunch *>* of posts on the topic, but I would like to make sure about something before *>* I spend to much time trying to reproduce something that is not possible. The *>* Matlab fminsearch has some nice features allowing the user to pass the *>* optimization status (i.e., iteration number, objective function value, *>* parameter estimate, algorithm porcedure,etc...) at each iteration to a *>* custom function. In turn, this allows to save the data to file or print *>* something to the shell. *>* *>* Did anybody manage to get optim similarly output the optimization status at *>* each iteration to a function? *>* *>* The control=(trace=...) argument seems only to return partial data to the *>* shell. Some post on the list also suggested to include some code inside the *>* objective function, but this implies the execution of the code at each *>* function evaluation rather than at each iteration. *>* *>* Any feedback on the topic would be appreciated. *>* *>* Sebastien *>* * I think that what you see is more or less what you get with optim() in this case. As I've mentioned in an earlier thread, I've translated Nelder-Mead from _Numerical Recipes_ code into R, which would allow you to instrument it however you wanted. (Indeed, I translated it in order to allow me to create a picture of N-M updating that showed which points were being visited and which updating rules executed.) I could send it if you wanted. The output-function hook is a nice idea, though -- might be worth mentioning to John Nash, who is working on a project (optimx on R-forge) to extend R's optimization capabilities. [[alternative HTML version deleted]]
As Ben Bolker has indicated, I am working on various improvements to the functionality of optim() along with others, esp. Ravi Varadhan and Kate Mullen. With relevance to the posts by Sebastien Bihorel and Ben Bolker about output of point/function value information on each evaluation, I am working (rather slowly due to other commitments) on a wrapper for the user's function that will do this. It allows nice progress graphs and performance profiles to be created. The tricky bit it getting a file opened to store the information and to close it again when done, and to do this fairly cleanly. Collaborations welcome. Also I want the wrapper to allow for flagging when the function cannot be evaluated. At the moment as far as I can tell, some methods -- not just in optim but other functions too -- die, some keep going with garbage, and some can handle a function that returns Inf or similar flag properly i.e., back off a line search or similar recovery which would be useful to protect users from unhappy results. I suggest off-list responses and we can see how quickly a good resolution can be achieved. JN