[GSoC-PortA] Visualize eq risk contrib portf

Ross Bennett rossbennett34 at gmail.com
Wed Oct 2 19:50:52 CEST 2013 

Very cool! Interesting to view the portfolios in mean-ETL and mean-HHI
space.

Thanks for sharing!

Ross


On Wed, Oct 2, 2013 at 11:22 AM, Peter Carl <peter at braverock.com> wrote:

> Proof that the prior plot does what I said it would...
> --
> Peter Carl
> http://www.braverock.com/peter
>
> > Changed the subject line, since I changed the subject.
> >
> > Here's a graph of the random portfolios colored by degree of
> concentration
> > in contribution of risk.  I used the HHI to measure it for each
> individual
> > portfolio, then normalized it and added a multiplier to match to a skewed
> > color space.
> >
> > Cool, eh?  I skewed the color space mainly to emphasize those that are
> the
> > closest to the equal weight contribution ideal, but in truth the position
> > limits keep the HHI between .143 (1/7) and about 0.35; so the range is
> > pretty small.  Keep in mind that if risk and weights were equivalent, the
> > maximum HHI measure based on weights would be 0.23...
> >
> > I think this gets to the heart of the matter, and might suggest a method
> > for measuring and showing the efficient frontier.  It's not entirely
> > straight forward from looking at this plot - probably better done in HHI
> > space to see how pointed that space really is.  BTW, this plots as a cone
> > in mean-HHI space.
> >
> > pcc
> > --
> > Peter Carl
> > http://www.braverock.com/peter
> >
> >> 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
> >>>
> >>>
> >> _______________________________________________
> >> 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/20131002/a03edf87/attachment.html>

More information about the GSoC-PortA mailing list