[GSoC-PortA] Visualize eq risk contrib portf

Wed Oct 2 20:18:48 CEST 2013

Here it is in HHI space with the hull identified...  I've figured out how
to find those, although it will need to be generalized.

pcc
-- 
Peter Carl
http://www.braverock.com/peter

> 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
>>
>>
> _______________________________________________
> 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-wHull.png
Type: image/png
Size: 50779 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131002/653ddf88/attachment-0001.png>