[GSoC-PortA] Visualize eq risk contrib portf

Peter Carl peter at braverock.com
Wed Oct 2 18:22:23 CEST 2013 

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

More information about the GSoC-PortA mailing list