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
investment mandate allows to give you the greatest possible room for
allocations. Sector or Factor constraints likewise should be as minimal
possible just to guarantee the degree of diversification described in
investment mandate.
The reason I'm suggesting this minimal constraint set is one of the
we wrote the random portfolio code in the first place. To see what I
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
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
moderate shrinkage actually decreases the possible impact of estimation
error in the various inputs, a little. Large amounts of shrinkage
restrictive constraints) will do the opposite, and magnify the negative
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
Patrick Burns as well as papers on the simplex models in
but the literature is not vast.
Numerical solvers become important as the feasible space becomes
One of the things that can create a non-smooth feasible space is a
overlapping constraint set.
The rportfolios package proposed by Frederick Novomestky also seems to
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
matrices of weights that are likely compatible with the
random or seed portfolio inputs. So if it works for you, that's great.
You also discuss using rejection after generating the portfolios. This
the method used internally by random.portfolios to reject individual
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
used by the current code. PortfolioAnalytics also allows portfolios to
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
up by Rcpp. It is possible that more efficient algorithms are available
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
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
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
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
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
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
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
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
on
translating it to cpp
Thank you,
On Mon, Mar 20, 2017 at 4:04 PM, Ross Bennett <
rossbennett34 at gmail.com>
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
of the feasible space and seems like I need to implement an Rcpp
version
the random portfolios function. I will be happy to collaborate and
share
code once i get a decent handle on it locally for the purposes of
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
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,
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
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
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
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]]