From rossbennett34 at gmail.com Mon May 19 17:20:20 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Mon, 19 May 2014 08:20:20 -0700 Subject: [GSoC-PortA] GSoC Timeline/Kickoff Message-ID: Mentors (and others on the list), It was great seeing you all at R/Finance last week. Here are the first 3 tasks in the timeline in my original proposal. 5/19 - 5/30: Multilayer Optimization 5/31 - 6/13: Regime Switching Optimization 6/14 - 6/27: Factor Portfolio Optimization I would like to modify the timeline as follows: 5/19 - 5/30: Regime Switching Optimization 5/31 - 6/13: Factor Portfolio Optimization 6/14 - 6/27: Multilayer Optimization Regime Switching Optimization My code example for the proposal was for regime switching. I kept it pretty general so that the user can just pass in a time series of what portfolio to use depending on the regime for any arbitrary regime switching model. Do you have any comments or feedback on my proposed way for supporting regime switching? The regime switching example is in the following code gist https://gist.github.com/rossb34/9645489 Factor Models to Estimate Moments I reached out to Kris Boudt a few weeks ago and he shared some of the code he used for his paper. I put together a small package as a prototype. One thing to note is that Kris sent me C++ code (using Rcpp) for computing the cokurtosis error matrix. I would prefer not to rewrite the code in R, but this does mean introducing a dependency on Rcpp. Along these same lines, we could also write functions to compute the 3rd and 4th moments in C++. The Armadillo library has a kron() function to compute the kronecker product making the higher moments an easy computation using RcppArmadillo. We could do this as a prototype in PortfolioAnalytics and eventually move to PerformanceAnalytics so M3.MM and M4.MM are compiled code. Thoughts? Here is the source code of the prototype package for moment estimates. https://bitbucket.org/rossbennett34/momentestimation/src Best, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrd at comcast.net Mon May 19 17:37:13 2014 From: martinrd at comcast.net (Doug Martin) Date: Mon, 19 May 2014 08:37:13 -0700 Subject: [GSoC-PortA] GSoC Timeline/Kickoff In-Reply-To: References: Message-ID: <007601cf7378$39751d40$ac5f57c0$@comcast.net> Two initial comments about regime switching models and their use, keeping mind that I haven?t looked at the proposal in a long time (maybe send it along): 1) There are a lot of models and they tend to be complex. The good news is that this PortfolioAnalytics development will support people to more (badly needed) research on what models are really worth using. 2) As for use in portfolio optimization a main feature needed is allow the user to specify how to blend data from a prior regime (or regimes) and the new regime for which you at first have very little data (maybe you already included this in the proposal?) 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: Monday, May 19, 2014 8:20 AM To: PortfolioAnalytics Subject: [GSoC-PortA] GSoC Timeline/Kickoff Mentors (and others on the list), It was great seeing you all at R/Finance last week. Here are the first 3 tasks in the timeline in my original proposal. 5/19 - 5/30: Multilayer Optimization 5/31 - 6/13: Regime Switching Optimization 6/14 - 6/27: Factor Portfolio Optimization I would like to modify the timeline as follows: 5/19 - 5/30: Regime Switching Optimization 5/31 - 6/13: Factor Portfolio Optimization 6/14 - 6/27: Multilayer Optimization Regime Switching Optimization My code example for the proposal was for regime switching. I kept it pretty general so that the user can just pass in a time series of what portfolio to use depending on the regime for any arbitrary regime switching model. Do you have any comments or feedback on my proposed way for supporting regime switching? The regime switching example is in the following code gist https://gist.github.com/rossb34/9645489 Factor Models to Estimate Moments I reached out to Kris Boudt a few weeks ago and he shared some of the code he used for his paper. I put together a small package as a prototype. One thing to note is that Kris sent me C++ code (using Rcpp) for computing the cokurtosis error matrix. I would prefer not to rewrite the code in R, but this does mean introducing a dependency on Rcpp. Along these same lines, we could also write functions to compute the 3rd and 4th moments in C++. The Armadillo library has a kron() function to compute the kronecker product making the higher moments an easy computation using RcppArmadillo. We could do this as a prototype in PortfolioAnalytics and eventually move to PerformanceAnalytics so M3.MM and M4.MM are compiled code. Thoughts? Here is the source code of the prototype package for moment estimates. https://bitbucket.org/rossbennett34/momentestimation/src Best, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.m.ulrich at gmail.com Mon May 19 17:56:26 2014 From: josh.m.ulrich at gmail.com (Joshua Ulrich) Date: Mon, 19 May 2014 10:56:26 -0500 Subject: [GSoC-PortA] GSoC Timeline/Kickoff In-Reply-To: References: Message-ID: On Mon, May 19, 2014 at 10:20 AM, Ross Bennett wrote: > Mentors (and others on the list), > > Factor Models to Estimate Moments > > I reached out to Kris Boudt a few weeks ago and he shared some of the code > he used for his paper. I put together a small package as a prototype. One > thing to note is that Kris sent me C++ code (using Rcpp) for computing the > cokurtosis error matrix. I would prefer not to rewrite the code in R, but > this does mean introducing a dependency on Rcpp. Along these same lines, we > could also write functions to compute the 3rd and 4th moments in C++. The > Armadillo library has a kron() function to compute the kronecker product > making the higher moments an easy computation using RcppArmadillo. We could > do this as a prototype in PortfolioAnalytics and eventually move to > PerformanceAnalytics so M3.MM and M4.MM are compiled code. Thoughts? > I did the initial coskew/cokurt port from R to Rcpp. The code I wrote looks similar to what's in the residualcokurtosis*F.cpp files. They're not complicated functions. If adding a dependency on Rcpp is a big deal, the code would be easy to re-write using R's regular C API. You don't want to write these in R. I don't remember what the speed gains were, but they were very large. I have profiled and improved R versions of M3.MM and M4.MM. I'm not sure how they compare to the new Rcpp versions though. > Here is the source code of the prototype package for moment estimates. > > https://bitbucket.org/rossbennett34/momentestimation/src > > > Best, > > Ross > Best, -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com From rossbennett34 at gmail.com Mon May 19 18:17:34 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Mon, 19 May 2014 09:17:34 -0700 Subject: [GSoC-PortA] GSoC Timeline/Kickoff In-Reply-To: <007601cf7378$39751d40$ac5f57c0$@comcast.net> References: <007601cf7378$39751d40$ac5f57c0$@comcast.net> Message-ID: On Mon, May 19, 2014 at 8:37 AM, Doug Martin wrote: > Two initial comments about regime switching models and their use, keeping > mind that I haven?t looked at the proposal in a long time (maybe send it > along): > > > > 1) There are a lot of models and they tend to be complex. The good > news is that this PortfolioAnalytics development will support people to > more (badly needed) research on what models are really worth using. > > > > 2) As for use in portfolio optimization a main feature needed is > allow the user to specify how to blend > > data from a prior regime (or regimes) and the new regime for which you at > first have very little data (maybe you already included this in the > proposal?) > That was not included in my proposal, but could be considered. Link to proposal http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rossbennett34/5747559595245568 > > > 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:* Monday, May 19, 2014 8:20 AM > *To:* PortfolioAnalytics > *Subject:* [GSoC-PortA] GSoC Timeline/Kickoff > > > > Mentors (and others on the list), > > > > It was great seeing you all at R/Finance last week. > > > > Here are the first 3 tasks in the timeline in my original proposal. > > 5/19 - 5/30: Multilayer Optimization > > 5/31 - 6/13: Regime Switching Optimization > > 6/14 - 6/27: Factor Portfolio Optimization > > > > I would like to modify the timeline as follows: > > 5/19 - 5/30: Regime Switching Optimization > > 5/31 - 6/13: Factor Portfolio Optimization > > 6/14 - 6/27: Multilayer Optimization > > > > Regime Switching Optimization > > My code example for the proposal was for regime switching. I kept it > pretty general so that the user can just pass in a time series of what > portfolio to use depending on the regime for any arbitrary regime switching > model. Do you have any comments or feedback on my proposed way for > supporting regime switching? > > The regime switching example is in the following code gist > > https://gist.github.com/rossb34/9645489 > > Factor Models to Estimate Moments > > I reached out to Kris Boudt a few weeks ago and he shared some of the code > he used for his paper. I put together a small package as a prototype. One > thing to note is that Kris sent me C++ code (using Rcpp) for computing the > cokurtosis error matrix. I would prefer not to rewrite the code in R, but > this does mean introducing a dependency on Rcpp. Along these same lines, > we could also write functions to compute the 3rd and 4th moments in C++. > The Armadillo library has a kron() function to compute the kronecker > product making the higher moments an easy computation using RcppArmadillo. > We could do this as a prototype in PortfolioAnalytics and eventually move > to PerformanceAnalytics so M3.MM and M4.MM are compiled code. Thoughts? > > Here is the source code of the prototype package for moment estimates. > > https://bitbucket.org/rossbennett34/momentestimation/src > > > > Best, > > Ross > > _______________________________________________ > 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 May 19 18:27:35 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Mon, 19 May 2014 09:27:35 -0700 Subject: [GSoC-PortA] GSoC Timeline/Kickoff In-Reply-To: References: Message-ID: On Mon, May 19, 2014 at 8:56 AM, Joshua Ulrich wrote: > On Mon, May 19, 2014 at 10:20 AM, Ross Bennett > wrote: > > Mentors (and others on the list), > > > > > > Factor Models to Estimate Moments > > > > I reached out to Kris Boudt a few weeks ago and he shared some of the > code > > he used for his paper. I put together a small package as a prototype. One > > thing to note is that Kris sent me C++ code (using Rcpp) for computing > the > > cokurtosis error matrix. I would prefer not to rewrite the code in R, but > > this does mean introducing a dependency on Rcpp. Along these same > lines, we > > could also write functions to compute the 3rd and 4th moments in C++. The > > Armadillo library has a kron() function to compute the kronecker product > > making the higher moments an easy computation using RcppArmadillo. We > could > > do this as a prototype in PortfolioAnalytics and eventually move to > > PerformanceAnalytics so M3.MM and M4.MM are compiled code. Thoughts? > > > I did the initial coskew/cokurt port from R to Rcpp. The code I wrote > looks similar to what's in the residualcokurtosis*F.cpp files. They're > not complicated functions. If adding a dependency on Rcpp is a big > deal, the code would be easy to re-write using R's regular C API. You > don't want to write these in R. I don't remember what the speed gains > were, but they were very large. > I used the residualcokurtosis*F.cpp files that Kris sent me without making any changes so these are the exact functions you wrote. > > I have profiled and improved R versions of M3.MM and M4.MM. I'm not > sure how they compare to the new Rcpp versions though. > You can install the moment estimation package with devtools::install_bitbucket("MomentEstimation", "rossbennett34") Here is a link to the script I have in the prototype package to test the Rcpp versions of M3.MM and M4.MM with PerformanceAnalytics. https://bitbucket.org/rossbennett34/momentestimation/src/e4ecc303a15e2b4175aab38b6e416e03f168893a/sandbox/momentBench.R?at=master It would be interesting to see the performance comparison of your improved R versions. > > > Here is the source code of the prototype package for moment estimates. > > > > https://bitbucket.org/rossbennett34/momentestimation/src > > > > > > Best, > > > > Ross > > > > Best, > -- > Joshua Ulrich | about.me/joshuaulrich > FOSS Trading | www.fosstrading.com > _______________________________________________ > 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 peter at braverock.com Mon May 19 18:05:15 2014 From: peter at braverock.com (Peter Carl) Date: Mon, 19 May 2014 11:05:15 -0500 Subject: [GSoC-PortA] GSoC Timeline/Kickoff In-Reply-To: References: Message-ID: <537A2BBB.3080901@braverock.com> Here's some background reading from April's edition of the Journal of Finance. This is slightly off topic, but I had been intending to send this paper to this group and this reminded me that I should send it around. The conclusion: For portfolios to perform well out of sample, it is important to incorporate an ensemble of methods that cover stochastic volatility, time-varying return expectation, AND parameter uncertainty. It would be great to take this paper as an excuse to start to develop best practices for some of these issues. pcc On 05/19/2014 10:20 AM, Ross Bennett wrote: > Mentors (and others on the list), > > It was great seeing you all at R/Finance last week. > > Here are the first 3 tasks in the timeline in my original proposal. > > 5/19 - 5/30: Multilayer Optimization > > 5/31 - 6/13: Regime Switching Optimization > > 6/14 - 6/27: Factor Portfolio Optimization > > > I would like to modify the timeline as follows: > > 5/19 - 5/30: Regime Switching Optimization > > 5/31 - 6/13: Factor Portfolio Optimization > > 6/14 - 6/27: Multilayer Optimization > > > Regime Switching Optimization > > My code example for the proposal was for regime switching. I kept it > pretty general so that the user can just pass in a time series of what > portfolio to use depending on the regime for any arbitrary regime > switching model. Do you have any comments or feedback on my proposed > way for supporting regime switching? > > The regime switching example is in the following code gist > > https://gist.github.com/rossb34/9645489 > > Factor Models to Estimate Moments > > I reached out to Kris Boudt a few weeks ago and he shared some of the > code he used for his paper. I put together a small package as a > prototype. One thing to note is that Kris sent me C++ code (using > Rcpp) for computing the cokurtosis error matrix. I would prefer not to > rewrite the code in R, but this does mean introducing a dependency on > Rcpp. Along these same lines, we could also write functions to > compute the 3rd and 4th moments in C++. The Armadillo library has a > kron() function to compute the kronecker product making the higher > moments an easy computation using RcppArmadillo. We could do this as a > prototype in PortfolioAnalytics and eventually move to > PerformanceAnalytics so M3.MM and M4.MM > are compiled code. Thoughts? > > Here is the source code of the prototype package for moment estimates. > > https://bitbucket.org/rossbennett34/momentestimation/src > > > Best, > > Ross > > > > _______________________________________________ > 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: jofi12121.pdf Type: application/pdf Size: 790720 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jofi12121-sup-0001-AppendixS1.pdf Type: application/pdf Size: 1376802 bytes Desc: not available URL: From rossbennett34 at gmail.com Wed May 28 23:36:10 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Wed, 28 May 2014 14:36:10 -0700 Subject: [GSoC-PortA] Regime Switching Message-ID: All, I am close to wrapping up adding support for regime switching as per my proposal. I added a demo so you can see an example of the functionality (see demo/regime_switching.R). There is one issue that came up that I would like some input on. The case is running optimize.portfolio.rebalancing with optimize_method="random". If the rp object is not passed in as an argument to optimize.portfolio.rebalancing, then we try to generate the random portfolios there so the random portfolios are not (re)generated inside the loop in optimize.portfolio. Since the regime portfolio has N portfolios for N regimes, the challenge here is knowing what portfolio to use for generating the random portfolios because the constraints could be very different in each portfolio. This only impacts optimize.portfolio.rebalancing because we do not know the portfolio specification based on the regime at the time we check the rp object. We do know inside optimize.portfolio. The check for rp in optimize.portfolio.rebalancing looks like this if(optimize_method=="random"){ if(is.null(rp)) rp<-random_portfolios(portfolio=portfolio, permutations=search_size) } I have a couple proposed solutions Solution 1: Require that the user pass in a random portfolios object for the rp argument. We don't try to generate random portfolios and we throw an error if rp is null. We could just use a single rp object or allow for a list of rp objects with one rp object for each regime portfolio. Solution 2: Bypass this check and let optimize.portfolio generate random portfolios for each regime at each iteration. This is flexible, but could result in very long run times. Are there any other solutions I should consider. Please let me know your thoughts on this. Thanks, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at braverock.com Wed May 28 23:49:58 2014 From: brian at braverock.com (Brian G. Peterson) Date: Wed, 28 May 2014 16:49:58 -0500 Subject: [GSoC-PortA] Regime Switching In-Reply-To: References: Message-ID: <53865A06.7050207@braverock.com> What about generating an rp set for each portfolio constraint set, and using the superset as the rp object passed into optimize.portfolio in the loop? I think this will automatically penalize the non-conforming portfolios (or can if we set a single parameter to do so), and the conforming portfolios will be the ones chosen on a objective value basis. Should work with a minimum of messing with the code. Regards, Brian On 05/28/2014 04:36 PM, Ross Bennett wrote: > All, > > I am close to wrapping up adding support for regime switching as per my > proposal. I added a demo so you can see an example of the functionality > (see demo/regime_switching.R). > > There is one issue that came up that I would like some input on. The > case is running optimize.portfolio.rebalancing with > optimize_method="random". If the rp object is not passed in as an > argument to optimize.portfolio.rebalancing, then we try to generate the > random portfolios there so the random portfolios are not (re)generated > inside the loop in optimize.portfolio. > > Since the regime portfolio has N portfolios for N regimes, the challenge > here is knowing what portfolio to use for generating the random > portfolios because the constraints could be very different in each > portfolio. This only impacts optimize.portfolio.rebalancing because we > do not know the portfolio specification based on the regime at the time > we check the rp object. We do know inside optimize.portfolio. > > The check for rp in optimize.portfolio.rebalancing looks like this > if(optimize_method=="random"){ > if(is.null(rp)) > rp<-random_portfolios(portfolio=portfolio, permutations=search_size) > } > > I have a couple proposed solutions > > Solution 1: > Require that the user pass in a random portfolios object for the rp > argument. We don't try to generate random portfolios and we throw an > error if rp is null. We could just use a single rp object or allow for a > list of rp objects with one rp object for each regime portfolio. > > Solution 2: > Bypass this check and let optimize.portfolio generate random portfolios > for each regime at each iteration. This is flexible, but could result in > very long run times. > > Are there any other solutions I should consider. > > Please let me know your thoughts on this. > > Thanks, > Ross > > > > > _______________________________________________ > 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 From rossbennett34 at gmail.com Thu May 29 00:21:42 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Wed, 28 May 2014 15:21:42 -0700 Subject: [GSoC-PortA] Regime Switching In-Reply-To: <53865A06.7050207@braverock.com> References: <53865A06.7050207@braverock.com> Message-ID: Thanks for the suggestion, I think that makes the most sense. I'll go ahead and implement that. Ross On Wed, May 28, 2014 at 2:49 PM, Brian G. Peterson wrote: > What about generating an rp set for each portfolio constraint set, and > using the superset as the rp object passed into optimize.portfolio in the > loop? > > I think this will automatically penalize the non-conforming portfolios (or > can if we set a single parameter to do so), and the conforming portfolios > will be the ones chosen on a objective value basis. > > Should work with a minimum of messing with the code. > > Regards, > > Brian > > > On 05/28/2014 04:36 PM, Ross Bennett wrote: > >> All, >> >> I am close to wrapping up adding support for regime switching as per my >> proposal. I added a demo so you can see an example of the functionality >> (see demo/regime_switching.R). >> >> There is one issue that came up that I would like some input on. The >> case is running optimize.portfolio.rebalancing with >> optimize_method="random". If the rp object is not passed in as an >> argument to optimize.portfolio.rebalancing, then we try to generate the >> random portfolios there so the random portfolios are not (re)generated >> inside the loop in optimize.portfolio. >> >> Since the regime portfolio has N portfolios for N regimes, the challenge >> here is knowing what portfolio to use for generating the random >> portfolios because the constraints could be very different in each >> portfolio. This only impacts optimize.portfolio.rebalancing because we >> do not know the portfolio specification based on the regime at the time >> we check the rp object. We do know inside optimize.portfolio. >> >> The check for rp in optimize.portfolio.rebalancing looks like this >> if(optimize_method=="random"){ >> if(is.null(rp)) >> rp<-random_portfolios(portfolio=portfolio, >> permutations=search_size) >> } >> >> I have a couple proposed solutions >> >> Solution 1: >> Require that the user pass in a random portfolios object for the rp >> argument. We don't try to generate random portfolios and we throw an >> error if rp is null. We could just use a single rp object or allow for a >> list of rp objects with one rp object for each regime portfolio. >> >> Solution 2: >> Bypass this check and let optimize.portfolio generate random portfolios >> for each regime at each iteration. This is flexible, but could result in >> very long run times. >> >> Are there any other solutions I should consider. >> >> Please let me know your thoughts on this. >> >> Thanks, >> Ross >> >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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 May 29 18:13:09 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Thu, 29 May 2014 09:13:09 -0700 Subject: [GSoC-PortA] Factor Model Moment Estimates based on Boudt paper Message-ID: All, Some parts of this were briefly discussed in a previous email thread, but I want to get the discussion started again. The code to compute the cokurtosis error matrix for multi factor and single factor models is written in C++ and uses the Rcpp package. The functions were sent to me by Kris Boudt and written by Joshua Ulrich. Joshua did state that the speed gains were very large and we do not want to write these in R. Do we want to re-write using R's C API or should we include "as is" and use Rcpp? This raised another discussion about computing the higher moments. Right now we use M3.MM and M4.MM from PerformanceAnalytics in set.portfolio.moments to compute the sample estimates. I re-wrote these using RcppArmadillo which was fairly straightforward because Armadillo has a function to compute the kronecker product. Joshua has profiled and optimized coskewness and cokurtosis functions written in R that are very fast. They use a different algorithm to avoid the kronecker product which results in a huge performance gain. What is the plan for M3.MM and M4.MM in PerformanceAnalytics? This potentially has a big impact on PortfolioAnalytics since the moments are computed at each rebalance period iteration. See attached for a benchmark (Processor: 2.9 GHz Intel Core i7; Memory: 8 GB). Let me know your thoughts and if you have any questions or comments. Thanks, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: benchmarkM3.png Type: image/png Size: 70614 bytes Desc: not available URL: From brian at braverock.com Thu May 29 18:16:42 2014 From: brian at braverock.com (Brian G. Peterson) Date: Thu, 29 May 2014 11:16:42 -0500 Subject: [GSoC-PortA] Factor Model Moment Estimates based on Boudt paper In-Reply-To: References: Message-ID: <53875D6A.8010002@braverock.com> We should figure out a plan to put compiled higher moment functions into PerformanceAnalytics. I'll leave it to you and Josh to figure out whether Rcpp or R's native .Call API make more sense. - Brian On 05/29/2014 11:13 AM, Ross Bennett wrote: > All, > > Some parts of this were briefly discussed in a previous email thread, > but I want to get the discussion started again. > > The code to compute the cokurtosis error matrix for multi factor and > single factor models is written in C++ and uses the Rcpp package. The > functions were sent to me by Kris Boudt and written by Joshua Ulrich. > Joshua did state that the speed gains were very large and we do not want > to write these in R. > > Do we want to re-write using R's C API or should we include "as is" and > use Rcpp? > > This raised another discussion about computing the higher moments. Right > now we use M3.MM and M4.MM from > PerformanceAnalytics in set.portfolio.moments to compute the sample > estimates. I re-wrote these using RcppArmadillo which was fairly > straightforward because Armadillo has a function to compute the > kronecker product. Joshua has profiled and optimized coskewness and > cokurtosis functions written in R that are very fast. They use a > different algorithm to avoid the kronecker product which results in a > huge performance gain. > > What is the plan for M3.MM and M4.MM in > PerformanceAnalytics? > > This potentially has a big impact on PortfolioAnalytics since the > moments are computed at each rebalance period iteration. > > See attached for a benchmark (Processor: 2.9 GHz Intel Core i7; Memory: > 8 GB). > > Let me know your thoughts and if you have any questions or comments. > > Thanks, > Ross > > > _______________________________________________ > 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 From rossbennett34 at gmail.com Sat May 31 06:05:38 2014 From: rossbennett34 at gmail.com (Ross Bennett) Date: Fri, 30 May 2014 21:05:38 -0700 Subject: [GSoC-PortA] Factor Model Moment Estimates based on Boudt paper In-Reply-To: <53875D6A.8010002@braverock.com> References: <53875D6A.8010002@braverock.com> Message-ID: On Thu, May 29, 2014 at 9:16 AM, Brian G. Peterson wrote: > We should figure out a plan to put compiled higher moment functions into > PerformanceAnalytics. > I'd be glad to do the legwork on this. As I mentioned in the previous email, I have some prototype functions using RcppArmadillo based on the fast R code with the more efficient algorithm that Josh sent me. I chose RcppArmadillo because it is easy to use the matrix and vector classes from Armadillo as well as the matrix operations. I suppose it would be feasible to do this in fortran or C. What are other's thoughts? Are there any other functions in PerformanceAnalytics that you would like to move to compiled code that might impact the decision? > > I'll leave it to you and Josh to figure out whether Rcpp or R's native > .Call API make more sense. > Ok, I'll get the discussion going with Josh. > > - Brian > > > > On 05/29/2014 11:13 AM, Ross Bennett wrote: > >> All, >> >> Some parts of this were briefly discussed in a previous email thread, >> but I want to get the discussion started again. >> >> The code to compute the cokurtosis error matrix for multi factor and >> single factor models is written in C++ and uses the Rcpp package. The >> functions were sent to me by Kris Boudt and written by Joshua Ulrich. >> Joshua did state that the speed gains were very large and we do not want >> to write these in R. >> >> Do we want to re-write using R's C API or should we include "as is" and >> use Rcpp? >> >> This raised another discussion about computing the higher moments. Right >> now we use M3.MM and M4.MM from >> >> PerformanceAnalytics in set.portfolio.moments to compute the sample >> estimates. I re-wrote these using RcppArmadillo which was fairly >> straightforward because Armadillo has a function to compute the >> kronecker product. Joshua has profiled and optimized coskewness and >> cokurtosis functions written in R that are very fast. They use a >> different algorithm to avoid the kronecker product which results in a >> huge performance gain. >> >> What is the plan for M3.MM and M4.MM in >> >> PerformanceAnalytics? >> >> This potentially has a big impact on PortfolioAnalytics since the >> moments are computed at each rebalance period iteration. >> >> See attached for a benchmark (Processor: 2.9 GHz Intel Core i7; Memory: >> 8 GB). >> >> Let me know your thoughts and if you have any questions or comments. >> >> Thanks, >> Ross >> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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: