From rossbennett34 at gmail.com Sun Feb 2 20:44:12 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Sun, 2 Feb 2014 11:44:12 -0800 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics Message-ID: All, To put the finishing touches on PortfolioAnalytics, I propose the following items. Enhance the print and summary methods for optimize.portfolio.rebalancing. Currently, a list of optimize.portfolio objects at each rebalance period is returned. I'd like to change this to also return the R object so that I can do more with a summary method such as calculating the portfolio rebalanced returns, annualized return, risk measures, etc. Add function to generalize the plot from Peter's presentation. See attached image. Address all warnings in R CMD Check I just ran R CMD Check using Rstudio and the only warning I received was the following: * checking package vignettes in 'inst/doc' ... WARNING Package vignettes without corresponding PDF/HTML: 'DesignThoughts.Rnw' 'ROI_vignette.Rnw' 'portfolio_vignette.Rnw' 'risk_budget_optimization.Rnw' We don't have anything in inst/doc as all our vignette files (.Rnw and .pdf) are in the vignettes directory. How do I handle this warning. Final review of documentation. I am just getting started playing around with the Bloomberg Portfolio Analysis module to see if there is anything we can borrow from there. Is there anything else that I need to consider? Ross P.S. Go Seahawks! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-01 at 10.46.52 PM.png Type: image/png Size: 203431 bytes Desc: not available URL: From martinrd at comcast.net Sun Feb 2 22:14:09 2014 From: martinrd at comcast.net (Doug Martin) Date: Sun, 2 Feb 2014 14:14:09 -0700 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: References: Message-ID: <000001cf205b$c082bce0$418836a0$@comcast.net> Ross, Good to see. Main thing from my perspective is that I need to check my chapter 2 with the current version and see if I missed implementing my current examples with the "to be released" version of PortfolioAnalytics, and finishing off a couple more examples. I will do this during the coming week. Other comments below. Doug From: gsoc-porta-bounces at lists.r-forge.r-project.org [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross Bennett Sent: Sunday, February 02, 2014 12:44 PM To: PortfolioAnalytics Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics All, To put the finishing touches on PortfolioAnalytics, I propose the following items. Enhance the print and summary methods for optimize.portfolio.rebalancing. Currently, a list of optimize.portfolio objects at each rebalance period is returned. [Doug] So does that imply one can now input a list of portfolio optimization strategy objects to "optimize.portfolio.rebalancing", e.g., each with different constraints and different objectives? (this would be very useful) I'd like to change this to also return the R object so that I can do more with a summary method such as calculating the portfolio rebalanced returns, annualized return, risk measures, etc. [Doug] I guess there is the question of how much in the way of performance analysis gets done with a summary method, as compared with using PerformanceAnalytics on the result of optimize.portfolio.rebalancing. Add function to generalize the plot from Peter's presentation. See attached image. Address all warnings in R CMD Check I just ran R CMD Check using Rstudio and the only warning I received was the following: * checking package vignettes in 'inst/doc' ... WARNING Package vignettes without corresponding PDF/HTML: 'DesignThoughts.Rnw' 'ROI_vignette.Rnw' 'portfolio_vignette.Rnw' 'risk_budget_optimization.Rnw' We don't have anything in inst/doc as all our vignette files (.Rnw and .pdf) are in the vignettes directory. How do I handle this warning. Final review of documentation. I am just getting started playing around with the Bloomberg Portfolio Analysis module to see if there is anything we can borrow from there. Is there anything else that I need to consider? Ross P.S. Go Seahawks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossbennett34 at gmail.com Mon Feb 3 05:25:29 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Sun, 2 Feb 2014 20:25:29 -0800 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: <000001cf205b$c082bce0$418836a0$@comcast.net> References: <000001cf205b$c082bce0$418836a0$@comcast.net> Message-ID: See responses inline. On Sun, Feb 2, 2014 at 1:14 PM, Doug Martin wrote: > Ross, > > > > Good to see. Main thing from my perspective is that I need to check my > chapter 2 with the current version and see if I missed implementing my > current examples with the "to be released" version of PortfolioAnalytics, > and finishing off a couple more examples. I will do this during the coming > week. > > > > Other comments below. > > > > Doug > > > > > > *From:* gsoc-porta-bounces at lists.r-forge.r-project.org [mailto: > gsoc-porta-bounces at lists.r-forge.r-project.org] *On Behalf Of *Ross > Bennett > *Sent:* Sunday, February 02, 2014 12:44 PM > *To:* PortfolioAnalytics > *Subject:* [GSoC-PortA] Finishing Touches to PortfolioAnalytics > > > > All, > > > > To put the finishing touches on PortfolioAnalytics, I propose the > following items. > > > > Enhance the print and summary methods for optimize.portfolio.rebalancing. > Currently, a list of optimize.portfolio objects at each rebalance period is > returned. > > *[Doug] So does that imply one can now input a list of portfolio > optimization strategy objects to "optimize.portfolio.rebalancing", e.g., > each with different constraints and different objectives? (this would be > very useful)* > No, that is currently not possible, but should not be too hard to implement. I could do this for optimize.portfolio as well. I think the most robust way to implement this would be to make optimize.portfolio() and optimize.portfolio.rebalancing() generic methods. This would require a few minor design changes and I don't think it would break backwards compatibility. We would have to change the order of arguments for optimize.portfolio() and optimize.portfolio.rebalancing() so that 'portfolio' is the first argument, currently 'R' is the first argument. > > I'd like to change this to also return the R object so that I can do more > with a summary method such as calculating the portfolio rebalanced returns, > annualized return, risk measures, etc. > > *[Doug] I guess there is the question of how much in the way of > performance analysis gets done with a summary method, as compared with > using PerformanceAnalytics on the result of optimize.portfolio.rebalancing.* > The idea is that I would use PerformanceAnalytics to calculate some of the metrics. Currently, optimize.portfolio.rebalancing returns a list of optimize.portfolio.* objects at each rebalance date. The user would have to do the following to calculate the portfolio returns. opt_backtest <- optimize.portfolio.rebalancing(R, portfolio, ...) portfolio_ret <- Return.rebalancing(R, extractWeights(opt_backtest)) I think it would be useful to calculate the portfolio returns in the summary method so the user would just have to do something like summary(opt_backtest)$portfolio_returns At a minimum the summary method would return the following: - optimal weights at each rebalance date - objective measures at each rebalance date - portfolio returns - portfolio annualized returns > > > Add function to generalize the plot from Peter's presentation. See > attached image. > > > > Address all warnings in R CMD Check > > I just ran R CMD Check using Rstudio and the only warning I received was > the following: > > * checking package vignettes in 'inst/doc' ... WARNING > > Package vignettes without corresponding PDF/HTML: > > 'DesignThoughts.Rnw' > > 'ROI_vignette.Rnw' > > 'portfolio_vignette.Rnw' > > 'risk_budget_optimization.Rnw' > > > > We don't have anything in inst/doc as all our vignette files (.Rnw and > .pdf) are in the vignettes directory. How do I handle this warning. > > > > Final review of documentation. > > > > I am just getting started playing around with the Bloomberg Portfolio > Analysis module to see if there is anything we can borrow from there. > > > > Is there anything else that I need to consider? > > > > Ross > > > > P.S. Go Seahawks! > > _______________________________________________ > GSoC-PortA mailing list > GSoC-PortA at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at braverock.com Wed Feb 5 08:29:10 2014 From: brian at braverock.com (Brian G. Peterson) Date: Wed, 05 Feb 2014 01:29:10 -0600 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: References: <000001cf205b$c082bce0$418836a0$@comcast.net> Message-ID: <52F1E846.9040004@braverock.com> On 02/02/2014 10:25 PM, Ross Bennett wrote: > Enhance the print and summary methods for > optimize.portfolio.rebalancing. Currently, a list of > optimize.portfolio objects at each rebalance period is returned.____ > > */[Doug] So does that imply one can now input a list of portfolio > optimization strategy objects to ?optimize.portfolio.rebalancing?, > e.g., each with different constraints and different objectives? > (this would be very useful)/* > > > No, that is currently not possible, but should not be too hard to > implement. I could do this for optimize.portfolio as well. I think the > most robust way to implement this would be to make optimize.portfolio() > and optimize.portfolio.rebalancing() generic methods. > > This would require a few minor design changes and I don't think it would > break backwards compatibility. We would have to change the order of > arguments for optimize.portfolio() and optimize.portfolio.rebalancing() > so that 'portfolio' is the first argument, currently 'R' is the first > argument. I think the desired functionality (take a list of portfolio objects) is a good idea. I don't think relying on S3 dispatch and making optimize.portfolio.* into S3 generics makes sense though. I say this because there's far too much shared code. The sub-functions for the different optimizer methods and special cases are far less code than the wrapper/framework function. I wouldn't want to duplicate all that code, or add a bunch of extra function calls in code that's called lots and lots of times. Also, I *really* hate breaking backwards compatibility by rearranging arguments unless there's a compelling reason. For R generics like print/plot/summary, using S3 dispatch is the obvious and only answer, but for optimize.portfolio.*, I'd say leaving the arguments list alone makes the most sense. I think you could add the loop over portfolio specification list elements (if it is a list) and collection of the results into a list of optimization results into the optimize.portfolio.* functions without too much work, and without breaking existing code. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock From brian at braverock.com Wed Feb 5 12:15:47 2014 From: brian at braverock.com (Brian G. Peterson) Date: Wed, 05 Feb 2014 05:15:47 -0600 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: References: <000001cf205b$c082bce0$418836a0$@comcast.net> Message-ID: <52F21D63.6010609@braverock.com> RE: summary method On 02/02/2014 10:25 PM, Ross Bennett wrote: > I'd like to change this to also return the R object so that I can do > more with a summary method such as calculating the portfolio > rebalanced returns, annualized return, risk measures, etc.____ > > */[Doug] I guess there is the question of how much in the way of > performance analysis gets done with a summary method, as compared > with using PerformanceAnalytics on the result of > optimize.portfolio.rebalancing./* > > > The idea is that I would use PerformanceAnalytics to calculate some of > the metrics. Currently, optimize.portfolio.rebalancing returns a list of > optimize.portfolio.* objects at each rebalance date. The user would have > to do the following to calculate the portfolio returns. > > opt_backtest <- optimize.portfolio.rebalancing(R, portfolio, ...) > portfolio_ret <- Return.rebalancing(R, extractWeights(opt_backtest)) > > I think it would be useful to calculate the portfolio returns in the > summary method so the user would just have to do something like > > summary(opt_backtest)$portfolio_returns > > At a minimum the summary method would return the following: > - optimal weights at each rebalance date > - objective measures at each rebalance date > - portfolio returns > - portfolio annualized returns I generally like this idea. In S, the summary method was supposed to return an object with standardized slots that other functions then knew how to manipulate. In R, many package authors seems to confuse print and summary methods. In reality, in many cases, a print method should call the summary method, then display some of that information. In other cases with particularly complex summary methods, I've seen print methods just for the summary objects. In practice most of the time, I think the first approach makes more sense. I don't think you really need to add standardized performance measures though. The user will have things that they want, some measure of return, some measure of risk, etc. If we collect these all in a standardized extract object, the user should be thrilled. I don't really think the user will care about extras, or they could have included them, or can trivially calculate the ones they care about themselves via PerformanceAnalytics. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock From rossbennett34 at gmail.com Wed Feb 5 15:54:39 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Wed, 5 Feb 2014 06:54:39 -0800 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: <52F1E846.9040004@braverock.com> References: <000001cf205b$c082bce0$418836a0$@comcast.net> <52F1E846.9040004@braverock.com> Message-ID: Makes a lot more sense from that perspective to avoid making optimize.portfolio and optimize.portfolio.rebalancing S3 generic methods. I'll proceed as you have outlined. Thanks for the clarification and guidance. Ross On Tue, Feb 4, 2014 at 11:29 PM, Brian G. Peterson wrote: > On 02/02/2014 10:25 PM, Ross Bennett wrote: > >> Enhance the print and summary methods for >> optimize.portfolio.rebalancing. Currently, a list of >> optimize.portfolio objects at each rebalance period is returned.____ >> >> */[Doug] So does that imply one can now input a list of portfolio >> >> optimization strategy objects to "optimize.portfolio.rebalancing", >> e.g., each with different constraints and different objectives? >> (this would be very useful)/* >> >> >> >> No, that is currently not possible, but should not be too hard to >> implement. I could do this for optimize.portfolio as well. I think the >> most robust way to implement this would be to make optimize.portfolio() >> and optimize.portfolio.rebalancing() generic methods. >> >> This would require a few minor design changes and I don't think it would >> break backwards compatibility. We would have to change the order of >> arguments for optimize.portfolio() and optimize.portfolio.rebalancing() >> so that 'portfolio' is the first argument, currently 'R' is the first >> argument. >> > > I think the desired functionality (take a list of portfolio objects) is a > good idea. > > I don't think relying on S3 dispatch and making optimize.portfolio.* into > S3 generics makes sense though. > > I say this because there's far too much shared code. The sub-functions > for the different optimizer methods and special cases are far less code > than the wrapper/framework function. I wouldn't want to duplicate all that > code, or add a bunch of extra function calls in code that's called lots and > lots of times. > > Also, I *really* hate breaking backwards compatibility by rearranging > arguments unless there's a compelling reason. For R generics like > print/plot/summary, using S3 dispatch is the obvious and only answer, but > for optimize.portfolio.*, I'd say leaving the arguments list alone makes > the most sense. > > I think you could add the loop over portfolio specification list elements > (if it is a list) and collection of the results into a list of optimization > results into the optimize.portfolio.* functions without too much work, and > without breaking existing code. > > Regards, > > Brian > > -- > Brian G. Peterson > http://braverock.com/brian/ > Ph: 773-459-4973 > IM: bgpbraverock > > _______________________________________________ > GSoC-PortA mailing list > GSoC-PortA at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossbennett34 at gmail.com Thu Feb 20 19:27:24 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Thu, 20 Feb 2014 10:27:24 -0800 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: References: <000001cf205b$c082bce0$418836a0$@comcast.net> <52F1E846.9040004@braverock.com> Message-ID: All, I am working on adding functionality to accept a list of portfolio objects for optimize.portfolio and optimize.portfolio.rebalancing. I added a block of code at the beginning of optimize.portfolio and optimize.portfolio.rebalancing to detect a list of portfolio objects and then loop through each portfolio in the list of portfolios and recursively call optimize.portfolio or optimize.portfolio.rebalancing. I have a return statement at the end of that block of code. Some frown upon multiple return statements in a function, is it ok that I do this here or is there a different approach I should follow. I also added demo/multiple_portfolio_optimization.R so you can test out the functionality. I just committed my changes with r3318. Ross On Wed, Feb 5, 2014 at 6:54 AM, Ross Bennett wrote: > Makes a lot more sense from that perspective to avoid making > optimize.portfolio and optimize.portfolio.rebalancing S3 generic methods. > I'll proceed as you have outlined. > > Thanks for the clarification and guidance. > > Ross > > > > On Tue, Feb 4, 2014 at 11:29 PM, Brian G. Peterson wrote: > >> On 02/02/2014 10:25 PM, Ross Bennett wrote: >> >>> Enhance the print and summary methods for >>> optimize.portfolio.rebalancing. Currently, a list of >>> optimize.portfolio objects at each rebalance period is returned.____ >>> >>> */[Doug] So does that imply one can now input a list of portfolio >>> >>> optimization strategy objects to "optimize.portfolio.rebalancing", >>> e.g., each with different constraints and different objectives? >>> (this would be very useful)/* >>> >>> >>> >>> No, that is currently not possible, but should not be too hard to >>> implement. I could do this for optimize.portfolio as well. I think the >>> most robust way to implement this would be to make optimize.portfolio() >>> and optimize.portfolio.rebalancing() generic methods. >>> >>> This would require a few minor design changes and I don't think it would >>> break backwards compatibility. We would have to change the order of >>> arguments for optimize.portfolio() and optimize.portfolio.rebalancing() >>> so that 'portfolio' is the first argument, currently 'R' is the first >>> argument. >>> >> >> I think the desired functionality (take a list of portfolio objects) is a >> good idea. >> >> I don't think relying on S3 dispatch and making optimize.portfolio.* into >> S3 generics makes sense though. >> >> I say this because there's far too much shared code. The sub-functions >> for the different optimizer methods and special cases are far less code >> than the wrapper/framework function. I wouldn't want to duplicate all that >> code, or add a bunch of extra function calls in code that's called lots and >> lots of times. >> >> Also, I *really* hate breaking backwards compatibility by rearranging >> arguments unless there's a compelling reason. For R generics like >> print/plot/summary, using S3 dispatch is the obvious and only answer, but >> for optimize.portfolio.*, I'd say leaving the arguments list alone makes >> the most sense. >> >> I think you could add the loop over portfolio specification list elements >> (if it is a list) and collection of the results into a list of optimization >> results into the optimize.portfolio.* functions without too much work, and >> without breaking existing code. >> >> Regards, >> >> Brian >> >> -- >> Brian G. Peterson >> http://braverock.com/brian/ >> Ph: 773-459-4973 >> IM: bgpbraverock >> >> _______________________________________________ >> GSoC-PortA mailing list >> GSoC-PortA at lists.r-forge.r-project.org >> http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrd at comcast.net Thu Feb 20 19:48:19 2014 From: martinrd at comcast.net (Doug Martin) Date: Thu, 20 Feb 2014 11:48:19 -0700 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: References: <000001cf205b$c082bce0$418836a0$@comcast.net> <52F1E846.9040004@braverock.com> Message-ID: <00e101cf2e6c$5c3952c0$14abf840$@comcast.net> Got it and will take a look tomorrow or on the weekend. Thanks, Doug From: gsoc-porta-bounces at lists.r-forge.r-project.org [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross Bennett Sent: Thursday, February 20, 2014 11:27 AM To: PortfolioAnalytics Subject: Re: [GSoC-PortA] Finishing Touches to PortfolioAnalytics All, I am working on adding functionality to accept a list of portfolio objects for optimize.portfolio and optimize.portfolio.rebalancing. I added a block of code at the beginning of optimize.portfolio and optimize.portfolio.rebalancing to detect a list of portfolio objects and then loop through each portfolio in the list of portfolios and recursively call optimize.portfolio or optimize.portfolio.rebalancing. I have a return statement at the end of that block of code. Some frown upon multiple return statements in a function, is it ok that I do this here or is there a different approach I should follow. I also added demo/multiple_portfolio_optimization.R so you can test out the functionality. I just committed my changes with r3318. Ross On Wed, Feb 5, 2014 at 6:54 AM, Ross Bennett wrote: Makes a lot more sense from that perspective to avoid making optimize.portfolio and optimize.portfolio.rebalancing S3 generic methods. I'll proceed as you have outlined. Thanks for the clarification and guidance. Ross On Tue, Feb 4, 2014 at 11:29 PM, Brian G. Peterson wrote: On 02/02/2014 10:25 PM, Ross Bennett wrote: Enhance the print and summary methods for optimize.portfolio.rebalancing. Currently, a list of optimize.portfolio objects at each rebalance period is returned.____ */[Doug] So does that imply one can now input a list of portfolio optimization strategy objects to "optimize.portfolio.rebalancing", e.g., each with different constraints and different objectives? (this would be very useful)/* No, that is currently not possible, but should not be too hard to implement. I could do this for optimize.portfolio as well. I think the most robust way to implement this would be to make optimize.portfolio() and optimize.portfolio.rebalancing() generic methods. This would require a few minor design changes and I don't think it would break backwards compatibility. We would have to change the order of arguments for optimize.portfolio() and optimize.portfolio.rebalancing() so that 'portfolio' is the first argument, currently 'R' is the first argument. I think the desired functionality (take a list of portfolio objects) is a good idea. I don't think relying on S3 dispatch and making optimize.portfolio.* into S3 generics makes sense though. I say this because there's far too much shared code. The sub-functions for the different optimizer methods and special cases are far less code than the wrapper/framework function. I wouldn't want to duplicate all that code, or add a bunch of extra function calls in code that's called lots and lots of times. Also, I *really* hate breaking backwards compatibility by rearranging arguments unless there's a compelling reason. For R generics like print/plot/summary, using S3 dispatch is the obvious and only answer, but for optimize.portfolio.*, I'd say leaving the arguments list alone makes the most sense. I think you could add the loop over portfolio specification list elements (if it is a list) and collection of the results into a list of optimization results into the optimize.portfolio.* functions without too much work, and without breaking existing code. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock _______________________________________________ GSoC-PortA mailing list GSoC-PortA at lists.r-forge.r-project.org http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossbennett34 at gmail.com Mon Feb 24 18:23:29 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Mon, 24 Feb 2014 09:23:29 -0800 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: <00e101cf2e6c$5c3952c0$14abf840$@comcast.net> References: <000001cf205b$c082bce0$418836a0$@comcast.net> <52F1E846.9040004@braverock.com> <00e101cf2e6c$5c3952c0$14abf840$@comcast.net> Message-ID: All, PortfolioAnalytics is not building on R-forge and part of the error message is shown below. Error: processing vignette 'risk_budget_optimization.Rnw' failed with diagnostics: subscript out of bounds Execution halted Run time: 437.89 seconds. However, when I run R CMD Check, the R code in the vignettes runs successfully so I am not sure how to address this error or if there is something else I am missing. I also tried building the vignette in Rstudio with the 'compile pdf' button and it compiled successfully. For your reference, I am attaching the 00check.log file. Ross On Thu, Feb 20, 2014 at 10:48 AM, Doug Martin wrote: > Got it and will take a look tomorrow or on the weekend. > > > > Thanks, > > Doug > > > > > > *From:* gsoc-porta-bounces at lists.r-forge.r-project.org [mailto: > gsoc-porta-bounces at lists.r-forge.r-project.org] *On Behalf Of *Ross > Bennett > *Sent:* Thursday, February 20, 2014 11:27 AM > *To:* PortfolioAnalytics > *Subject:* Re: [GSoC-PortA] Finishing Touches to PortfolioAnalytics > > > > All, > > > > I am working on adding functionality to accept a list of portfolio objects > for optimize.portfolio and optimize.portfolio.rebalancing. > > > > I added a block of code at the beginning of optimize.portfolio and > optimize.portfolio.rebalancing to detect a list of portfolio objects and > then loop through each portfolio in the list of portfolios and recursively > call optimize.portfolio or optimize.portfolio.rebalancing. I have a return > statement at the end of that block of code. Some frown upon multiple return > statements in a function, is it ok that I do this here or is there a > different approach I should follow. > > > > I also added demo/multiple_portfolio_optimization.R so you can test out > the functionality. > > > > I just committed my changes with r3318. > > > > Ross > > > > > > On Wed, Feb 5, 2014 at 6:54 AM, Ross Bennett > wrote: > > Makes a lot more sense from that perspective to avoid making > optimize.portfolio and optimize.portfolio.rebalancing S3 generic methods. > I'll proceed as you have outlined. > > > > Thanks for the clarification and guidance. > > > > Ross > > > > > > On Tue, Feb 4, 2014 at 11:29 PM, Brian G. Peterson > wrote: > > On 02/02/2014 10:25 PM, Ross Bennett wrote: > > Enhance the print and summary methods for > optimize.portfolio.rebalancing. Currently, a list of > > optimize.portfolio objects at each rebalance period is returned.____ > > */[Doug] So does that imply one can now input a list of portfolio > > > optimization strategy objects to "optimize.portfolio.rebalancing", > e.g., each with different constraints and different objectives? > > (this would be very useful)/* > > > > > No, that is currently not possible, but should not be too hard to > implement. I could do this for optimize.portfolio as well. I think the > most robust way to implement this would be to make optimize.portfolio() > and optimize.portfolio.rebalancing() generic methods. > > This would require a few minor design changes and I don't think it would > break backwards compatibility. We would have to change the order of > arguments for optimize.portfolio() and optimize.portfolio.rebalancing() > so that 'portfolio' is the first argument, currently 'R' is the first > argument. > > > I think the desired functionality (take a list of portfolio objects) is a > good idea. > > I don't think relying on S3 dispatch and making optimize.portfolio.* into > S3 generics makes sense though. > > I say this because there's far too much shared code. The sub-functions > for the different optimizer methods and special cases are far less code > than the wrapper/framework function. I wouldn't want to duplicate all that > code, or add a bunch of extra function calls in code that's called lots and > lots of times. > > Also, I *really* hate breaking backwards compatibility by rearranging > arguments unless there's a compelling reason. For R generics like > print/plot/summary, using S3 dispatch is the obvious and only answer, but > for optimize.portfolio.*, I'd say leaving the arguments list alone makes > the most sense. > > I think you could add the loop over portfolio specification list elements > (if it is a list) and collection of the results into a list of optimization > results into the optimize.portfolio.* functions without too much work, and > without breaking existing code. > > Regards, > > Brian > > -- > Brian G. Peterson > http://braverock.com/brian/ > Ph: 773-459-4973 > IM: bgpbraverock > > > _______________________________________________ > GSoC-PortA mailing list > GSoC-PortA at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta > > > > > > _______________________________________________ > GSoC-PortA mailing list > GSoC-PortA at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 00check.log Type: application/octet-stream Size: 9154 bytes Desc: not available URL: From brian at braverock.com Mon Feb 24 20:16:04 2014 From: brian at braverock.com (Brian G. Peterson) Date: Mon, 24 Feb 2014 13:16:04 -0600 Subject: [GSoC-PortA] Finishing Touches to PortfolioAnalytics In-Reply-To: References: <000001cf205b$c082bce0$418836a0$@comcast.net> <52F1E846.9040004@braverock.com> <00e101cf2e6c$5c3952c0$14abf840$@comcast.net> Message-ID: <530B9A74.4020609@braverock.com> I'm guessing the vignettes might just take too long for R-Forge. We should ask them to see if they have any other data. I had no trouble building it here from the command line and RStudio. Brian On 02/24/2014 11:23 AM, Ross Bennett wrote: > All, > > PortfolioAnalytics is not building on R-forge and part of the error > message is shown below. > > Error: processing vignette ?risk_budget_optimization.Rnw? failed with diagnostics: > subscript out of bounds > Execution halted > Run time: 437.89 seconds. > > However, when I run R CMD Check, the R code in the vignettes runs > successfully so I am not sure how to address this error or if there is > something else I am missing. I also tried building the vignette in > Rstudio with the 'compile pdf' button and it compiled successfully. For > your reference, I am attaching the 00check.log file. > > Ross > > > > On Thu, Feb 20, 2014 at 10:48 AM, Doug Martin > wrote: > > Got it and will take a look tomorrow or on the weekend.____ > > __ __ > > Thanks,____ > > Doug____ > > __ __ > > __ __ > > *From:*gsoc-porta-bounces at lists.r-forge.r-project.org > > [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org > ] *On Behalf > Of *Ross Bennett > *Sent:* Thursday, February 20, 2014 11:27 AM > *To:* PortfolioAnalytics > *Subject:* Re: [GSoC-PortA] Finishing Touches to PortfolioAnalytics____ > > __ __ > > All,____ > > __ __ > > I am working on adding functionality to accept a list of portfolio > objects for optimize.portfolio and optimize.portfolio.rebalancing.____ > > __ __ > > I added a block of code at the beginning of optimize.portfolio and > optimize.portfolio.rebalancing to detect a list of portfolio objects > and then loop through each portfolio in the list of portfolios and > recursively call optimize.portfolio or > optimize.portfolio.rebalancing. I have a return statement at the end > of that block of code. Some frown upon multiple return statements in > a function, is it ok that I do this here or is there a different > approach I should follow.____ > > __ __ > > I also added demo/multiple_portfolio_optimization.R so you can test > out the functionality.____ > > __ __ > > I just committed my changes with r3318.____ > > __ __ > > Ross____ > > __ __ > > __ __ > > On Wed, Feb 5, 2014 at 6:54 AM, Ross Bennett > > wrote:____ > > Makes a lot more sense from that perspective to avoid making > optimize.portfolio and optimize.portfolio.rebalancing S3 generic > methods. I'll proceed as you have outlined.____ > > __ __ > > Thanks for the clarification and guidance.____ > > __ __ > > Ross____ > > __ __ > > __ __ > > On Tue, Feb 4, 2014 at 11:29 PM, Brian G. Peterson > > wrote:____ > > On 02/02/2014 10:25 PM, Ross Bennett wrote:____ > > Enhance the print and summary methods for > optimize.portfolio.rebalancing. Currently, a list of____ > > optimize.portfolio objects at each rebalance period is > returned.____ > > */[Doug] So does that imply one can now input a list of > portfolio____ > > > optimization strategy objects to > ?optimize.portfolio.rebalancing?, > e.g., each with different constraints and different > objectives?____ > > (this would be very useful)/*____ > > > > > No, that is currently not possible, but should not be too hard to > implement. I could do this for optimize.portfolio as well. I > think the > most robust way to implement this would be to make > optimize.portfolio() > and optimize.portfolio.rebalancing() generic methods. > > This would require a few minor design changes and I don't think > it would > break backwards compatibility. We would have to change the order of > arguments for optimize.portfolio() and > optimize.portfolio.rebalancing() > so that 'portfolio' is the first argument, currently 'R' is the > first > argument.____ > > > I think the desired functionality (take a list of portfolio objects) > is a good idea. > > I don't think relying on S3 dispatch and making optimize.portfolio.* > into S3 generics makes sense though. > > I say this because there's far too much shared code. The > sub-functions for the different optimizer methods and special cases > are far less code than the wrapper/framework function. I wouldn't > want to duplicate all that code, or add a bunch of extra function > calls in code that's called lots and lots of times. > > Also, I *really* hate breaking backwards compatibility by > rearranging arguments unless there's a compelling reason. For R > generics like print/plot/summary, using S3 dispatch is the obvious > and only answer, but for optimize.portfolio.*, I'd say leaving the > arguments list alone makes the most sense. > > I think you could add the loop over portfolio specification list > elements (if it is a list) and collection of the results into a list > of optimization results into the optimize.portfolio.* functions > without too much work, and without breaking existing code. > > Regards, > > Brian > > -- > Brian G. Peterson > http://braverock.com/brian/ > Ph: 773-459-4973 > IM: bgpbraverock____ > > > _______________________________________________ > GSoC-PortA mailing list > GSoC-PortA at lists.r-forge.r-project.org > > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta____ > > __ __ > > __ __ > > > _______________________________________________ > GSoC-PortA mailing list > GSoC-PortA at lists.r-forge.r-project.org > > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta > > > > > _______________________________________________ > GSoC-PortA mailing list > GSoC-PortA at lists.r-forge.r-project.org > http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta > -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock