[R-SIG-Finance] random portfolios

Ross Bennett rossbennett34 at gmail.com
Tue Mar 21 12:24:36 CET 2017 

Just wanted to point out an example of what Brian mentioned for
visualizing the feasible space with different constraint sets.
Visualizations here
http://rossb34.github.io/PortfolioAnalyticsPresentation2016/#22 on
slides 22-26 and code
https://github.com/rossb34/PortfolioAnalyticsPresentation2016/blob/master/feasible_space.R
to produce the plots.

Ross


On Tue, Mar 21, 2017 at 5:41 AM, Brian G. Peterson <brian at braverock.com> wrote:
> The process you describe is pretty standard for an investment-committee
> driven process.
>
> I'm going to suggest that you don't really want to change the constraints
> that often.  For example, box constraints should be as large as your overall
> investment mandate allows to give you the greatest possible room for
> allocations.  Sector or Factor constraints likewise should be as minimal as
> possible just to guarantee the degree of diversification described in your
> investment mandate.
>
> The reason I'm suggesting this minimal constraint set is one of the reasons
> we wrote the random portfolio code in the first place.  To see what I mean,
> generate a set of unconstrained random portfolios (or e.g. only with a
> full-investment constraint).  Then generate sets of constrained random
> portfolios, adding your various constraint sets. Plot the different sets on
> the same risk/return scatter plot, using different colors for each set.
> Note how small the feasible space becomes, very quickly.
>
> This shrinkage of the feasible space has some good shrinkage properties...
> moderate shrinkage actually decreases the possible impact of estimation
> error in the various inputs, a little.  Large amounts of shrinkage (overly
> restrictive constraints) will do the opposite, and magnify the negative out
> of sample impact of estimation error.
>
> The academic literature mostly focuses on analytical solvers (e.g.
> quadratic, linear, etc) and simple constraint sets.  We've cited papers by
> Patrick Burns as well as papers on the simplex models in PortfolioAnalytics,
> but the literature is not vast.
>
> Numerical solvers become important as the feasible space becomes non-smooth.
> One of the things that can create a non-smooth feasible space is a complex,
> overlapping constraint set.
>
> The rportfolios package proposed by Frederick Novomestky also seems to be an
> R-only implementation, at a glance relying on truncated random binomial
> vectors rather than truncated random uniform vectors.  I believe it will
> have similar performance characteristics to the Burns-style random sample
> portfolios, and it seems to support fewer constraint sets (no overlapping
> sector, group, or factor constraints that I see).  In any case, it generates
> matrices of weights that are likely compatible with the PortfolioAnalytics
> random or seed portfolio inputs.  So if it works for you, that's great.
>
> You also discuss using rejection after generating the portfolios.  This is
> the method used internally by random.portfolios to reject individual weights
> if a constraint is violated.  I'll have to evaluate whether the truncdist
> package used by rportfolios could be more efficient than the runif that is
> used by the current code.  PortfolioAnalytics also allows portfolios to be
> penalized in the solver, so that more complex cases can be considered, or
> interactions between constraints and objectives.
>
> To answer the question of whether Rcpp will help is somewhat complex. I'm
> confident that some of the nested loops in the generation code will be sped
> up by Rcpp.  It is possible that more efficient algorithms are available for
> constructing the weight vectors.  A reason that this hasn't been a huge
> priority though is that construction of the random portfolio matrix is
> usually not the time limiter in a large optimization: your objective
> function is.  I think it will be possible to improve the efficiency of this
> step, though it is unclear how much of an impact this should have in
> practice to a large and complicated numerically solved portfolio
> optimization problem.
>
> Regards,
>
> Brian
>
>
>
>
> On 03/20/2017 07:06 PM, Kevin Dhingra wrote:
>>
>> Brian,
>>
>> Yes I think that will be a good starting point. My universe would not
>> change a lot (I will be working with 10-15 benchmarks at a time and I
>> guess
>> I can generate a reusable set for each independently before running it
>> through my main algorithm). Having said that, I envision the investment
>> mandates/constraints changing quite a lot (both in the cross section and
>> also over time for the same manager). I am hoping there must be a way
>> around it using rejection sampling but have not done enough research to
>> comment on how that solution works for such big dimensions. It will be
>> really helpful if you could point me to any specific resources from
>> academia for the same (Haven't been able to find much about random
>> portfolios myself except Portfolio Analytics and Patrick Burns work on
>> Portfolio Probe). As a side note - Do you think translating it using Rcpp
>> would be time well spent or you think there must be a smarter way to get
>> around it still using R?
>>
>> I really appreciate your help on this thread.
>>
>> Regards,
>> Kshitij Dhingra
>>
>> On Mon, Mar 20, 2017 at 7:21 PM, Brian G. Peterson <brian at braverock.com>
>> wrote:
>>
>>> For this type of problem, I would probably generate one set of random
>>> portfolios and just reuse that set of feasible portfolios...  My usual
>>> rule
>>> is n-assets + 1-2k feasible portfolios.  You can get a better number e.g.
>>> from sampling theory, but this should be enough.
>>>
>>> Once you have this weights matrix rp, you only need to regenerate rp if
>>> your universe changes.
>>>
>>> Still interested in a more efficient implementation, of course, or we can
>>> work with you to see if we can find resources to work on it, e.g. from
>>> academia.
>>>
>>> Regards,
>>>
>>> Brian
>>>
>>>
>>> On 03/20/2017 05:28 PM, Kevin Dhingra wrote:
>>>
>>>> Hi Ross,
>>>>
>>>> Sure. Even though I have not profiled the bottlenecks quite in detail as
>>>> of
>>>> yet, i will give you a decent idea of the problem I am working with. I
>>>> can
>>>> have multiple indices with as much as 2000 assets with group, position
>>>> and
>>>> turnover limits (Not sure if i can increase the speed by removing
>>>> constraints and doing rejection sampling later). In order to generate a
>>>> daily possible set for the market in this case, I was playing around
>>>> with
>>>> ~4-5 thousand permutations. Also I think I will end up using the
>>>> "sample"
>>>> method because of the type of constraints we have and as you already
>>>> have
>>>> mentioned that method is the slowest (takes about 30 times the time
>>>> using
>>>> "simplex" for the same constraints). Adding box and position limit
>>>> constraints are causing it to run a bit slower (but its not a big
>>>> difference). I can always provide a more thorough analysis of the
>>>> potential
>>>> bottlenecks with a lot more detail when I have a chance to start working
>>>> on
>>>> translating it to cpp
>>>>
>>>> Thank you,
>>>>
>>>> On Mon, Mar 20, 2017 at 4:04 PM, Ross Bennett <rossbennett34 at gmail.com>
>>>> wrote:
>>>>
>>>> Kevin,
>>>>>
>>>>>
>>>>> Can you give us a sense of the number of assets in the portfolio and
>>>>> the constraints? That will help us understand where the potential
>>>>> bottlenecks are in the random portfolio generation. For example,
>>>>> generating a set of random portfolios for box and weight constraints
>>>>> if relatively fast, but adding group or position limit constraints
>>>>> makes the algorithm more complicated and slower.
>>>>>
>>>>> Thanks,
>>>>> Ross
>>>>>
>>>>>
>>>>> On Mon, Mar 20, 2017 at 2:35 PM, Kevin Dhingra
>>>>> <kevin.dhingra at appliedacademics.com> wrote:
>>>>>
>>>>>> Brian,
>>>>>>
>>>>>> Thank you for a quick reply. I will soon be working on that problem
>>>>>> and
>>>>>> from what I have played with so far, it is unlikely that for our
>>>>>> example
>>>>>> ~2k portfolios will be enough (really hoping it would) to get a good
>>>>>>
>>>>> sense
>>>>>
>>>>>> of the feasible space and seems like I need to implement an Rcpp
>>>>>> version
>>>>>>
>>>>> of
>>>>>
>>>>>> the random portfolios function. I will be happy to collaborate and
>>>>>> share
>>>>>>
>>>>> my
>>>>>
>>>>>> code once i get a decent handle on it locally for the purposes of our
>>>>>> current project.
>>>>>>
>>>>>> Regards,
>>>>>> Kshitij Dhingra
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 20, 2017 at 3:17 PM, Brian G. Peterson
>>>>>> <brian at braverock.com
>>>>>>>
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Mon, 2017-03-20 at 15:09 -0400, Kevin Dhingra wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I have been using the random_portfolios function from the
>>>>>>>> `PortfolioAnalytics` package to simulate the range of possibilities
>>>>>>>> for return paths at each step under various portfolio constraints /
>>>>>>>> mandates for evaluating mutual fund managers. As more managers are
>>>>>>>> added to the universe, however, and more simulations are needed, the
>>>>>>>> pure R implementations get pretty heavy and hard to scale. I was
>>>>>>>> wondering if there has been any work out there thus far on
>>>>>>>> implementing any of the three random portfolio generation methods
>>>>>>>> (sample, simplex, and grid search) at a lower level, using something
>>>>>>>> like `Rcpp` to enhance the efficiency of these algorithms?
>>>>>>>>
>>>>>>>
>>>>>>> We've discussed it, but I can't say that it is terribly high on our
>>>>>>> list of priorities.
>>>>>>>
>>>>>>> In most cases, no more than 1-2k portfolios should be required to get
>>>>>>> a
>>>>>>> fair view of the feasible space given your constraints and
>>>>>>> objectives.
>>>>>>>
>>>>>>> We'd be happy to work with you if you want to craft a patch to use C
>>>>>>> or
>>>>>>> Rcpp for this.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kshitij Dhingra
>>>>>> Applied Academics LLC
>>>>>> Office: +1.917.262.0516
>>>>>> Mobile: +1.206.696.5945
>>>>>> Email: kshitij.dhingra at appliedacademics.com
>>>>>> Website: http://www.AppliedAcademics.com
>>>>>>
>>>>>>         [[alternative HTML version deleted]]
>>>>>>
>>>>>> _______________________________________________
>>>>>> R-SIG-Finance at r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>>>>>> -- Subscriber-posting only. If you want to post, subscribe first.
>>>>>> -- Also note that this is not the r-help list where general R
>>>>>> questions
>>>>>>
>>>>> should go.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Brian G. Peterson
>>> http://braverock.com/brian/
>>> Ph: 773-459-4973
>>> IM: bgpbraverock
>>>
>>>
>>> _______________________________________________
>>> R-SIG-Finance at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>>> -- Subscriber-posting only. If you want to post, subscribe first.
>>> -- Also note that this is not the r-help list where general R questions
>>> should go.
>>>
>>
>>
>>
>
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
>
> _______________________________________________
> R-SIG-Finance at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> -- Subscriber-posting only. If you want to post, subscribe first.
> -- Also note that this is not the r-help list where general R questions
> should go.

More information about the R-SIG-Finance mailing list