[GSoC-PortA] Problem with ROI solvers?

Wed Oct 2 04:31:46 CEST 2013

Peter,

I think you bring up a really interesting point about the properties or
behavior of equal risk contribution portfolios. In a different email thread
on this list (I think the subject line was "Portfolio Vignette") Brian
mentioned that a portfolio with a risk budget objective will likely place
the portfolio on the interior of the space, depending on the objectives. I
believe this is just an example where that is the case. I'm just
piggybacking off of what Brian said and haven't spent much time thinking
about this - it would be an interesting research project and this is a nice
example.

The chart.EfficientFrontier function traces the edge of the feasible
portfolios in risk-return space. Where "feasible" means that the weights
satisfy the constraints - so the points along the efficient frontier are
not necessarily equal risk contribution portfolios. It might also be
interesting looking at the neighbor portfolios because the neighbor
portfolios will be near equal risk contribution. You should be able to see
how close to equal contribution the neighbor portfolios are with the
chart.RiskBudget function. Comparing the optimal portfolio to the space of
neighbor portfolios might give more detail.

Another thing to note is that the neighbor portfolios may not be the
portfolios closest to equal risk contribution. The neighbor portfolios, as
extracted by specifying neighbors=N, are the N nearest portfolios based on
the "out" column. There could be many equal risk contribution portfolios
(which is why you specify a sub-objective) and you could extract the
nearest equal risk contribution portfolios to plot as neighbors.

Thanks for the kind words! I'm grateful for the opportunity to contribute
to the package and glad that you are happy with what I have done.

Thanks,
Ross

On Tue, Oct 1, 2013 at 5:51 PM, Peter Carl <peter at braverock.com> wrote:

> Ross,
>
> Thanks very much for taking the time to look into that - I really
> appreciate it.
>
> I hope you don't mind another question, this related to the attached
> graph.  I note that the efficient frontier is identifying a higher-return
> lower-risk portfolio than the identified optimal, if I'm interpreting it
> correctly.
>
> Generated with:
> > chart.EfficientFrontier(EqmETL.RND)
>
> Is there something I'm missing?
>
> Btw, I think it's ok with the Google overlords to tell you that you had a
> great summer, and that I really appreciate what you've done.  I'm looking
> forward to your continued contribution!
>
> pcc
> --
> Peter Carl
> http://www.braverock.com/peter
>
> > Peter,
> >
> > I suspected this might be the case and did confirm it for the results in
> > the mean-StdDev space. The plot is using the objective measures from the
> > extractStats output of the EqmETL.RND object and these are calculated
> with
> > clean="boudt" whereas the buoys.portfmeas as well as MinSD.ROI are
> > calculated with clean="none".
> >
> > From the graph, it looks like the minimum StdDev for the random
> portfolios
> > is 0.0095. This is close to the result I get with the following test:
> >
> >> R.clean <- Return.clean(R=R, method="boudt")
> >>
> >> tmpSD <- vector("numeric", length=nrow(rp))
> >> tmpSDcleanR <- vector("numeric", length=nrow(rp))
> >> for(i in 1:nrow(rp)){
> > +   tmpSD[i] <- StdDev(R=R, weights=rp[i,])
> > +   tmpSDcleanR[i] <- StdDev(R=R.clean, weights=rp[i,])
> > + }
> >>
> >> min(tmpSD)
> > [1] 0.01020511
> >> min(tmpSDcleanR)
> > [1] 0.009514874
> >> as.numeric(MinSD.ROI$objective_measures)
> > [1] 0.01009001
> >
> > Ross
> >
> > On Sat, Sep 28, 2013 at 1:04 PM, Peter Carl <peter at braverock.com> wrote:
> >
> >> I think I might have found the issue.  In the RP solvers, I was using
> >> clean="boudt", but wasn't passing in anything into the ROI solvers.
> >> That
> >> would be a big difference...
> >>
> >> I'll confirm that is the issue later, and come back if it wasn't.
> >>
> >> Thanks for listening.
> >>
> >> pcc
> >> --
> >> Peter Carl
> >> http://www.braverock.com/peter
> >>
> >> > Whoops, I hit "send" too early.
> >> >
> >> > That's the gist of the message, though.  I'll check in all my recent
> >> > changes and the RP result so that you can reproduce these results.
> >> Let
> >> me
> >> > know if you have any other ideas or see issues in how I've laid out
> >> the
> >> > constraint objects.
> >> >
> >> > Thanks in advance,
> >> >
> >> > pcc
> >> > --
> >> > Peter Carl
> >> > http://www.braverock.com/peter
> >> >
> >> > I hit a bump in the road a couple of days ago when I looked at the two
> >> > attached charts.  One shows the mean-ETL of a set of different
> >> objectives
> >> > against a cloud of random portfolios.  The objectives that can be are
> >> > calculated through ROI; I used RP for most of the others and DE for
> >> the
> >> > risk budget objective.
> >> >
> >> > Note that the cloud of RP portfolios shows portfolios with lower mETL
> >> than
> >> > the indicated MinmETL portfolio.  Well, maybe the mETL space isn't
> >> convex?
> >> >  Turns out, you can see the same issue in the attached mean-SD space
> >> with
> >> > the minSD portfolio.
> >> >
> >> > I went back and re-calculated the RP portfolios to eliminate the
> >> wiggle
> >> we
> >> > usually give the boundaries (a two percent leeway to speed up
> >> portfolio
> >> > generation) reasoning that those might be the issue.  I generated 10K
> >> > RP's, of which about 3K summed exactly to 1.0 (which is plenty).  So I
> >> > know that it isn't that those portfolios are out of bounds relative to
> >> the
> >> > constraints objects.
> >> >
> >> > I've tried to make sure that every objective is using the same
> >> > constraints, and I've double-checked my post processing to make sure I
> >> > wasn't damaging the output from the optimization runs to get things
> >> into
> >> > charts.
> >> >
> >> > This suggests to me that it's a deeper problem, although there still
> >> just
> >> > might be an issue in my code somewhere.
> >> > --
> >> > Peter Carl
> >> > http://www.braverock.com/peter
> >> >
> >> > _______________________________________________
> >> > 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/20131001/873cb9ba/attachment.html>