[GSoC-PortA] Random portfolios

[Ross Bennett]

The check for min_sum and max_sum is done right away in
randomize_portfolio_v2. The main reason why I added this check and wiggle
room for min_sum and max_sum inside of the function is to speed up
generating the random portfolio and ensure that a reasonable number of
portfolios can be generated.

Another logical place for this check would be in the check_constraints
function, this would prevent portfolios being eliminated. Even if we do
this check here, constrained_objective will penalize a large number of sets
of weights that do not sum to exactly 1. I think it also might make sense
to add a check in optimize.portfolio and issue a warning to the user that
min_sum and max_sum may be too restrictive. This will apply to
optimize_method="random" and optimize_method="DEoptim" because we are using
logic from random portfolios as a mapping function in DEoptim.

Ross


On Tue, Sep 24, 2013 at 9:52 AM, Peter Carl <peter at braverock.com> wrote:

> Thanks, that does work.  Should the check done in randomize_portfolio_v2
> be moved up the chain to catch that issue earlier?
> --
> Peter Carl
> http://www.braverock.com/peter
>
> > The reason for fewer random portfolios being generated is due to the
> > leverage constraints in init.portf. There is a block of code in
> > randomize_portfolio_v2 (which is called by rp_sample) that will check for
> > a
> > difference in min_sum and max_sum. For example, if min_sum=1 and
> > max_sum=1,
> > we temporarily modify min_sum=0.99 and max_sum=1.01 so that random
> > portfolios can be generated.
> >
> > Then in random_portfolios, there is a block of code that eliminates
> > portfolios that do not satisfy the constraints with the check_constraints
> > function. This takes place for random portfolios generated by the sample,
> > simplex, and grid method. Because rp_sample will generate portfolios with
> > weights that sum from 0.99 to 1.01, there are several portfolios that
> > violate leverage constraints of min_sum=1 and max_sum=1 and therefore
> will
> > be eliminated.
> >
> > If you change the init.portf leverage constraints to min_sum=0.99 and
> > max_sum=1.01 you should generate 1000 portfolios.
> >
> > I'll add some of this content to the @details in random_portfolios to
> > explain how the function is sensitive to leverage constraints.
> >
> > Thanks,
> > Ross
> >
> >
> >
> >
> > On Tue, Sep 24, 2013 at 8:15 AM, Ross Bennett
> > <rossbennett34 at gmail.com>wrote:
> >
> >> Thanks for making me aware of this. I'll take a closer look and try to
> >> figure out what is going on.
> >>
> >> Ross
> >> On Sep 24, 2013 8:03 AM, "Peter Carl" <peter at braverock.com> wrote:
> >>
> >>> Fair point.  I get the same result when I use high values for
> >>> max_permutations.  That attribute should probably be referenced in the
> >>> function documentation under details, so that users know it can be
> >>> passed
> >>> through dots.
> >>>
> >>> Same result though.  When I call rp_sample directly:
> >>> rp_sample(init.portf, permutations=1000)
> >>> ... I get 1000 rows back.
> >>>
> >>> So something's happening in the dispatch code?
> >>>
> >>> pcc
> >>> --
> >>> Peter Carl
> >>> http://www.braverock.com/peter
> >>>
> >>> > On 09/24/2013 09:28 AM, Peter Carl wrote:
> >>> >> The random_portfolios function isn't generating the correct number
> >>> of
> >>> >> permutations.
> >>> >>
> >>> >>> >random_portfolios(portfolio=init.portf, permutations=1000)
> >>> >> gives me a result with 317 weight vectors, rather than 1000.
> >>> >>
> >>> >> I think that there's a loop missing: when the number of lines is
> >>> less
> >>> >> than
> >>> >> permutations, the function needs to generate more, check for unique
> >>> >> solutions, and repeat until there are (in this case) 1000 weight
> >>> >> vectors.
> >>> >>
> >>> >> Although (and it's difficult to tell), on their own the charts seem
> >>> to
> >>> >> generate about the right number?  Or maybe not...
> >>> >
> >>> > I suspect that given your constraints you're just hitting
> >>> > max_permutations.
> >>> >
> >>> > All that code is still there, so it seems most likely that you just
> >>> > don't have max_permutations high enough, or that your granularity on
> >>> the
> >>> > sequence is too high (e.g. you're using a step size of .01, and
> >>> should
> >>> > try .005)
> >>> >
> >>> > --
> >>> > 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
> >
>
>
> _______________________________________________
> 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: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20130924/c48a47d5/attachment-0001.html>