[GSoC-PortA] Visualize eq risk contrib portf

Peter Carl peter at braverock.com
Wed Oct 2 18:00:17 CEST 2013 

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConcPercESContrib.png
Type: image/png
Size: 58589 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131002/b0a945d1/attachment-0001.png>

More information about the GSoC-PortA mailing list