From peter at braverock.com  Wed Oct  2 02:51:33 2013
From: peter at braverock.com (Peter Carl)
Date: Tue, 1 Oct 2013 19:51:33 -0500
Subject: [GSoC-PortA] Problem with ROI solvers?
In-Reply-To: <CAEESW=XfT_gC-0v=u8VBUFhdjquTPV12wdXbCmxUivADKsJL=Q@mail.gmail.com>
References: <2c24f9bd6659bf416d8e8d995b10a6dc.squirrel@mail.braverock.com>
 <02f235525a54cb5e17d11b037f1b4fd6.squirrel@mail.braverock.com>
 <CAEESW=XfT_gC-0v=u8VBUFhdjquTPV12wdXbCmxUivADKsJL=Q@mail.gmail.com>
Message-ID: <3551c08f9295a2de184cf65aed7bfc2e.squirrel@mail.braverock.com>

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EqmETL-efffrontier.pdf
Type: application/pdf
Size: 24127 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131001/5432ea4e/attachment-0001.pdf>

From rossbennett34 at gmail.com  Wed Oct  2 04:31:46 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Tue, 1 Oct 2013 19:31:46 -0700
Subject: [GSoC-PortA] Problem with ROI solvers?
In-Reply-To: <3551c08f9295a2de184cf65aed7bfc2e.squirrel@mail.braverock.com>
References: <2c24f9bd6659bf416d8e8d995b10a6dc.squirrel@mail.braverock.com>
 <02f235525a54cb5e17d11b037f1b4fd6.squirrel@mail.braverock.com>
 <CAEESW=XfT_gC-0v=u8VBUFhdjquTPV12wdXbCmxUivADKsJL=Q@mail.gmail.com>
 <3551c08f9295a2de184cf65aed7bfc2e.squirrel@mail.braverock.com>
Message-ID: <CAEESW=Xwu6p_iqJv2MXDHdvCfazhg5QQfq7WgxCDomgqraf-6A@mail.gmail.com>

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>

From peter at braverock.com  Wed Oct  2 18:00:17 2013
From: peter at braverock.com (Peter Carl)
Date: Wed, 2 Oct 2013 11:00:17 -0500
Subject: [GSoC-PortA] Visualize eq risk contrib portf
In-Reply-To: <CAEESW=Xwu6p_iqJv2MXDHdvCfazhg5QQfq7WgxCDomgqraf-6A@mail.gmail.com>
References: <2c24f9bd6659bf416d8e8d995b10a6dc.squirrel@mail.braverock.com>
 <02f235525a54cb5e17d11b037f1b4fd6.squirrel@mail.braverock.com>
 <CAEESW=XfT_gC-0v=u8VBUFhdjquTPV12wdXbCmxUivADKsJL=Q@mail.gmail.com>
 <3551c08f9295a2de184cf65aed7bfc2e.squirrel@mail.braverock.com>
 <CAEESW=Xwu6p_iqJv2MXDHdvCfazhg5QQfq7WgxCDomgqraf-6A@mail.gmail.com>
Message-ID: <10efc192b1dc3545c70b6e36e2cf7795.squirrel@mail.braverock.com>

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>

From peter at braverock.com  Wed Oct  2 18:22:23 2013
From: peter at braverock.com (Peter Carl)
Date: Wed, 2 Oct 2013 11:22:23 -0500
Subject: [GSoC-PortA] Visualize eq risk contrib portf
In-Reply-To: <10efc192b1dc3545c70b6e36e2cf7795.squirrel@mail.braverock.com>
References: <2c24f9bd6659bf416d8e8d995b10a6dc.squirrel@mail.braverock.com>
 <02f235525a54cb5e17d11b037f1b4fd6.squirrel@mail.braverock.com>
 <CAEESW=XfT_gC-0v=u8VBUFhdjquTPV12wdXbCmxUivADKsJL=Q@mail.gmail.com>
 <3551c08f9295a2de184cf65aed7bfc2e.squirrel@mail.braverock.com>
 <CAEESW=Xwu6p_iqJv2MXDHdvCfazhg5QQfq7WgxCDomgqraf-6A@mail.gmail.com>
 <10efc192b1dc3545c70b6e36e2cf7795.squirrel@mail.braverock.com>
Message-ID: <9610cf93b7436cc8afa3bf170d601065.squirrel@mail.braverock.com>

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>

From rossbennett34 at gmail.com  Wed Oct  2 19:50:52 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Wed, 2 Oct 2013 12:50:52 -0500
Subject: [GSoC-PortA] Visualize eq risk contrib portf
In-Reply-To: <9610cf93b7436cc8afa3bf170d601065.squirrel@mail.braverock.com>
References: <2c24f9bd6659bf416d8e8d995b10a6dc.squirrel@mail.braverock.com>
 <02f235525a54cb5e17d11b037f1b4fd6.squirrel@mail.braverock.com>
 <CAEESW=XfT_gC-0v=u8VBUFhdjquTPV12wdXbCmxUivADKsJL=Q@mail.gmail.com>
 <3551c08f9295a2de184cf65aed7bfc2e.squirrel@mail.braverock.com>
 <CAEESW=Xwu6p_iqJv2MXDHdvCfazhg5QQfq7WgxCDomgqraf-6A@mail.gmail.com>
 <10efc192b1dc3545c70b6e36e2cf7795.squirrel@mail.braverock.com>
 <9610cf93b7436cc8afa3bf170d601065.squirrel@mail.braverock.com>
Message-ID: <CAEESW=WAMxZv9vvsZ=zqsFz-PBGfonofJCbVPeo5qwwAhj9_Og@mail.gmail.com>

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>

From peter at braverock.com  Wed Oct  2 20:18:48 2013
From: peter at braverock.com (Peter Carl)
Date: Wed, 2 Oct 2013 13:18:48 -0500
Subject: [GSoC-PortA] Visualize eq risk contrib portf
In-Reply-To: <CAEESW=WAMxZv9vvsZ=zqsFz-PBGfonofJCbVPeo5qwwAhj9_Og@mail.gmail.com>
References: <2c24f9bd6659bf416d8e8d995b10a6dc.squirrel@mail.braverock.com>
 <02f235525a54cb5e17d11b037f1b4fd6.squirrel@mail.braverock.com>
 <CAEESW=XfT_gC-0v=u8VBUFhdjquTPV12wdXbCmxUivADKsJL=Q@mail.gmail.com>
 <3551c08f9295a2de184cf65aed7bfc2e.squirrel@mail.braverock.com>
 <CAEESW=Xwu6p_iqJv2MXDHdvCfazhg5QQfq7WgxCDomgqraf-6A@mail.gmail.com>
 <10efc192b1dc3545c70b6e36e2cf7795.squirrel@mail.braverock.com>
 <9610cf93b7436cc8afa3bf170d601065.squirrel@mail.braverock.com>
 <CAEESW=WAMxZv9vvsZ=zqsFz-PBGfonofJCbVPeo5qwwAhj9_Og@mail.gmail.com>
Message-ID: <8fd535d6c9a1e2f03387586d98e61156.squirrel@mail.braverock.com>

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>

From peter at braverock.com  Fri Oct  4 20:49:27 2013
From: peter at braverock.com (Peter Carl)
Date: Fri, 4 Oct 2013 13:49:27 -0500
Subject: [GSoC-PortA] Mean-mETL objective?
Message-ID: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>

Hey Ross,

I can't seem to get the Mean-mETL objective to select anything other than
the Min mETL portfolio using ROI.  It looks like there should be good
convexity, but I think there's a substantial imbalance between the size of
the monthly mean return and the loss indicated by the ETL.  I've tried
modifying the multiplier on the mean, but it doesn't seem to have an
effect.

Any thoughts?

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




From rossbennett34 at gmail.com  Fri Oct  4 21:42:37 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Fri, 4 Oct 2013 12:42:37 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
Message-ID: <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>

Peter,

Unfortunately, with ROI we are only able to minimize ETL with ETL as an
objective. If you have mean and ETL as an objective using ROI, unless there
is a target in the mean return objective, we just minimize ETL. If you have
both mean and ETL as objectives, you could add a target to the mean
objective and this will minimize ETL subject to the target return.

We can do the following with ETL as an objective using ROI:
 - Minimize ETL subject to leverage, box, group, exposure, position limit,
and target return.

Multipliers are ignored with ROI since the problems are formulated into an
LP/QP problem. I'll take a look at the documentation in optimize.portfolio
and make sure this is clear.

I hope that helps clear it up.

Ross


On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com> wrote:

> Hey Ross,
>
> I can't seem to get the Mean-mETL objective to select anything other than
> the Min mETL portfolio using ROI.  It looks like there should be good
> convexity, but I think there's a substantial imbalance between the size of
> the monthly mean return and the loss indicated by the ETL.  I've tried
> modifying the multiplier on the mean, but it doesn't seem to have an
> effect.
>
> Any thoughts?
>
> pcc
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131004/7982f172/attachment.html>

From brian at braverock.com  Fri Oct  4 21:58:32 2013
From: brian at braverock.com (Brian G. Peterson)
Date: Fri, 04 Oct 2013 14:58:32 -0500
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
Message-ID: <524F1DE8.9030301@braverock.com>

If it is an LP problem, I think you can only minimize subject to 
constraints.

If it is a QP problem, can't you do the mean/ETL portfolio?

That assumes the space is convex, which it will be for Gaussian ETL, and 
may not be for modified Cornish Fisher ETL, but will be most of the 
time, at most reasonable confidence levels.

Brian

On 10/04/2013 02:42 PM, Ross Bennett wrote:
> Peter,
>
> Unfortunately, with ROI we are only able to minimize ETL with ETL as an
> objective. If you have mean and ETL as an objective using ROI, unless
> there is a target in the mean return objective, we just minimize ETL. If
> you have both mean and ETL as objectives, you could add a target to the
> mean objective and this will minimize ETL subject to the target return.
>
> We can do the following with ETL as an objective using ROI:
>   - Minimize ETL subject to leverage, box, group, exposure, position
> limit, and target return.
>
> Multipliers are ignored with ROI since the problems are formulated into
> an LP/QP problem. I'll take a look at the documentation in
> optimize.portfolio and make sure this is clear.
>
> I hope that helps clear it up.
>
> Ross
>
>
> On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com
> <mailto:peter at braverock.com>> wrote:
>
>     Hey Ross,
>
>     I can't seem to get the Mean-mETL objective to select anything other
>     than
>     the Min mETL portfolio using ROI.  It looks like there should be good
>     convexity, but I think there's a substantial imbalance between the
>     size of
>     the monthly mean return and the loss indicated by the ETL.  I've tried
>     modifying the multiplier on the mean, but it doesn't seem to have an
>     effect.
>
>     Any thoughts?
>
>     pcc

From rossbennett34 at gmail.com  Fri Oct  4 22:54:50 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Fri, 4 Oct 2013 13:54:50 -0700
Subject: [GSoC-PortA] Some feedback...
In-Reply-To: <30c9e004e0cf5f5dfda0cd17ef50ea01.squirrel@mail.braverock.com>
References: <6077558330b1a022003470c2092bae1b.squirrel@mail.braverock.com>
 <CAEESW=Vnm=gdrW-ZrNcs75PDMHjKQnoWjcQbbCXNvPtKyag6=A@mail.gmail.com>
 <d8bde6de6669c505e939538fbec8aeca.squirrel@mail.braverock.com>
 <CAEESW=XycK5GeBUvwdttkmwxtgcLvcLPTvjdjgurd5S9tpaLMA@mail.gmail.com>
 <30c9e004e0cf5f5dfda0cd17ef50ea01.squirrel@mail.braverock.com>
Message-ID: <CAEESW=W6Nw=xhcxEtq42Yut=GzUHtrVJsASVyxe6DJ1kjigzCQ@mail.gmail.com>

I think I have a good first step in combining objective measures for all
portfolios in an opt.list object. My apologies in advance for the long
email, but I wanted to put this out there as this could be a pretty unique
feature in PortfolioAnalytics.

Here is an outline of what I am doing.

Step 1: Get the objectives from the portfolio$objectives slot from each
optimize.portfolio object in the opt.list object and combine into a single
list of objectives. I am careful with how I construct the list so that
risk_budget objectives are added last.

Step 2: Detect and remove duplicates by objective name and type. The last
objective is the one that is kept. This is the comprehensive objectives
list of all objectives from each optimize.portfolio object in opt.list.

Step 3: Insert the comprehensive objectives list into the
portfolio$objectives slot in each optimize.portfolio object in the opt.list
object. Then call constrained_objective given the returns, weights, and
portfolio of each optimize.portfolio object. This allows the use of
different returns, assets, and constraints, but calculates the same
objectives.

The drawbacks of this approach is that the objective_measures are
recalculated and handling multiple arguments with different values is
tricky.

For example, say we combine two optimize.portfolio objects and both have ES
as the only objective. The first object uses arguments=list(p=0.95,
clean="boudt") and the second object uses arguments=list(p=0.90,
clean="none") for the ES objective. The steps described above will use
p=0.90 and clean="none" to calculate the objective_measure.

One solution I thought of was to add a ... argument to
extractObjectiveMeasures() so the user can pass in arguments, otherwise
default to the steps described above.

This is obviously a simple case where the previous way of extracting the
objective_measures from multiple optimize.portfolio objects worked better,
but that way only worked if all portfolio objects had the exact same
objectives and types.

Typing this I just realized I should probably do the following:
if( all objectives are identical) {
  extract objective_measures the previous way
} else {
  extract objective_measures using steps above
}

Any comments or suggestions?

Thanks,
Ross


On Tue, Sep 24, 2013 at 4:00 AM, Peter Carl <peter at braverock.com> wrote:

> Now that I think about it a bit more, I think that returns and assets CAN
> differ, as long as the measures are calculable at the portfolio level.
> I'm not sure which of the processes you outlined below are preferable, but
> they are definitely in the right direction.
>
> pcc
> --
> Peter Carl
> http://www.braverock.com/peter
>
> > On Mon, Sep 23, 2013 at 1:19 PM, Peter Carl <peter at braverock.com> wrote:
> >
> >> Here's your comment from below:
> >>
> >> "It is tough to tell with the formatting on the email, but I'll take a
> >> closer look at the script in the sandbox to see if I can tell what is
> >> going on. The idea is that extractObjectiveMeasures will return a matrix
> >> of the objective measures for all optimize.portfolio objects in the
> >> opt.list object. For example, the meanSD row should have NAs under the
> >> ETL
> >> and ETL component contribution columns. I am only stitching together the
> >> objective measures, I do not re-calculate StdDev or component StdDev for
> >> the portfolios with ETL as an objective. Basically, I just take whatever
> >> objectives are in the $objective_measures slot of each
> >> optimize.portfolio
> >> object. Should I be doing something such that all cells in the matrix
> >> have
> >> values? "
> >>
> >> I think so, although I doubt this has been well spelled out before.  The
> >> question is: can we anticipate how to fill in these values given the
> >> information in each object?
> >>
> >
> > I think we might be able to depending on how the objective measures are
> > calculated on the weights.
> >
> > One way would be to pick out the objective names, match the name to the
> > function, and then calculate the objectives on the weights. The
> parameters
> > could be pulled from the $arguments list in each objective. This might be
> > tricky if there are multiple arguments with different arguments. This is
> > likely the simplest solution. If "ES" is an objective name, we could by
> > default calculate it with portfolio_method="component" since the
> > univariate
> > ES also calculated.
> >
> > Another way is to combine all the objectives from each object, try to
> > detect and remove duplicate objectives objects, then pass that portfolio
> > object to constrained_objective to calculate over the weights.
> >
> > Not sure which way is better, I'll have to give this some thought and try
> > out a few things.
> >
> >
> >>
> >> When I do this by hand, I'm just calculating for the list of optimal
> >> weights of each objective for each measure.  At that point, I can make
> >> comparisons I couldn't otherwise.
> >>
> >> Note that the objectives can be vastly different, as long as the assets
> >> are the same and the parameters for each of the metrics are the same.
> >>
> >
> > I could add a check to make sure that the assets and returns are the same
> > in each optimize.portfolio object. I think this will only work if that is
> > the case. It would be nice to have the flexibility to have different
> > assets
> > and returns, but that may not be doable.
> >
> >
> >>
> >> Does that make sense?
> >>
> >
> > It does make sense, thanks for the feedback.
> >
> >
> >>
> >> pcc
> >> --
> >> Peter Carl
> >> http://www.braverock.com/peter
> >>
> >> > Peter,
> >> >
> >> > Thanks for the feedback, I really appreciate it.
> >> >
> >> > see comments in line.
> >> >
> >> >
> >> > On Sun, Sep 22, 2013 at 4:41 PM, Peter Carl <peter at braverock.com>
> >> wrote:
> >> >
> >> >> Ross,
> >> >>
> >> >> I've been working through your vignette to hopefully give you some
> >> more
> >> >> detailed feedback, including on your questions from a few days ago.
> >> >> Sorry
> >> >> this has taken so long, but I wanted to spend some focused time on
> >> the
> >> >> package.
> >> >>
> >> >> I realize that you've got different plot methods for each type, and I
> >> >> appreciate what a hassle it is to keep such methods relatively
> >> >> consistent.
> >> >>  In chart.RiskReturn.DE, when the function doesn't find anything
> that
> >> >> fits
> >> >> its defaults:
> >> >> > plot(RiskBudget.DE)
> >> >> Error in plot.window(...) : need finite 'xlim' values
> >> >> In addition: Warning messages:
> >> >> 1: In chart.Scatter.DE(object = DE, risk.col = risk.col, return.col
> =
> >> >> return.col,  :
> >> >>   mean or ES do  not match extractStats output of $objective_measures
> >> >> slot
> >> >> 2: In min(x) : no non-missing arguments to min; returning Inf
> >> >> 3: In max(x) : no non-missing arguments to max; returning -Inf
> >> >>
> >> >> It's a risk budget on ETL, so if I tell it that, it works:
> >> >> > plot(RiskBudget.DE, risk.col="ETL", return.col="mean")
> >> >>
> >> >
> >> > The default is risk.col="ES". Because your objective name is "ETL",
> >> you
> >> > need to explicitly do risk.col="ETL".
> >> >
> >> >
> >> >>
> >> >> ...but it doesn't recover well when I try to plot the results in
> >> >> variance
> >> >> space:
> >> >> > plot(RiskBudget.DE, risk.col="StdDev", return.col="mean")
> >> >> Error in plot.window(...) : need finite 'xlim' values
> >> >> In addition: Warning messages:
> >> >> 1: In chart.Scatter.DE(object = DE, risk.col = risk.col, return.col
> =
> >> >> return.col,  :
> >> >>   mean or StdDev do  not match extractStats output of
> >> >> $objective_measures
> >> >> slot
> >> >> 2: In min(x) : no non-missing arguments to min; returning Inf
> >> >> 3: In max(x) : no non-missing arguments to max; returning -Inf
> >> >>
> >> >>
> >> >> I'm not exactly sure what the issue is here, but maybe it's related:
> >> >> > chart.RiskBudget(RiskBudget.DE, risk.type="percentage",
> >> neighbors=5)
> >> >> Error in subsetx[i, riskcols] : incorrect number of dimensions
> >> >> > traceback()
> >> >> 3: points(subsetx[i, riskcols], type = "b", col = "lightblue")
> >> >> 2: chart.RiskBudget.optimize.portfolio(RiskBudget.DE, risk.type =
> >> >> "percentage",
> >> >>        neighbors = 5)
> >> >> 1: chart.RiskBudget(RiskBudget.DE, risk.type = "percentage",
> >> neighbors =
> >> >> 5)
> >> >>
> >> >
> >> > Not sure either what the issue is, but I'll take a look.
> >> >
> >> >
> >> >> In chart.RiskReturnScatter.RP, it looks like 'rp' is being passed
> >> into
> >> >> plot through dots.
> >> >> > plot(EqmETL.RND, risk.col="StdDev", return.col="mean", rp=1000,
> >> >> chart.assets=TRUE)
> >> >> There were 13 warnings (use warnings() to see them)
> >> >> > warnings()
> >> >> Warning messages:
> >> >> 1: "rp" is not a graphical parameter
> >> >> 2: "rp" is not a graphical parameter
> >> >> 3: "rp" is not a graphical parameter
> >> >>
> >> >
> >> > The 'rp' argument is meant for optimize.portfolio.ROI and
> >> > optimize.portfolio.GenSA objects. Since ROI and GenSA do not return
> >> trace
> >> > information like DEoptim or random portfolios, I added this as an
> >> option
> >> > to
> >> > generate random portfolios to plot the feasible space. If you are
> >> already
> >> > passing in an optimize.portfolio.random object, there is no need to
> >> pass
> >> > in
> >> > rp as an argument.
> >> >
> >> >
> >> >>
> >> >>
> >> >> > extractWeights(buoys)
> >> >>          Convertible Arbitrage Equity Market Neutral Fixed Income
> >> >> Arbitrage Event Driven CTA Global Global Macro Long/Short Equity
> >> >> MeanSD              0.05000000                 0.050
> >> >> 0.050   0.30000000  0.0500000    0.2000000             0.300
> >> >> MeanmETL            0.05000000                 0.300
> >> >> 0.050   0.05000000  0.2000000    0.3000000             0.050
> >> >> MinSD               0.06042904                 0.300
> >> >> 0.300   0.05234676  0.1735858    0.0636384             0.050
> >> >> MinmETL             0.05000000                 0.300
> >> >> 0.050   0.05000000  0.2000000    0.3000000             0.050
> >> >> EqSD                0.12500000                 0.240
> >> >> 0.200   0.08500000  0.1050000    0.1700000             0.075
> >> >> EqmETL              0.06000000                 0.265
> >> >> 0.165   0.09000000  0.2050000    0.1300000             0.080
> >> >> RB                  0.05200000                 0.410
> >> >> 0.060   0.05200000  0.1438995    0.2220000             0.058
> >> >>
> >> >> ...but this doesn't:
> >> >> > extractObjectiveMeasures(buoys)
> >> >>                 mean     StdDev         ES StdDev.contribution1
> >> >> StdDev.contribution2 StdDev.contribution3
> >> >> StdDev.contribution4
> >> >> MeanSD   0.006782814 0.01546759         NA                   NA
> >> >>        NA                   NA                   NA
> >> >> MeanmETL 0.005897789         NA 0.01505626                   NA
> >> >>        NA                   NA                   NA
> >> >> MinSD             NA 0.01009001         NA                   NA
> >> >>        NA                   NA                   NA
> >> >> MinmETL           NA         NA 0.01505626                   NA
> >> >>        NA                   NA                   NA
> >> >> EqSD              NA 0.01113716         NA          0.001763096
> >> >> 0.001565752          0.001886988          0.001258567
> >> >> EqmETL            NA         NA 0.01646509                   NA
> >> >>        NA                   NA                   NA
> >> >> RB       0.005812997         NA         NA                   NA
> >> >>        NA                   NA                   NA
> >> >>          StdDev.contribution5 StdDev.contribution6
> >> StdDev.contribution7
> >> >> StdDev.pct_contrib_StdDev1 StdDev.pct_contrib_StdDev2
> >> >> MeanSD                     NA                   NA
> >> NA
> >> >>                      NA                         NA
> >> >> MeanmETL                   NA                   NA
> >> NA
> >> >>                      NA                         NA
> >> >> MinSD                      NA                   NA
> >> NA
> >> >>                      NA                         NA
> >> >> MinmETL                    NA                   NA
> >> NA
> >> >>                      NA                         NA
> >> >> EqSD              0.001039908          0.002296903
> >> 0.001325947
> >> >>               0.1583075                  0.1405881
> >> >> EqmETL                     NA                   NA
> >> NA
> >> >>                      NA                         NA
> >> >> RB                         NA                   NA
> >> NA
> >> >>                      NA                         NA
> >> >> ...snip...
> >> >>
> >> >>
> >> > It is tough to tell with the formatting on the email, but I'll take a
> >> > closer look at the script in the sandbox to see if I can tell what is
> >> > going
> >> > on. The idea is that extractObjectiveMeasures will return a matrix of
> >> the
> >> > objective measures for all optimize.portfolio objects in the opt.list
> >> > object. For example, the meanSD row should have NAs under the ETL and
> >> ETL
> >> > component contribution columns. I am only stitching together the
> >> objective
> >> > measures, I do not re-calculate StdDev or component StdDev for the
> >> > portfolios with ETL as an objective. Basically, I just take whatever
> >> > objectives are in the $objective_measures slot of each
> >> optimize.portfolio
> >> > object. Should I be doing something such that all cells in the matrix
> >> have
> >> > values?
> >> >
> >> >
> >> >> As a consequence, only one portfolio appears in the following plot
> >> >> (MeanSD):
> >> >> > chart.RiskReward(buoys)
> >> >>
> >> >
> >> > This relates to my comment above about how I am not recalculating
> >> > anything.
> >> > Before the portfolios are plotted in risk-return space, I omit rows
> >> that
> >> > have NA values. For example, if you wanted to plot all the portfolios
> >> in
> >> > mean-ETL space, all portfolios should have mean and ETL as an
> >> objective.
> >> > You could set the multiplier to 0 so it does not affect the
> >> optimization,
> >> > but is returned in the $objective_measures slot.
> >> >
> >> >
> >> >>
> >> >> All in all, this is all looking good.  I've got some scripts checked
> >> in
> >> >> under sandbox/symposium2013 if you want to follow along.
> >> >>
> >> >
> >> > I'll take a closer look and follow along, thanks!
> >> >
> >> >
> >> >>
> >> >> pcc
> >> >> --
> >> >> 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/20131004/c3318846/attachment-0001.html>

From peter at braverock.com  Fri Oct  4 23:16:29 2013
From: peter at braverock.com (Peter Carl)
Date: Fri, 4 Oct 2013 16:16:29 -0500
Subject: [GSoC-PortA] Some feedback...
In-Reply-To: <CAEESW=W6Nw=xhcxEtq42Yut=GzUHtrVJsASVyxe6DJ1kjigzCQ@mail.gmail.com>
References: <6077558330b1a022003470c2092bae1b.squirrel@mail.braverock.com>
 <CAEESW=Vnm=gdrW-ZrNcs75PDMHjKQnoWjcQbbCXNvPtKyag6=A@mail.gmail.com>
 <d8bde6de6669c505e939538fbec8aeca.squirrel@mail.braverock.com>
 <CAEESW=XycK5GeBUvwdttkmwxtgcLvcLPTvjdjgurd5S9tpaLMA@mail.gmail.com>
 <30c9e004e0cf5f5dfda0cd17ef50ea01.squirrel@mail.braverock.com>
 <CAEESW=W6Nw=xhcxEtq42Yut=GzUHtrVJsASVyxe6DJ1kjigzCQ@mail.gmail.com>
Message-ID: <15810dff5f04b4854d75c32ab4dd5213.squirrel@mail.braverock.com>

At first glance, that all sounds correct to me (or at least eerily similar
to what I've been doing by hand this week.)  I agree - this is unique. 
Let me know what I can test for you...

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

> I think I have a good first step in combining objective measures for all
> portfolios in an opt.list object. My apologies in advance for the long
> email, but I wanted to put this out there as this could be a pretty unique
> feature in PortfolioAnalytics.
>
> Here is an outline of what I am doing.
>
> Step 1: Get the objectives from the portfolio$objectives slot from each
> optimize.portfolio object in the opt.list object and combine into a single
> list of objectives. I am careful with how I construct the list so that
> risk_budget objectives are added last.
>
> Step 2: Detect and remove duplicates by objective name and type. The last
> objective is the one that is kept. This is the comprehensive objectives
> list of all objectives from each optimize.portfolio object in opt.list.
>
> Step 3: Insert the comprehensive objectives list into the
> portfolio$objectives slot in each optimize.portfolio object in the
> opt.list
> object. Then call constrained_objective given the returns, weights, and
> portfolio of each optimize.portfolio object. This allows the use of
> different returns, assets, and constraints, but calculates the same
> objectives.
>
> The drawbacks of this approach is that the objective_measures are
> recalculated and handling multiple arguments with different values is
> tricky.
>
> For example, say we combine two optimize.portfolio objects and both have
> ES
> as the only objective. The first object uses arguments=list(p=0.95,
> clean="boudt") and the second object uses arguments=list(p=0.90,
> clean="none") for the ES objective. The steps described above will use
> p=0.90 and clean="none" to calculate the objective_measure.
>
> One solution I thought of was to add a ... argument to
> extractObjectiveMeasures() so the user can pass in arguments, otherwise
> default to the steps described above.
>
> This is obviously a simple case where the previous way of extracting the
> objective_measures from multiple optimize.portfolio objects worked better,
> but that way only worked if all portfolio objects had the exact same
> objectives and types.
>
> Typing this I just realized I should probably do the following:
> if( all objectives are identical) {
>   extract objective_measures the previous way
> } else {
>   extract objective_measures using steps above
> }
>
> Any comments or suggestions?
>
> Thanks,
> Ross
>
>
> On Tue, Sep 24, 2013 at 4:00 AM, Peter Carl <peter at braverock.com> wrote:
>
>> Now that I think about it a bit more, I think that returns and assets
>> CAN
>> differ, as long as the measures are calculable at the portfolio level.
>> I'm not sure which of the processes you outlined below are preferable,
>> but
>> they are definitely in the right direction.
>>
>> pcc
>> --
>> Peter Carl
>> http://www.braverock.com/peter
>>
>> > On Mon, Sep 23, 2013 at 1:19 PM, Peter Carl <peter at braverock.com>
>> wrote:
>> >
>> >> Here's your comment from below:
>> >>
>> >> "It is tough to tell with the formatting on the email, but I'll take
>> a
>> >> closer look at the script in the sandbox to see if I can tell what is
>> >> going on. The idea is that extractObjectiveMeasures will return a
>> matrix
>> >> of the objective measures for all optimize.portfolio objects in the
>> >> opt.list object. For example, the meanSD row should have NAs under
>> the
>> >> ETL
>> >> and ETL component contribution columns. I am only stitching together
>> the
>> >> objective measures, I do not re-calculate StdDev or component StdDev
>> for
>> >> the portfolios with ETL as an objective. Basically, I just take
>> whatever
>> >> objectives are in the $objective_measures slot of each
>> >> optimize.portfolio
>> >> object. Should I be doing something such that all cells in the matrix
>> >> have
>> >> values? "
>> >>
>> >> I think so, although I doubt this has been well spelled out before.
>> The
>> >> question is: can we anticipate how to fill in these values given the
>> >> information in each object?
>> >>
>> >
>> > I think we might be able to depending on how the objective measures
>> are
>> > calculated on the weights.
>> >
>> > One way would be to pick out the objective names, match the name to
>> the
>> > function, and then calculate the objectives on the weights. The
>> parameters
>> > could be pulled from the $arguments list in each objective. This might
>> be
>> > tricky if there are multiple arguments with different arguments. This
>> is
>> > likely the simplest solution. If "ES" is an objective name, we could
>> by
>> > default calculate it with portfolio_method="component" since the
>> > univariate
>> > ES also calculated.
>> >
>> > Another way is to combine all the objectives from each object, try to
>> > detect and remove duplicate objectives objects, then pass that
>> portfolio
>> > object to constrained_objective to calculate over the weights.
>> >
>> > Not sure which way is better, I'll have to give this some thought and
>> try
>> > out a few things.
>> >
>> >
>> >>
>> >> When I do this by hand, I'm just calculating for the list of optimal
>> >> weights of each objective for each measure.  At that point, I can
>> make
>> >> comparisons I couldn't otherwise.
>> >>
>> >> Note that the objectives can be vastly different, as long as the
>> assets
>> >> are the same and the parameters for each of the metrics are the same.
>> >>
>> >
>> > I could add a check to make sure that the assets and returns are the
>> same
>> > in each optimize.portfolio object. I think this will only work if that
>> is
>> > the case. It would be nice to have the flexibility to have different
>> > assets
>> > and returns, but that may not be doable.
>> >
>> >
>> >>
>> >> Does that make sense?
>> >>
>> >
>> > It does make sense, thanks for the feedback.
>> >
>> >
>> >>
>> >> pcc
>> >> --
>> >> Peter Carl
>> >> http://www.braverock.com/peter
>> >>
>> >> > Peter,
>> >> >
>> >> > Thanks for the feedback, I really appreciate it.
>> >> >
>> >> > see comments in line.
>> >> >
>> >> >
>> >> > On Sun, Sep 22, 2013 at 4:41 PM, Peter Carl <peter at braverock.com>
>> >> wrote:
>> >> >
>> >> >> Ross,
>> >> >>
>> >> >> I've been working through your vignette to hopefully give you some
>> >> more
>> >> >> detailed feedback, including on your questions from a few days
>> ago.
>> >> >> Sorry
>> >> >> this has taken so long, but I wanted to spend some focused time on
>> >> the
>> >> >> package.
>> >> >>
>> >> >> I realize that you've got different plot methods for each type,
>> and I
>> >> >> appreciate what a hassle it is to keep such methods relatively
>> >> >> consistent.
>> >> >>  In chart.RiskReturn.DE, when the function doesn't find anything
>> that
>> >> >> fits
>> >> >> its defaults:
>> >> >> > plot(RiskBudget.DE)
>> >> >> Error in plot.window(...) : need finite 'xlim' values
>> >> >> In addition: Warning messages:
>> >> >> 1: In chart.Scatter.DE(object = DE, risk.col = risk.col,
>> return.col
>> =
>> >> >> return.col,  :
>> >> >>   mean or ES do  not match extractStats output of
>> $objective_measures
>> >> >> slot
>> >> >> 2: In min(x) : no non-missing arguments to min; returning Inf
>> >> >> 3: In max(x) : no non-missing arguments to max; returning -Inf
>> >> >>
>> >> >> It's a risk budget on ETL, so if I tell it that, it works:
>> >> >> > plot(RiskBudget.DE, risk.col="ETL", return.col="mean")
>> >> >>
>> >> >
>> >> > The default is risk.col="ES". Because your objective name is "ETL",
>> >> you
>> >> > need to explicitly do risk.col="ETL".
>> >> >
>> >> >
>> >> >>
>> >> >> ...but it doesn't recover well when I try to plot the results in
>> >> >> variance
>> >> >> space:
>> >> >> > plot(RiskBudget.DE, risk.col="StdDev", return.col="mean")
>> >> >> Error in plot.window(...) : need finite 'xlim' values
>> >> >> In addition: Warning messages:
>> >> >> 1: In chart.Scatter.DE(object = DE, risk.col = risk.col,
>> return.col
>> =
>> >> >> return.col,  :
>> >> >>   mean or StdDev do  not match extractStats output of
>> >> >> $objective_measures
>> >> >> slot
>> >> >> 2: In min(x) : no non-missing arguments to min; returning Inf
>> >> >> 3: In max(x) : no non-missing arguments to max; returning -Inf
>> >> >>
>> >> >>
>> >> >> I'm not exactly sure what the issue is here, but maybe it's
>> related:
>> >> >> > chart.RiskBudget(RiskBudget.DE, risk.type="percentage",
>> >> neighbors=5)
>> >> >> Error in subsetx[i, riskcols] : incorrect number of dimensions
>> >> >> > traceback()
>> >> >> 3: points(subsetx[i, riskcols], type = "b", col = "lightblue")
>> >> >> 2: chart.RiskBudget.optimize.portfolio(RiskBudget.DE, risk.type =
>> >> >> "percentage",
>> >> >>        neighbors = 5)
>> >> >> 1: chart.RiskBudget(RiskBudget.DE, risk.type = "percentage",
>> >> neighbors =
>> >> >> 5)
>> >> >>
>> >> >
>> >> > Not sure either what the issue is, but I'll take a look.
>> >> >
>> >> >
>> >> >> In chart.RiskReturnScatter.RP, it looks like 'rp' is being passed
>> >> into
>> >> >> plot through dots.
>> >> >> > plot(EqmETL.RND, risk.col="StdDev", return.col="mean", rp=1000,
>> >> >> chart.assets=TRUE)
>> >> >> There were 13 warnings (use warnings() to see them)
>> >> >> > warnings()
>> >> >> Warning messages:
>> >> >> 1: "rp" is not a graphical parameter
>> >> >> 2: "rp" is not a graphical parameter
>> >> >> 3: "rp" is not a graphical parameter
>> >> >>
>> >> >
>> >> > The 'rp' argument is meant for optimize.portfolio.ROI and
>> >> > optimize.portfolio.GenSA objects. Since ROI and GenSA do not return
>> >> trace
>> >> > information like DEoptim or random portfolios, I added this as an
>> >> option
>> >> > to
>> >> > generate random portfolios to plot the feasible space. If you are
>> >> already
>> >> > passing in an optimize.portfolio.random object, there is no need to
>> >> pass
>> >> > in
>> >> > rp as an argument.
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> > extractWeights(buoys)
>> >> >>          Convertible Arbitrage Equity Market Neutral Fixed Income
>> >> >> Arbitrage Event Driven CTA Global Global Macro Long/Short Equity
>> >> >> MeanSD              0.05000000                 0.050
>> >> >> 0.050   0.30000000  0.0500000    0.2000000             0.300
>> >> >> MeanmETL            0.05000000                 0.300
>> >> >> 0.050   0.05000000  0.2000000    0.3000000             0.050
>> >> >> MinSD               0.06042904                 0.300
>> >> >> 0.300   0.05234676  0.1735858    0.0636384             0.050
>> >> >> MinmETL             0.05000000                 0.300
>> >> >> 0.050   0.05000000  0.2000000    0.3000000             0.050
>> >> >> EqSD                0.12500000                 0.240
>> >> >> 0.200   0.08500000  0.1050000    0.1700000             0.075
>> >> >> EqmETL              0.06000000                 0.265
>> >> >> 0.165   0.09000000  0.2050000    0.1300000             0.080
>> >> >> RB                  0.05200000                 0.410
>> >> >> 0.060   0.05200000  0.1438995    0.2220000             0.058
>> >> >>
>> >> >> ...but this doesn't:
>> >> >> > extractObjectiveMeasures(buoys)
>> >> >>                 mean     StdDev         ES StdDev.contribution1
>> >> >> StdDev.contribution2 StdDev.contribution3
>> >> >> StdDev.contribution4
>> >> >> MeanSD   0.006782814 0.01546759         NA                   NA
>> >> >>        NA                   NA                   NA
>> >> >> MeanmETL 0.005897789         NA 0.01505626                   NA
>> >> >>        NA                   NA                   NA
>> >> >> MinSD             NA 0.01009001         NA                   NA
>> >> >>        NA                   NA                   NA
>> >> >> MinmETL           NA         NA 0.01505626                   NA
>> >> >>        NA                   NA                   NA
>> >> >> EqSD              NA 0.01113716         NA          0.001763096
>> >> >> 0.001565752          0.001886988          0.001258567
>> >> >> EqmETL            NA         NA 0.01646509                   NA
>> >> >>        NA                   NA                   NA
>> >> >> RB       0.005812997         NA         NA                   NA
>> >> >>        NA                   NA                   NA
>> >> >>          StdDev.contribution5 StdDev.contribution6
>> >> StdDev.contribution7
>> >> >> StdDev.pct_contrib_StdDev1 StdDev.pct_contrib_StdDev2
>> >> >> MeanSD                     NA                   NA
>> >> NA
>> >> >>                      NA                         NA
>> >> >> MeanmETL                   NA                   NA
>> >> NA
>> >> >>                      NA                         NA
>> >> >> MinSD                      NA                   NA
>> >> NA
>> >> >>                      NA                         NA
>> >> >> MinmETL                    NA                   NA
>> >> NA
>> >> >>                      NA                         NA
>> >> >> EqSD              0.001039908          0.002296903
>> >> 0.001325947
>> >> >>               0.1583075                  0.1405881
>> >> >> EqmETL                     NA                   NA
>> >> NA
>> >> >>                      NA                         NA
>> >> >> RB                         NA                   NA
>> >> NA
>> >> >>                      NA                         NA
>> >> >> ...snip...
>> >> >>
>> >> >>
>> >> > It is tough to tell with the formatting on the email, but I'll take
>> a
>> >> > closer look at the script in the sandbox to see if I can tell what
>> is
>> >> > going
>> >> > on. The idea is that extractObjectiveMeasures will return a matrix
>> of
>> >> the
>> >> > objective measures for all optimize.portfolio objects in the
>> opt.list
>> >> > object. For example, the meanSD row should have NAs under the ETL
>> and
>> >> ETL
>> >> > component contribution columns. I am only stitching together the
>> >> objective
>> >> > measures, I do not re-calculate StdDev or component StdDev for the
>> >> > portfolios with ETL as an objective. Basically, I just take
>> whatever
>> >> > objectives are in the $objective_measures slot of each
>> >> optimize.portfolio
>> >> > object. Should I be doing something such that all cells in the
>> matrix
>> >> have
>> >> > values?
>> >> >
>> >> >
>> >> >> As a consequence, only one portfolio appears in the following plot
>> >> >> (MeanSD):
>> >> >> > chart.RiskReward(buoys)
>> >> >>
>> >> >
>> >> > This relates to my comment above about how I am not recalculating
>> >> > anything.
>> >> > Before the portfolios are plotted in risk-return space, I omit rows
>> >> that
>> >> > have NA values. For example, if you wanted to plot all the
>> portfolios
>> >> in
>> >> > mean-ETL space, all portfolios should have mean and ETL as an
>> >> objective.
>> >> > You could set the multiplier to 0 so it does not affect the
>> >> optimization,
>> >> > but is returned in the $objective_measures slot.
>> >> >
>> >> >
>> >> >>
>> >> >> All in all, this is all looking good.  I've got some scripts
>> checked
>> >> in
>> >> >> under sandbox/symposium2013 if you want to follow along.
>> >> >>
>> >> >
>> >> > I'll take a closer look and follow along, thanks!
>> >> >
>> >> >
>> >> >>
>> >> >> pcc
>> >> >> --
>> >> >> 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
>



From martinrd at comcast.net  Sat Oct  5 17:10:22 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sat, 5 Oct 2013 08:10:22 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
Message-ID: <002701cec1dd$041b1520$0c513f60$@comcast.net>

Peter,

 

While you have convexity with ETL, that would not hold with mETL due to
presence of skewness and kurtosis of portfolio returns that depend upon the
weights.  I'll have a look at the rest of this thread.

 

Doug

 

 

-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Peter
Carl
Sent: Friday, October 04, 2013 11:49 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: [GSoC-PortA] Mean-mETL objective?

 

Hey Ross,

 

I can't seem to get the Mean-mETL objective to select anything other than
the Min mETL portfolio using ROI.  It looks like there should be good
convexity, but I think there's a substantial imbalance between the size of
the monthly mean return and the loss indicated by the ETL.  I've tried
modifying the multiplier on the mean, but it doesn't seem to have an effect.

 

Any thoughts?

 

pcc

--

Peter Carl

 <http://www.braverock.com/peter> http://www.braverock.com/peter

 

 

 

_______________________________________________

GSoC-PortA mailing list

 <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

 <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
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/20131005/981c2b21/attachment.html>

From martinrd at comcast.net  Sat Oct  5 17:10:22 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sat, 5 Oct 2013 08:10:22 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
Message-ID: <002701cec1dd$041b1520$0c513f60$@comcast.net>

Peter,

 

While you have convexity with ETL, that would not hold with mETL due to
presence of skewness and kurtosis of portfolio returns that depend upon the
weights.  I'll have a look at the rest of this thread.

 

Doug

 

 

-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Peter
Carl
Sent: Friday, October 04, 2013 11:49 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: [GSoC-PortA] Mean-mETL objective?

 

Hey Ross,

 

I can't seem to get the Mean-mETL objective to select anything other than
the Min mETL portfolio using ROI.  It looks like there should be good
convexity, but I think there's a substantial imbalance between the size of
the monthly mean return and the loss indicated by the ETL.  I've tried
modifying the multiplier on the mean, but it doesn't seem to have an effect.

 

Any thoughts?

 

pcc

--

Peter Carl

 <http://www.braverock.com/peter> http://www.braverock.com/peter

 

 

 

_______________________________________________

GSoC-PortA mailing list

 <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

 <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
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/20131005/981c2b21/attachment-0001.html>

From martinrd at comcast.net  Sat Oct  5 17:15:02 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sat, 5 Oct 2013 08:15:02 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
Message-ID: <002c01cec1dd$aa4c3fa0$fee4bee0$@comcast.net>

 

 

 

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Friday, October 04, 2013 12:43 PM
To: PortfolioAnalytics
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

Peter,

 

Unfortunately, with ROI we are only able to minimize ETL with ETL as an
objective. If you have mean and ETL as an objective using ROI, unless there
is a target in the mean return objective, we just minimize ETL. If you have
both mean and ETL as objectives, you could add a target to the mean
objective and this will minimize ETL subject to the target return. 

[Doug] That is unfortunate.

 

We can do the following with ETL as an objective using ROI:

 - Minimize ETL subject to leverage, box, group, exposure, position limit,
and target return.

 

Multipliers are ignored with ROI since the problems are formulated into an
LP/QP problem.

[Doug] Ditto on my comment above.  There is no problem to use solve.QP
directly in the quadratic utility (QU) formulation of the problem (as well
as the MinVar formulation). Should be the same for Rglpk.  So we are
inheriting a limitation of ROI not of the solvers themselves.

 

I'll take a look at the documentation in optimize.portfolio and make sure
this is clear.

 

I hope that helps clear it up.

 

Ross

 

On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com> wrote:

Hey Ross,

I can't seem to get the Mean-mETL objective to select anything other than
the Min mETL portfolio using ROI.  It looks like there should be good
convexity, but I think there's a substantial imbalance between the size of
the monthly mean return and the loss indicated by the ETL.  I've tried
modifying the multiplier on the mean, but it doesn't seem to have an
effect.

Any thoughts?

pcc
--
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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131005/4516afa2/attachment.html>

From martinrd at comcast.net  Sat Oct  5 18:06:58 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sat, 5 Oct 2013 09:06:58 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <524F1DE8.9030301@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
Message-ID: <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>

 

 

 

 

-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Friday, October 04, 2013 12:59 PM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

If it is an LP problem, I think you can only minimize subject to
constraints.

[Doug] Although I have never check this, it does not sound right.  The inner
product in the LP formulation of ETL supports that formulation of ETL as an
LP, but there should be no problem to adding another piece representing the
inner product of mean return forecasts and portfolio weights (mean portfolio
return estimate).  I will check it out, as I had intended to add this in the
ETL chapter.

 

If it is a QP problem, can't you do the mean/ETL portfolio?

 

That assumes the space is convex, which it will be for Gaussian ETL,

[Doug] But that case is not interesting, does not add value relative to MVO.

 

and may not be for modified Cornish Fisher ETL, but will be most of the
time, at most reasonable confidence levels.

[Doug] For both standard and modified ETL, the problem is in general
non-convex.  I guess you are saying from your experience the problem with
modified ETL usually appears to be convex.  I'm curious about how you
ascertain that?   E.g., because on multiple runs with DeOptim you seldom
find more than one local minimum?  That would certainly be reassuring.

 

 

Brian

 

On 10/04/2013 02:42 PM, Ross Bennett wrote:

> Peter,

> 

> Unfortunately, with ROI we are only able to minimize ETL with ETL as 

> an objective. If you have mean and ETL as an objective using ROI, 

> unless there is a target in the mean return objective, we just 

> minimize ETL. If you have both mean and ETL as objectives, you could 

> add a target to the mean objective and this will minimize ETL subject to
the target return.

> 

> We can do the following with ETL as an objective using ROI:

>   - Minimize ETL subject to leverage, box, group, exposure, position 

> limit, and target return.

> 

> Multipliers are ignored with ROI since the problems are formulated 

> into an LP/QP problem. I'll take a look at the documentation in 

> optimize.portfolio and make sure this is clear.

> 

> I hope that helps clear it up.

> 

> Ross

> 

> 

> On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com 

> < <mailto:peter at braverock.com> mailto:peter at braverock.com>> wrote:

> 

>     Hey Ross,

> 

>     I can't seem to get the Mean-mETL objective to select anything other

>     than

>     the Min mETL portfolio using ROI.  It looks like there should be good

>     convexity, but I think there's a substantial imbalance between the

>     size of

>     the monthly mean return and the loss indicated by the ETL.  I've tried

>     modifying the multiplier on the mean, but it doesn't seem to have an

>     effect.

> 

>     Any thoughts?

> 

>     pcc

_______________________________________________

GSoC-PortA mailing list

 <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

 <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
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/20131005/9e666204/attachment-0001.html>

From martinrd at comcast.net  Sat Oct  5 18:06:58 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sat, 5 Oct 2013 09:06:58 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <524F1DE8.9030301@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
Message-ID: <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>

 

 

 

 

-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Friday, October 04, 2013 12:59 PM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

If it is an LP problem, I think you can only minimize subject to
constraints.

[Doug] Although I have never check this, it does not sound right.  The inner
product in the LP formulation of ETL supports that formulation of ETL as an
LP, but there should be no problem to adding another piece representing the
inner product of mean return forecasts and portfolio weights (mean portfolio
return estimate).  I will check it out, as I had intended to add this in the
ETL chapter.

 

If it is a QP problem, can't you do the mean/ETL portfolio?

 

That assumes the space is convex, which it will be for Gaussian ETL,

[Doug] But that case is not interesting, does not add value relative to MVO.

 

and may not be for modified Cornish Fisher ETL, but will be most of the
time, at most reasonable confidence levels.

[Doug] For both standard and modified ETL, the problem is in general
non-convex.  I guess you are saying from your experience the problem with
modified ETL usually appears to be convex.  I'm curious about how you
ascertain that?   E.g., because on multiple runs with DeOptim you seldom
find more than one local minimum?  That would certainly be reassuring.

 

 

Brian

 

On 10/04/2013 02:42 PM, Ross Bennett wrote:

> Peter,

> 

> Unfortunately, with ROI we are only able to minimize ETL with ETL as 

> an objective. If you have mean and ETL as an objective using ROI, 

> unless there is a target in the mean return objective, we just 

> minimize ETL. If you have both mean and ETL as objectives, you could 

> add a target to the mean objective and this will minimize ETL subject to
the target return.

> 

> We can do the following with ETL as an objective using ROI:

>   - Minimize ETL subject to leverage, box, group, exposure, position 

> limit, and target return.

> 

> Multipliers are ignored with ROI since the problems are formulated 

> into an LP/QP problem. I'll take a look at the documentation in 

> optimize.portfolio and make sure this is clear.

> 

> I hope that helps clear it up.

> 

> Ross

> 

> 

> On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com 

> < <mailto:peter at braverock.com> mailto:peter at braverock.com>> wrote:

> 

>     Hey Ross,

> 

>     I can't seem to get the Mean-mETL objective to select anything other

>     than

>     the Min mETL portfolio using ROI.  It looks like there should be good

>     convexity, but I think there's a substantial imbalance between the

>     size of

>     the monthly mean return and the loss indicated by the ETL.  I've tried

>     modifying the multiplier on the mean, but it doesn't seem to have an

>     effect.

> 

>     Any thoughts?

> 

>     pcc

_______________________________________________

GSoC-PortA mailing list

 <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

 <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
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/20131005/9e666204/attachment-0002.html>

From martinrd at comcast.net  Sat Oct  5 18:13:12 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sat, 5 Oct 2013 09:13:12 -0700
Subject: [GSoC-PortA] Some feedback...
In-Reply-To: <CAEESW=W6Nw=xhcxEtq42Yut=GzUHtrVJsASVyxe6DJ1kjigzCQ@mail.gmail.com>
References: <6077558330b1a022003470c2092bae1b.squirrel@mail.braverock.com>
 <CAEESW=Vnm=gdrW-ZrNcs75PDMHjKQnoWjcQbbCXNvPtKyag6=A@mail.gmail.com>
 <d8bde6de6669c505e939538fbec8aeca.squirrel@mail.braverock.com>
 <CAEESW=XycK5GeBUvwdttkmwxtgcLvcLPTvjdjgurd5S9tpaLMA@mail.gmail.com>
 <30c9e004e0cf5f5dfda0cd17ef50ea01.squirrel@mail.braverock.com>
 <CAEESW=W6Nw=xhcxEtq42Yut=GzUHtrVJsASVyxe6DJ1kjigzCQ@mail.gmail.com>
Message-ID: <009401cec1e5$cae3a070$60aae150$@comcast.net>

I am just catching up with this thread.  Offhand, I think that combining a
bunch of objectives in a list and embedding in the portfolio$objectives slot
may be useful.  On the other hand, having a bunch of different objectives of
varying complexity "hidden" away in a singled list object in this manner may
be hard for the user to keep up with.  Minimally a good simple extraction
method for viewing, reminding yourself what they are would be key.  I will
think some more about this and discuss with Ross and Guy.

 

Thanks,

Doug

 

 

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Friday, October 04, 2013 1:55 PM
To: PortfolioAnalytics
Subject: Re: [GSoC-PortA] Some feedback...

 

I think I have a good first step in combining objective measures for all
portfolios in an opt.list object. My apologies in advance for the long
email, but I wanted to put this out there as this could be a pretty unique
feature in PortfolioAnalytics. 

 

Here is an outline of what I am doing.

 

Step 1: Get the objectives from the portfolio$objectives slot from each
optimize.portfolio object in the opt.list object and combine into a single
list of objectives. I am careful with how I construct the list so that
risk_budget objectives are added last.

 

Step 2: Detect and remove duplicates by objective name and type. The last
objective is the one that is kept. This is the comprehensive objectives list
of all objectives from each optimize.portfolio object in opt.list.

 

Step 3: Insert the comprehensive objectives list into the
portfolio$objectives slot in each optimize.portfolio object in the opt.list
object. Then call constrained_objective given the returns, weights, and
portfolio of each optimize.portfolio object. This allows the use of
different returns, assets, and constraints, but calculates the same
objectives.

 

The drawbacks of this approach is that the objective_measures are
recalculated and handling multiple arguments with different values is
tricky. 

 

For example, say we combine two optimize.portfolio objects and both have ES
as the only objective. The first object uses arguments=list(p=0.95,
clean="boudt") and the second object uses arguments=list(p=0.90,
clean="none") for the ES objective. The steps described above will use
p=0.90 and clean="none" to calculate the objective_measure.

 

One solution I thought of was to add a ... argument to
extractObjectiveMeasures() so the user can pass in arguments, otherwise
default to the steps described above.

 

This is obviously a simple case where the previous way of extracting the
objective_measures from multiple optimize.portfolio objects worked better,
but that way only worked if all portfolio objects had the exact same
objectives and types. 

 

Typing this I just realized I should probably do the following:

if( all objectives are identical) {

  extract objective_measures the previous way

} else {

  extract objective_measures using steps above

}

 

Any comments or suggestions?

 

Thanks,

Ross

 

On Tue, Sep 24, 2013 at 4:00 AM, Peter Carl <peter at braverock.com> wrote:

Now that I think about it a bit more, I think that returns and assets CAN
differ, as long as the measures are calculable at the portfolio level.
I'm not sure which of the processes you outlined below are preferable, but
they are definitely in the right direction.


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

> On Mon, Sep 23, 2013 at 1:19 PM, Peter Carl <peter at braverock.com> wrote:
>
>> Here's your comment from below:
>>
>> "It is tough to tell with the formatting on the email, but I'll take a
>> closer look at the script in the sandbox to see if I can tell what is
>> going on. The idea is that extractObjectiveMeasures will return a matrix
>> of the objective measures for all optimize.portfolio objects in the
>> opt.list object. For example, the meanSD row should have NAs under the
>> ETL
>> and ETL component contribution columns. I am only stitching together the
>> objective measures, I do not re-calculate StdDev or component StdDev for
>> the portfolios with ETL as an objective. Basically, I just take whatever
>> objectives are in the $objective_measures slot of each
>> optimize.portfolio
>> object. Should I be doing something such that all cells in the matrix
>> have
>> values? "
>>
>> I think so, although I doubt this has been well spelled out before.  The
>> question is: can we anticipate how to fill in these values given the
>> information in each object?
>>
>
> I think we might be able to depending on how the objective measures are
> calculated on the weights.
>
> One way would be to pick out the objective names, match the name to the
> function, and then calculate the objectives on the weights. The parameters
> could be pulled from the $arguments list in each objective. This might be
> tricky if there are multiple arguments with different arguments. This is
> likely the simplest solution. If "ES" is an objective name, we could by
> default calculate it with portfolio_method="component" since the
> univariate
> ES also calculated.
>
> Another way is to combine all the objectives from each object, try to
> detect and remove duplicate objectives objects, then pass that portfolio
> object to constrained_objective to calculate over the weights.
>
> Not sure which way is better, I'll have to give this some thought and try
> out a few things.
>
>
>>
>> When I do this by hand, I'm just calculating for the list of optimal
>> weights of each objective for each measure.  At that point, I can make
>> comparisons I couldn't otherwise.
>>
>> Note that the objectives can be vastly different, as long as the assets
>> are the same and the parameters for each of the metrics are the same.
>>
>
> I could add a check to make sure that the assets and returns are the same
> in each optimize.portfolio object. I think this will only work if that is
> the case. It would be nice to have the flexibility to have different
> assets
> and returns, but that may not be doable.
>
>
>>
>> Does that make sense?
>>
>
> It does make sense, thanks for the feedback.
>
>
>>
>> pcc
>> --
>> Peter Carl
>> http://www.braverock.com/peter
>>
>> > Peter,
>> >
>> > Thanks for the feedback, I really appreciate it.
>> >
>> > see comments in line.
>> >
>> >
>> > On Sun, Sep 22, 2013 at 4:41 PM, Peter Carl <peter at braverock.com>
>> wrote:
>> >
>> >> Ross,
>> >>
>> >> I've been working through your vignette to hopefully give you some
>> more
>> >> detailed feedback, including on your questions from a few days ago.
>> >> Sorry
>> >> this has taken so long, but I wanted to spend some focused time on
>> the
>> >> package.
>> >>
>> >> I realize that you've got different plot methods for each type, and I
>> >> appreciate what a hassle it is to keep such methods relatively
>> >> consistent.
>> >>  In chart.RiskReturn.DE, when the function doesn't find anything that
>> >> fits
>> >> its defaults:
>> >> > plot(RiskBudget.DE)
>> >> Error in plot.window(...) : need finite 'xlim' values
>> >> In addition: Warning messages:
>> >> 1: In chart.Scatter.DE(object = DE, risk.col = risk.col, return.col =
>> >> return.col,  :
>> >>   mean or ES do  not match extractStats output of $objective_measures
>> >> slot
>> >> 2: In min(x) : no non-missing arguments to min; returning Inf
>> >> 3: In max(x) : no non-missing arguments to max; returning -Inf
>> >>
>> >> It's a risk budget on ETL, so if I tell it that, it works:
>> >> > plot(RiskBudget.DE, risk.col="ETL", return.col="mean")
>> >>
>> >
>> > The default is risk.col="ES". Because your objective name is "ETL",
>> you
>> > need to explicitly do risk.col="ETL".
>> >
>> >
>> >>
>> >> ...but it doesn't recover well when I try to plot the results in
>> >> variance
>> >> space:
>> >> > plot(RiskBudget.DE, risk.col="StdDev", return.col="mean")
>> >> Error in plot.window(...) : need finite 'xlim' values
>> >> In addition: Warning messages:
>> >> 1: In chart.Scatter.DE(object = DE, risk.col = risk.col, return.col =
>> >> return.col,  :
>> >>   mean or StdDev do  not match extractStats output of
>> >> $objective_measures
>> >> slot
>> >> 2: In min(x) : no non-missing arguments to min; returning Inf
>> >> 3: In max(x) : no non-missing arguments to max; returning -Inf
>> >>
>> >>
>> >> I'm not exactly sure what the issue is here, but maybe it's related:
>> >> > chart.RiskBudget(RiskBudget.DE, risk.type="percentage",
>> neighbors=5)
>> >> Error in subsetx[i, riskcols] : incorrect number of dimensions
>> >> > traceback()
>> >> 3: points(subsetx[i, riskcols], type = "b", col = "lightblue")
>> >> 2: chart.RiskBudget.optimize.portfolio(RiskBudget.DE, risk.type =
>> >> "percentage",
>> >>        neighbors = 5)
>> >> 1: chart.RiskBudget(RiskBudget.DE, risk.type = "percentage",
>> neighbors =
>> >> 5)
>> >>
>> >
>> > Not sure either what the issue is, but I'll take a look.
>> >
>> >
>> >> In chart.RiskReturnScatter.RP, it looks like 'rp' is being passed
>> into
>> >> plot through dots.
>> >> > plot(EqmETL.RND, risk.col="StdDev", return.col="mean", rp=1000,
>> >> chart.assets=TRUE)
>> >> There were 13 warnings (use warnings() to see them)
>> >> > warnings()
>> >> Warning messages:
>> >> 1: "rp" is not a graphical parameter
>> >> 2: "rp" is not a graphical parameter
>> >> 3: "rp" is not a graphical parameter
>> >>
>> >
>> > The 'rp' argument is meant for optimize.portfolio.ROI and
>> > optimize.portfolio.GenSA objects. Since ROI and GenSA do not return
>> trace
>> > information like DEoptim or random portfolios, I added this as an
>> option
>> > to
>> > generate random portfolios to plot the feasible space. If you are
>> already
>> > passing in an optimize.portfolio.random object, there is no need to
>> pass
>> > in
>> > rp as an argument.
>> >
>> >
>> >>
>> >>
>> >> > extractWeights(buoys)
>> >>          Convertible Arbitrage Equity Market Neutral Fixed Income
>> >> Arbitrage Event Driven CTA Global Global Macro Long/Short Equity
>> >> MeanSD              0.05000000                 0.050
>> >> 0.050   0.30000000  0.0500000    0.2000000             0.300
>> >> MeanmETL            0.05000000                 0.300
>> >> 0.050   0.05000000  0.2000000    0.3000000             0.050
>> >> MinSD               0.06042904                 0.300
>> >> 0.300   0.05234676  0.1735858    0.0636384             0.050
>> >> MinmETL             0.05000000                 0.300
>> >> 0.050   0.05000000  0.2000000    0.3000000             0.050
>> >> EqSD                0.12500000                 0.240
>> >> 0.200   0.08500000  0.1050000    0.1700000             0.075
>> >> EqmETL              0.06000000                 0.265
>> >> 0.165   0.09000000  0.2050000    0.1300000             0.080
>> >> RB                  0.05200000                 0.410
>> >> 0.060   0.05200000  0.1438995    0.2220000             0.058
>> >>
>> >> ...but this doesn't:
>> >> > extractObjectiveMeasures(buoys)
>> >>                 mean     StdDev         ES StdDev.contribution1
>> >> StdDev.contribution2 StdDev.contribution3
>> >> StdDev.contribution4
>> >> MeanSD   0.006782814 0.01546759         NA                   NA
>> >>        NA                   NA                   NA
>> >> MeanmETL 0.005897789         NA 0.01505626                   NA
>> >>        NA                   NA                   NA
>> >> MinSD             NA 0.01009001         NA                   NA
>> >>        NA                   NA                   NA
>> >> MinmETL           NA         NA 0.01505626                   NA
>> >>        NA                   NA                   NA
>> >> EqSD              NA 0.01113716         NA          0.001763096
>> >> 0.001565752          0.001886988          0.001258567
>> >> EqmETL            NA         NA 0.01646509                   NA
>> >>        NA                   NA                   NA
>> >> RB       0.005812997         NA         NA                   NA
>> >>        NA                   NA                   NA
>> >>          StdDev.contribution5 StdDev.contribution6
>> StdDev.contribution7
>> >> StdDev.pct_contrib_StdDev1 StdDev.pct_contrib_StdDev2
>> >> MeanSD                     NA                   NA
>> NA
>> >>                      NA                         NA
>> >> MeanmETL                   NA                   NA
>> NA
>> >>                      NA                         NA
>> >> MinSD                      NA                   NA
>> NA
>> >>                      NA                         NA
>> >> MinmETL                    NA                   NA
>> NA
>> >>                      NA                         NA
>> >> EqSD              0.001039908          0.002296903
>> 0.001325947
>> >>               0.1583075                  0.1405881
>> >> EqmETL                     NA                   NA
>> NA
>> >>                      NA                         NA
>> >> RB                         NA                   NA
>> NA
>> >>                      NA                         NA
>> >> ...snip...
>> >>
>> >>
>> > It is tough to tell with the formatting on the email, but I'll take a
>> > closer look at the script in the sandbox to see if I can tell what is
>> > going
>> > on. The idea is that extractObjectiveMeasures will return a matrix of
>> the
>> > objective measures for all optimize.portfolio objects in the opt.list
>> > object. For example, the meanSD row should have NAs under the ETL and
>> ETL
>> > component contribution columns. I am only stitching together the
>> objective
>> > measures, I do not re-calculate StdDev or component StdDev for the
>> > portfolios with ETL as an objective. Basically, I just take whatever
>> > objectives are in the $objective_measures slot of each
>> optimize.portfolio
>> > object. Should I be doing something such that all cells in the matrix
>> have
>> > values?
>> >
>> >
>> >> As a consequence, only one portfolio appears in the following plot
>> >> (MeanSD):
>> >> > chart.RiskReward(buoys)
>> >>
>> >
>> > This relates to my comment above about how I am not recalculating
>> > anything.
>> > Before the portfolios are plotted in risk-return space, I omit rows
>> that
>> > have NA values. For example, if you wanted to plot all the portfolios
>> in
>> > mean-ETL space, all portfolios should have mean and ETL as an
>> objective.
>> > You could set the multiplier to 0 so it does not affect the
>> optimization,
>> > but is returned in the $objective_measures slot.
>> >
>> >
>> >>
>> >> All in all, this is all looking good.  I've got some scripts checked
>> in
>> >> under sandbox/symposium2013 if you want to follow along.
>> >>
>> >
>> > I'll take a closer look and follow along, thanks!
>> >
>> >
>> >>
>> >> pcc
>> >> --
>> >> 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/20131005/70a75394/attachment-0001.html>

From brian at braverock.com  Sun Oct  6 15:04:51 2013
From: brian at braverock.com (Brian G. Peterson)
Date: Sun, 06 Oct 2013 08:04:51 -0500
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <002701cec1dd$041b1520$0c513f60$@comcast.net>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <002701cec1dd$041b1520$0c513f60$@comcast.net>
Message-ID: <52515FF3.4080009@braverock.com>


Can't we assume convexity, even if we're wrong?

In many cases, the upper hull of the mean/mETL space will be convex, and 
the lack of convexity will manifest itself only in the lower hull.

Right now, we don't do the mean/ETL tangency portfolio even when we have 
Gaussian ETL.  It seems that we should be able to support this for the 
mean/ETL space, and extend it with appropriate caveats to the mean/mETL 
space.

Doug is correct that in the presence of skewness and kurtosis the upper 
hull may be sufficiently bumpy that the quadratic (or is it conical?) 
form won't hold.  It seems that we could address this in the documentation.

On 10/05/2013 10:10 AM, Doug Martin wrote:
> Peter,
>
> While you have convexity with ETL, that would not hold with mETL due to
> presence of skewness and kurtosis of portfolio returns that depend upon
> the weights.  I?ll have a look at the rest of this thread.
>
> Doug
>
> -----Original Message-----
> From: Peter Carl
> Sent: Friday, October 04, 2013 11:49 AM
>
> Hey Ross,
>
> I can't seem to get the Mean-mETL objective to select anything other
> than the Min mETL portfolio using ROI.  It looks like there should be
> good convexity, but I think there's a substantial imbalance between the
> size of the monthly mean return and the loss indicated by the ETL.  I've
> tried modifying the multiplier on the mean, but it doesn't seem to have
> an effect.
>
> Any thoughts?
>
> pcc
>
> --

From brian at braverock.com  Sun Oct  6 15:23:18 2013
From: brian at braverock.com (Brian G. Peterson)
Date: Sun, 06 Oct 2013 08:23:18 -0500
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <002c01cec1dd$aa4c3fa0$fee4bee0$@comcast.net>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <002c01cec1dd$aa4c3fa0$fee4bee0$@comcast.net>
Message-ID: <52516446.3080300@braverock.com>

Doug,

If the underlying solvers can do it, we should be able to pass it 
through to ROI.  There shouldn't be any inherent restriction from using ROI.

I think, based on reading your replies, that we just need to understand 
how to formulate the problem.

DEoptim only finds one minima, and it appears to be the correct one. 
'Neighbor' portfolios (the portfolios closest to the global minima by 
objective vaule) are all close in the hull space to the global minima.

Overall, I'd hope to investigate this a bit more, because if the 
formulation as a LP/QP problem is possible, it's obviously much faster 
than using random portfolios or DEoptim (or PSO, or GenSA, etc) to find 
the objective.

Regards,

Brian

On 10/05/2013 10:15 AM, Doug Martin wrote:
> *Ross Bennett wrote:
> Peter,
>
> Unfortunately, with ROI we are only able to minimize ETL with ETL as an
> objective. If you have mean and ETL as an objective using ROI, unless
> there is a target in the mean return objective, we just minimize ETL. If
> you have both mean and ETL as objectives, you could add a target to the
> mean objective and this will minimize ETL subject to the target return.
>
> */[Doug] That is unfortunate./*
>
> We can do the following with ETL as an objective using ROI:
>
>   - Minimize ETL subject to leverage, box, group, exposure, position
> limit, and target return.
>
> Multipliers are ignored with ROI since the problems are formulated into
> an LP/QP problem.
>
> */[Doug] Ditto on my comment above.  There is no problem to use solve.QP
> directly in the quadratic utility (QU) formulation of the problem (as
> well as the MinVar formulation). Should be the same for Rglpk.  So we
> are inheriting a limitation of ROI not of the solvers themselves./*
>
> *//*
>
> I'll take a look at the documentation in optimize.portfolio and make
> sure this is clear.
>
> I hope that helps clear it up.
>
> Ross
>
> On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com
> <mailto:peter at braverock.com>> wrote:
>
> Hey Ross,
>
> I can't seem to get the Mean-mETL objective to select anything other than
> the Min mETL portfolio using ROI.  It looks like there should be good
> convexity, but I think there's a substantial imbalance between the size of
> the monthly mean return and the loss indicated by the ETL.  I've tried
> modifying the multiplier on the mean, but it doesn't seem to have an
> effect.
>
> Any thoughts?
>
> pcc
> --
> Peter Carl
> http://www.braverock.com/peter
>
>
>
> _______________________________________________
> GSoC-PortA mailing list
> GSoC-PortA at lists.r-forge.r-project.org
> <mailto: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
>


-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock

From brian at braverock.com  Sun Oct  6 15:36:08 2013
From: brian at braverock.com (Brian G. Peterson)
Date: Sun, 06 Oct 2013 08:36:08 -0500
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
Message-ID: <52516748.6090605@braverock.com>

Doug,

Per my other emails in this thread, I'd love to know how to formulate 
the mean/ETL problem as an LP.

This UW dissertation is one of the early links on Google:

https://digital.lib.washington.edu/researchworks/bitstream/handle/1773/21869/Zhang_washington_0250E_10711.pdf?sequence=1

page 26 of the document (p38 of the pdf) constructs the mean/ETL problem 
as a linear programming problem.

I haven't followed it further than this, but it appears that we just 
need to sort out the formulation, and we should be good.

The Cornish Fisher solution will be locally convex over much of its 
feasible space.  It is often not globally convext across variations in 
probability 'p' (or 'alpha', though I dislike the alpha notation since 
alpha is such a loaded word in finance).  It is not guaranteed to be 
convex, of course, and will not be convex if skewness or kurtosis are 
sufficiently large and the 'p' setting is sufficiently large.

so, based on what I've been able to read this morning, it seems we just 
need to get the formulation correct, and we should be able to treat 
mean/ETL optimization as an LP problem.

Brian

On 10/05/2013 11:06 AM, Doug Martin wrote:
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of
> Brian G. Peterson
> Sent: Friday, October 04, 2013 12:59 PM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?
>
> If it is an LP problem, I think you can only minimize subject to
> constraints.
>
> */[Doug] Although I have never check this, it does not sound right.  The
> inner product in the LP formulation of ETL supports that formulation of
> ETL as an LP, but there should be no problem to adding another piece
> representing the inner product of mean return forecasts and portfolio
> weights (mean portfolio return estimate).  I will check it out, as I had
> intended to add this in the ETL chapter./*
>
> If it is a QP problem, can't you do the mean/ETL portfolio?
>
> That assumes the space is convex, which it will be for Gaussian ETL,
>
> */[Doug] But that case is not interesting, does not add value relative
> to MVO./*
>
> *//*
>
> and may not be for modified Cornish Fisher ETL, but will be most of the
> time, at most reasonable confidence levels.
>
> */[Doug] For both standard and modified ETL, the problem is in general
> non-convex.  I guess you are saying from your experience the problem
> with modified ETL usually appears to be convex.  I?m curious about how
> you ascertain that?   E.g., because on multiple runs with DeOptim you
> seldom find more than one local minimum?  That would certainly be
> reassuring./*
>
> *//*
>
> Brian
>
> On 10/04/2013 02:42 PM, Ross Bennett wrote:
>
>  > Peter,
>
>  >
>
>  > Unfortunately, with ROI we are only able to minimize ETL with ETL as
>
>  > an objective. If you have mean and ETL as an objective using ROI,
>
>  > unless there is a target in the mean return objective, we just
>
>  > minimize ETL. If you have both mean and ETL as objectives, you could
>
>  > add a target to the mean objective and this will minimize ETL subject
> to the target return.
>
>  >
>
>  > We can do the following with ETL as an objective using ROI:
>
>  >   - Minimize ETL subject to leverage, box, group, exposure, position
>
>  > limit, and target return.
>
>  >
>
>  > Multipliers are ignored with ROI since the problems are formulated
>
>  > into an LP/QP problem. I'll take a look at the documentation in
>
>  > optimize.portfolio and make sure this is clear.
>
>  >
>
>  > I hope that helps clear it up.
>
>  >
>
>  > Ross
>
>  >
>
>  >
>
>  > On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com
>
>  > <mailto:peter at braverock.com>> wrote:
>
>  >
>
>  >     Hey Ross,
>
>  >
>
>  >     I can't seem to get the Mean-mETL objective to select anything other
>
>  >     than
>
>  >     the Min mETL portfolio using ROI.  It looks like there should be good
>
>  >     convexity, but I think there's a substantial imbalance between the
>
>  >     size of
>
>  >     the monthly mean return and the loss indicated by the ETL.  I've
> tried
>
>  >     modifying the multiplier on the mean, but it doesn't seem to have an
>
>  >     effect.
>
>  >
>
>  >     Any thoughts?
>
>  >
>
>  >     pcc
>
> _______________________________________________
>
> GSoC-PortA mailing list
>
> GSoC-PortA at lists.r-forge.r-project.org
> <mailto: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
>


-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock

From martinrd at comcast.net  Sun Oct  6 16:19:49 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 07:19:49 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52515FF3.4080009@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <002701cec1dd$041b1520$0c513f60$@comcast.net>
 <52515FF3.4080009@braverock.com>
Message-ID: <000a01cec29f$1e0b2ac0$5a218040$@comcast.net>

We are talking about convexity differently.  You are talking about the
mean-return versus risk efficient frontier.  I am talking about the
optimization problem (for any single point on the efficient frontier).  By
the way in mathematics the usual convention is that what you call convex is
usually called concave   Using that convention, the efficient frontier can
be non-convex with some constraints even in the MVO case, e.g., with MIP for
constraining the number of assets in the portfolio that happens (see Figure
3.1 in Scherer and Martin).

See additional comments below.

 

-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 6:05 AM
To: PortfolioAnalytics
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

 

Can't we assume convexity, even if we're wrong?

 

In many cases, the upper hull of the mean/mETL space will be convex, and the
lack of convexity will manifest itself only in the lower hull.

 

Right now, we don't do the mean/ETL tangency portfolio even when we have
Gaussian ETL.  It seems that we should be able to support this for the
mean/ETL space, and extend it with appropriate caveats to the mean/mETL
space.

[Doug] It will be no problem to compute this by efficient search along a
concave efficient frontier so long as the mean return of the global minimum
risk portfolio is larger than the risk free-rate.  Otherwise there is no
tangency portfolio.

 

Doug is correct that in the presence of skewness and kurtosis the upper hull
may be sufficiently bumpy that the quadratic (or is it conical?) form won't
hold.  It seems that we could address this in the documentation.

 

On 10/05/2013 10:10 AM, Doug Martin wrote:

> Peter,

> 

> While you have convexity with ETL, that would not hold with mETL due 

> to presence of skewness and kurtosis of portfolio returns that depend 

> upon the weights.  I'll have a look at the rest of this thread.

> 

> Doug

> 

> -----Original Message-----

> From: Peter Carl

> Sent: Friday, October 04, 2013 11:49 AM

> 

> Hey Ross,

> 

> I can't seem to get the Mean-mETL objective to select anything other 

> than the Min mETL portfolio using ROI.  It looks like there should be 

> good convexity, but I think there's a substantial imbalance between 

> the size of the monthly mean return and the loss indicated by the ETL.  

> I've tried modifying the multiplier on the mean, but it doesn't seem 

> to have an effect.

> 

> Any thoughts?

> 

> pcc

> 

> --

_______________________________________________

GSoC-PortA mailing list

 <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

 <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
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/20131006/71e5046c/attachment-0002.html>

From martinrd at comcast.net  Sun Oct  6 16:19:49 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 07:19:49 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52515FF3.4080009@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <002701cec1dd$041b1520$0c513f60$@comcast.net>
 <52515FF3.4080009@braverock.com>
Message-ID: <000a01cec29f$1e0b2ac0$5a218040$@comcast.net>

We are talking about convexity differently.  You are talking about the
mean-return versus risk efficient frontier.  I am talking about the
optimization problem (for any single point on the efficient frontier).  By
the way in mathematics the usual convention is that what you call convex is
usually called concave   Using that convention, the efficient frontier can
be non-convex with some constraints even in the MVO case, e.g., with MIP for
constraining the number of assets in the portfolio that happens (see Figure
3.1 in Scherer and Martin).

See additional comments below.

 

-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 6:05 AM
To: PortfolioAnalytics
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

 

Can't we assume convexity, even if we're wrong?

 

In many cases, the upper hull of the mean/mETL space will be convex, and the
lack of convexity will manifest itself only in the lower hull.

 

Right now, we don't do the mean/ETL tangency portfolio even when we have
Gaussian ETL.  It seems that we should be able to support this for the
mean/ETL space, and extend it with appropriate caveats to the mean/mETL
space.

[Doug] It will be no problem to compute this by efficient search along a
concave efficient frontier so long as the mean return of the global minimum
risk portfolio is larger than the risk free-rate.  Otherwise there is no
tangency portfolio.

 

Doug is correct that in the presence of skewness and kurtosis the upper hull
may be sufficiently bumpy that the quadratic (or is it conical?) form won't
hold.  It seems that we could address this in the documentation.

 

On 10/05/2013 10:10 AM, Doug Martin wrote:

> Peter,

> 

> While you have convexity with ETL, that would not hold with mETL due 

> to presence of skewness and kurtosis of portfolio returns that depend 

> upon the weights.  I'll have a look at the rest of this thread.

> 

> Doug

> 

> -----Original Message-----

> From: Peter Carl

> Sent: Friday, October 04, 2013 11:49 AM

> 

> Hey Ross,

> 

> I can't seem to get the Mean-mETL objective to select anything other 

> than the Min mETL portfolio using ROI.  It looks like there should be 

> good convexity, but I think there's a substantial imbalance between 

> the size of the monthly mean return and the loss indicated by the ETL.  

> I've tried modifying the multiplier on the mean, but it doesn't seem 

> to have an effect.

> 

> Any thoughts?

> 

> pcc

> 

> --

_______________________________________________

GSoC-PortA mailing list

 <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

 <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
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/20131006/71e5046c/attachment-0003.html>

From martinrd at comcast.net  Sun Oct  6 16:24:13 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 07:24:13 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52516446.3080300@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <002c01cec1dd$aa4c3fa0$fee4bee0$@comcast.net>
 <52516446.3080300@braverock.com>
Message-ID: <000f01cec29f$bbb4cce0$331e66a0$@comcast.net>

 

 

 

 

-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 6:23 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

Doug,

 

If the underlying solvers can do it, we should be able to pass it through to
ROI.  There shouldn't be any inherent restriction from using ROI.

[Doug] Agreed.

 

I think, based on reading your replies, that we just need to understand how
to formulate the problem.

[Doug] That is done.

 

DEoptim only finds one minima, and it appears to be the correct one. 

'Neighbor' portfolios (the portfolios closest to the global minima by
objective vaule) are all close in the hull space to the global minima.

 

Overall, I'd hope to investigate this a bit more, because if the formulation
as a LP/QP problem is possible, it's obviously much faster than using random
portfolios or DEoptim (or PSO, or GenSA, etc) to find the objective.

[Doug] I think spend a little time on this later this autumn or early
winter.

 

Regards,

 

Brian

 

On 10/05/2013 10:15 AM, Doug Martin wrote:

> *Ross Bennett wrote:

> Peter,

> 

> Unfortunately, with ROI we are only able to minimize ETL with ETL as 

> an objective. If you have mean and ETL as an objective using ROI, 

> unless there is a target in the mean return objective, we just 

> minimize ETL. If you have both mean and ETL as objectives, you could 

> add a target to the mean objective and this will minimize ETL subject to
the target return.

> 

> */[Doug] That is unfortunate./*

> 

> We can do the following with ETL as an objective using ROI:

> 

>   - Minimize ETL subject to leverage, box, group, exposure, position 

> limit, and target return.

> 

> Multipliers are ignored with ROI since the problems are formulated 

> into an LP/QP problem.

> 

> */[Doug] Ditto on my comment above.  There is no problem to use 

> solve.QP directly in the quadratic utility (QU) formulation of the 

> problem (as well as the MinVar formulation). Should be the same for 

> Rglpk.  So we are inheriting a limitation of ROI not of the solvers 

> themselves./*

> 

> *//*

> 

> I'll take a look at the documentation in optimize.portfolio and make 

> sure this is clear.

> 

> I hope that helps clear it up.

> 

> Ross

> 

> On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com 

> < <mailto:peter at braverock.com> mailto:peter at braverock.com>> wrote:

> 

> Hey Ross,

> 

> I can't seem to get the Mean-mETL objective to select anything other 

> than the Min mETL portfolio using ROI.  It looks like there should be 

> good convexity, but I think there's a substantial imbalance between 

> the size of the monthly mean return and the loss indicated by the ETL.  

> I've tried modifying the multiplier on the mean, but it doesn't seem 

> to have an effect.

> 

> Any thoughts?

> 

> pcc

> --

> Peter Carl

>  <http://www.braverock.com/peter> http://www.braverock.com/peter

> 

> 

> 

> _______________________________________________

> GSoC-PortA mailing list

>  <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

> < <mailto:GSoC-PortA at lists.r-forge.r-project.org>
mailto:GSoC-PortA at lists.r-forge.r-project.org>

>  <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta

> 

> 

> 

> _______________________________________________

> GSoC-PortA mailing list

>  <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

>  <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta

> 

 

 

--

Brian G. Peterson

 <http://braverock.com/brian/> http://braverock.com/brian/

Ph: 773-459-4973

IM: bgpbraverock

_______________________________________________

GSoC-PortA mailing list

 <mailto:GSoC-PortA at lists.r-forge.r-project.org>
GSoC-PortA at lists.r-forge.r-project.org

 <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
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/20131006/51a118a1/attachment.html>

From martinrd at comcast.net  Sun Oct  6 16:48:33 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 07:48:33 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52516748.6090605@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
Message-ID: <002001cec2a3$218168f0$64843ad0$@comcast.net>

The LP formulation, as well as the intrinsic convexity of the basic CVaR/ETL
problem was established by Rockafellar and Uryasev (2000).  With mETL none
of those results follow.    

Doug

P.S. I don't know if you noticed that Zhang was my Ph.D. student.   



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 6:36 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

Doug,

Per my other emails in this thread, I'd love to know how to formulate the
mean/ETL problem as an LP.

This UW dissertation is one of the early links on Google:

https://digital.lib.washington.edu/researchworks/bitstream/handle/1773/21869
/Zhang_washington_0250E_10711.pdf?sequence=1

page 26 of the document (p38 of the pdf) constructs the mean/ETL problem as
a linear programming problem.

I haven't followed it further than this, but it appears that we just need to
sort out the formulation, and we should be good.

The Cornish Fisher solution will be locally convex over much of its feasible
space.  It is often not globally convext across variations in probability
'p' (or 'alpha', though I dislike the alpha notation since alpha is such a
loaded word in finance).  It is not guaranteed to be convex, of course, and
will not be convex if skewness or kurtosis are sufficiently large and the
'p' setting is sufficiently large.

so, based on what I've been able to read this morning, it seems we just need
to get the formulation correct, and we should be able to treat mean/ETL
optimization as an LP problem.

Brian

On 10/05/2013 11:06 AM, Doug Martin wrote:
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of 
> Brian G. Peterson
> Sent: Friday, October 04, 2013 12:59 PM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?
>
> If it is an LP problem, I think you can only minimize subject to 
> constraints.
>
> */[Doug] Although I have never check this, it does not sound right.  
> The inner product in the LP formulation of ETL supports that 
> formulation of ETL as an LP, but there should be no problem to adding 
> another piece representing the inner product of mean return forecasts 
> and portfolio weights (mean portfolio return estimate).  I will check 
> it out, as I had intended to add this in the ETL chapter./*
>
> If it is a QP problem, can't you do the mean/ETL portfolio?
>
> That assumes the space is convex, which it will be for Gaussian ETL,
>
> */[Doug] But that case is not interesting, does not add value relative 
> to MVO./*
>
> *//*
>
> and may not be for modified Cornish Fisher ETL, but will be most of 
> the time, at most reasonable confidence levels.
>
> */[Doug] For both standard and modified ETL, the problem is in general 
> non-convex.  I guess you are saying from your experience the problem 
> with modified ETL usually appears to be convex.  I'm curious about how
> you ascertain that?   E.g., because on multiple runs with DeOptim you
> seldom find more than one local minimum?  That would certainly be
> reassuring./*
>
> *//*
>
> Brian
>
> On 10/04/2013 02:42 PM, Ross Bennett wrote:
>
>  > Peter,
>
>  >
>
>  > Unfortunately, with ROI we are only able to minimize ETL with ETL 
> as
>
>  > an objective. If you have mean and ETL as an objective using ROI,
>
>  > unless there is a target in the mean return objective, we just
>
>  > minimize ETL. If you have both mean and ETL as objectives, you 
> could
>
>  > add a target to the mean objective and this will minimize ETL 
> subject to the target return.
>
>  >
>
>  > We can do the following with ETL as an objective using ROI:
>
>  >   - Minimize ETL subject to leverage, box, group, exposure, position
>
>  > limit, and target return.
>
>  >
>
>  > Multipliers are ignored with ROI since the problems are formulated
>
>  > into an LP/QP problem. I'll take a look at the documentation in
>
>  > optimize.portfolio and make sure this is clear.
>
>  >
>
>  > I hope that helps clear it up.
>
>  >
>
>  > Ross
>
>  >
>
>  >
>
>  > On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com
>
>  > <mailto:peter at braverock.com>> wrote:
>
>  >
>
>  >     Hey Ross,
>
>  >
>
>  >     I can't seem to get the Mean-mETL objective to select anything
other
>
>  >     than
>
>  >     the Min mETL portfolio using ROI.  It looks like there should be
good
>
>  >     convexity, but I think there's a substantial imbalance between the
>
>  >     size of
>
>  >     the monthly mean return and the loss indicated by the ETL.  I've
> tried
>
>  >     modifying the multiplier on the mean, but it doesn't seem to have
an
>
>  >     effect.
>
>  >
>
>  >     Any thoughts?
>
>  >
>
>  >     pcc
>
> _______________________________________________
>
> GSoC-PortA mailing list
>
> GSoC-PortA at lists.r-forge.r-project.org
> <mailto: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
>


--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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


From martinrd at comcast.net  Sun Oct  6 16:48:33 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 07:48:33 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52516748.6090605@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
Message-ID: <002001cec2a3$218168f0$64843ad0$@comcast.net>

The LP formulation, as well as the intrinsic convexity of the basic CVaR/ETL
problem was established by Rockafellar and Uryasev (2000).  With mETL none
of those results follow.    

Doug

P.S. I don't know if you noticed that Zhang was my Ph.D. student.   



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 6:36 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

Doug,

Per my other emails in this thread, I'd love to know how to formulate the
mean/ETL problem as an LP.

This UW dissertation is one of the early links on Google:

https://digital.lib.washington.edu/researchworks/bitstream/handle/1773/21869
/Zhang_washington_0250E_10711.pdf?sequence=1

page 26 of the document (p38 of the pdf) constructs the mean/ETL problem as
a linear programming problem.

I haven't followed it further than this, but it appears that we just need to
sort out the formulation, and we should be good.

The Cornish Fisher solution will be locally convex over much of its feasible
space.  It is often not globally convext across variations in probability
'p' (or 'alpha', though I dislike the alpha notation since alpha is such a
loaded word in finance).  It is not guaranteed to be convex, of course, and
will not be convex if skewness or kurtosis are sufficiently large and the
'p' setting is sufficiently large.

so, based on what I've been able to read this morning, it seems we just need
to get the formulation correct, and we should be able to treat mean/ETL
optimization as an LP problem.

Brian

On 10/05/2013 11:06 AM, Doug Martin wrote:
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of 
> Brian G. Peterson
> Sent: Friday, October 04, 2013 12:59 PM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?
>
> If it is an LP problem, I think you can only minimize subject to 
> constraints.
>
> */[Doug] Although I have never check this, it does not sound right.  
> The inner product in the LP formulation of ETL supports that 
> formulation of ETL as an LP, but there should be no problem to adding 
> another piece representing the inner product of mean return forecasts 
> and portfolio weights (mean portfolio return estimate).  I will check 
> it out, as I had intended to add this in the ETL chapter./*
>
> If it is a QP problem, can't you do the mean/ETL portfolio?
>
> That assumes the space is convex, which it will be for Gaussian ETL,
>
> */[Doug] But that case is not interesting, does not add value relative 
> to MVO./*
>
> *//*
>
> and may not be for modified Cornish Fisher ETL, but will be most of 
> the time, at most reasonable confidence levels.
>
> */[Doug] For both standard and modified ETL, the problem is in general 
> non-convex.  I guess you are saying from your experience the problem 
> with modified ETL usually appears to be convex.  I'm curious about how
> you ascertain that?   E.g., because on multiple runs with DeOptim you
> seldom find more than one local minimum?  That would certainly be
> reassuring./*
>
> *//*
>
> Brian
>
> On 10/04/2013 02:42 PM, Ross Bennett wrote:
>
>  > Peter,
>
>  >
>
>  > Unfortunately, with ROI we are only able to minimize ETL with ETL 
> as
>
>  > an objective. If you have mean and ETL as an objective using ROI,
>
>  > unless there is a target in the mean return objective, we just
>
>  > minimize ETL. If you have both mean and ETL as objectives, you 
> could
>
>  > add a target to the mean objective and this will minimize ETL 
> subject to the target return.
>
>  >
>
>  > We can do the following with ETL as an objective using ROI:
>
>  >   - Minimize ETL subject to leverage, box, group, exposure, position
>
>  > limit, and target return.
>
>  >
>
>  > Multipliers are ignored with ROI since the problems are formulated
>
>  > into an LP/QP problem. I'll take a look at the documentation in
>
>  > optimize.portfolio and make sure this is clear.
>
>  >
>
>  > I hope that helps clear it up.
>
>  >
>
>  > Ross
>
>  >
>
>  >
>
>  > On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com
>
>  > <mailto:peter at braverock.com>> wrote:
>
>  >
>
>  >     Hey Ross,
>
>  >
>
>  >     I can't seem to get the Mean-mETL objective to select anything
other
>
>  >     than
>
>  >     the Min mETL portfolio using ROI.  It looks like there should be
good
>
>  >     convexity, but I think there's a substantial imbalance between the
>
>  >     size of
>
>  >     the monthly mean return and the loss indicated by the ETL.  I've
> tried
>
>  >     modifying the multiplier on the mean, but it doesn't seem to have
an
>
>  >     effect.
>
>  >
>
>  >     Any thoughts?
>
>  >
>
>  >     pcc
>
> _______________________________________________
>
> GSoC-PortA mailing list
>
> GSoC-PortA at lists.r-forge.r-project.org
> <mailto: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
>


--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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


From martinrd at comcast.net  Sun Oct  6 17:00:13 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 08:00:13 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52516748.6090605@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
Message-ID: <002d01cec2a4$c30346c0$4909d440$@comcast.net>

P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
Rglpk, with some nice examples (will send when available).   I will also use
this for the MIP examples in an advanced constraints chapter (since we don't
have a QP solver available with MIP capability, unless I can find time to do
a chapter using CPLEX via PortfolioAnalytics via ROI).

Doug 



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 6:36 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

Doug,

Per my other emails in this thread, I'd love to know how to formulate the
mean/ETL problem as an LP.

This UW dissertation is one of the early links on Google:

https://digital.lib.washington.edu/researchworks/bitstream/handle/1773/21869
/Zhang_washington_0250E_10711.pdf?sequence=1

page 26 of the document (p38 of the pdf) constructs the mean/ETL problem as
a linear programming problem.

I haven't followed it further than this, but it appears that we just need to
sort out the formulation, and we should be good.

The Cornish Fisher solution will be locally convex over much of its feasible
space.  It is often not globally convext across variations in probability
'p' (or 'alpha', though I dislike the alpha notation since alpha is such a
loaded word in finance).  It is not guaranteed to be convex, of course, and
will not be convex if skewness or kurtosis are sufficiently large and the
'p' setting is sufficiently large.

so, based on what I've been able to read this morning, it seems we just need
to get the formulation correct, and we should be able to treat mean/ETL
optimization as an LP problem.

Brian

On 10/05/2013 11:06 AM, Doug Martin wrote:
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of 
> Brian G. Peterson
> Sent: Friday, October 04, 2013 12:59 PM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?
>
> If it is an LP problem, I think you can only minimize subject to 
> constraints.
>
> */[Doug] Although I have never check this, it does not sound right.  
> The inner product in the LP formulation of ETL supports that 
> formulation of ETL as an LP, but there should be no problem to adding 
> another piece representing the inner product of mean return forecasts 
> and portfolio weights (mean portfolio return estimate).  I will check 
> it out, as I had intended to add this in the ETL chapter./*
>
> If it is a QP problem, can't you do the mean/ETL portfolio?
>
> That assumes the space is convex, which it will be for Gaussian ETL,
>
> */[Doug] But that case is not interesting, does not add value relative 
> to MVO./*
>
> *//*
>
> and may not be for modified Cornish Fisher ETL, but will be most of 
> the time, at most reasonable confidence levels.
>
> */[Doug] For both standard and modified ETL, the problem is in general 
> non-convex.  I guess you are saying from your experience the problem 
> with modified ETL usually appears to be convex.  I'm curious about how
> you ascertain that?   E.g., because on multiple runs with DeOptim you
> seldom find more than one local minimum?  That would certainly be
> reassuring./*
>
> *//*
>
> Brian
>
> On 10/04/2013 02:42 PM, Ross Bennett wrote:
>
>  > Peter,
>
>  >
>
>  > Unfortunately, with ROI we are only able to minimize ETL with ETL 
> as
>
>  > an objective. If you have mean and ETL as an objective using ROI,
>
>  > unless there is a target in the mean return objective, we just
>
>  > minimize ETL. If you have both mean and ETL as objectives, you 
> could
>
>  > add a target to the mean objective and this will minimize ETL 
> subject to the target return.
>
>  >
>
>  > We can do the following with ETL as an objective using ROI:
>
>  >   - Minimize ETL subject to leverage, box, group, exposure, position
>
>  > limit, and target return.
>
>  >
>
>  > Multipliers are ignored with ROI since the problems are formulated
>
>  > into an LP/QP problem. I'll take a look at the documentation in
>
>  > optimize.portfolio and make sure this is clear.
>
>  >
>
>  > I hope that helps clear it up.
>
>  >
>
>  > Ross
>
>  >
>
>  >
>
>  > On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com
>
>  > <mailto:peter at braverock.com>> wrote:
>
>  >
>
>  >     Hey Ross,
>
>  >
>
>  >     I can't seem to get the Mean-mETL objective to select anything
other
>
>  >     than
>
>  >     the Min mETL portfolio using ROI.  It looks like there should be
good
>
>  >     convexity, but I think there's a substantial imbalance between the
>
>  >     size of
>
>  >     the monthly mean return and the loss indicated by the ETL.  I've
> tried
>
>  >     modifying the multiplier on the mean, but it doesn't seem to have
an
>
>  >     effect.
>
>  >
>
>  >     Any thoughts?
>
>  >
>
>  >     pcc
>
> _______________________________________________
>
> GSoC-PortA mailing list
>
> GSoC-PortA at lists.r-forge.r-project.org
> <mailto: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
>


--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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


From martinrd at comcast.net  Sun Oct  6 17:00:13 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 08:00:13 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52516748.6090605@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
Message-ID: <002d01cec2a4$c30346c0$4909d440$@comcast.net>

P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
Rglpk, with some nice examples (will send when available).   I will also use
this for the MIP examples in an advanced constraints chapter (since we don't
have a QP solver available with MIP capability, unless I can find time to do
a chapter using CPLEX via PortfolioAnalytics via ROI).

Doug 



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 6:36 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

Doug,

Per my other emails in this thread, I'd love to know how to formulate the
mean/ETL problem as an LP.

This UW dissertation is one of the early links on Google:

https://digital.lib.washington.edu/researchworks/bitstream/handle/1773/21869
/Zhang_washington_0250E_10711.pdf?sequence=1

page 26 of the document (p38 of the pdf) constructs the mean/ETL problem as
a linear programming problem.

I haven't followed it further than this, but it appears that we just need to
sort out the formulation, and we should be good.

The Cornish Fisher solution will be locally convex over much of its feasible
space.  It is often not globally convext across variations in probability
'p' (or 'alpha', though I dislike the alpha notation since alpha is such a
loaded word in finance).  It is not guaranteed to be convex, of course, and
will not be convex if skewness or kurtosis are sufficiently large and the
'p' setting is sufficiently large.

so, based on what I've been able to read this morning, it seems we just need
to get the formulation correct, and we should be able to treat mean/ETL
optimization as an LP problem.

Brian

On 10/05/2013 11:06 AM, Doug Martin wrote:
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of 
> Brian G. Peterson
> Sent: Friday, October 04, 2013 12:59 PM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?
>
> If it is an LP problem, I think you can only minimize subject to 
> constraints.
>
> */[Doug] Although I have never check this, it does not sound right.  
> The inner product in the LP formulation of ETL supports that 
> formulation of ETL as an LP, but there should be no problem to adding 
> another piece representing the inner product of mean return forecasts 
> and portfolio weights (mean portfolio return estimate).  I will check 
> it out, as I had intended to add this in the ETL chapter./*
>
> If it is a QP problem, can't you do the mean/ETL portfolio?
>
> That assumes the space is convex, which it will be for Gaussian ETL,
>
> */[Doug] But that case is not interesting, does not add value relative 
> to MVO./*
>
> *//*
>
> and may not be for modified Cornish Fisher ETL, but will be most of 
> the time, at most reasonable confidence levels.
>
> */[Doug] For both standard and modified ETL, the problem is in general 
> non-convex.  I guess you are saying from your experience the problem 
> with modified ETL usually appears to be convex.  I'm curious about how
> you ascertain that?   E.g., because on multiple runs with DeOptim you
> seldom find more than one local minimum?  That would certainly be
> reassuring./*
>
> *//*
>
> Brian
>
> On 10/04/2013 02:42 PM, Ross Bennett wrote:
>
>  > Peter,
>
>  >
>
>  > Unfortunately, with ROI we are only able to minimize ETL with ETL 
> as
>
>  > an objective. If you have mean and ETL as an objective using ROI,
>
>  > unless there is a target in the mean return objective, we just
>
>  > minimize ETL. If you have both mean and ETL as objectives, you 
> could
>
>  > add a target to the mean objective and this will minimize ETL 
> subject to the target return.
>
>  >
>
>  > We can do the following with ETL as an objective using ROI:
>
>  >   - Minimize ETL subject to leverage, box, group, exposure, position
>
>  > limit, and target return.
>
>  >
>
>  > Multipliers are ignored with ROI since the problems are formulated
>
>  > into an LP/QP problem. I'll take a look at the documentation in
>
>  > optimize.portfolio and make sure this is clear.
>
>  >
>
>  > I hope that helps clear it up.
>
>  >
>
>  > Ross
>
>  >
>
>  >
>
>  > On Fri, Oct 4, 2013 at 11:49 AM, Peter Carl <peter at braverock.com
>
>  > <mailto:peter at braverock.com>> wrote:
>
>  >
>
>  >     Hey Ross,
>
>  >
>
>  >     I can't seem to get the Mean-mETL objective to select anything
other
>
>  >     than
>
>  >     the Min mETL portfolio using ROI.  It looks like there should be
good
>
>  >     convexity, but I think there's a substantial imbalance between the
>
>  >     size of
>
>  >     the monthly mean return and the loss indicated by the ETL.  I've
> tried
>
>  >     modifying the multiplier on the mean, but it doesn't seem to have
an
>
>  >     effect.
>
>  >
>
>  >     Any thoughts?
>
>  >
>
>  >     pcc
>
> _______________________________________________
>
> GSoC-PortA mailing list
>
> GSoC-PortA at lists.r-forge.r-project.org
> <mailto: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
>


--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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


From brian at braverock.com  Sun Oct  6 17:18:47 2013
From: brian at braverock.com (Brian G. Peterson)
Date: Sun, 06 Oct 2013 10:18:47 -0500
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <002d01cec2a4$c30346c0$4909d440$@comcast.net>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
Message-ID: <52517F57.7060902@braverock.com>

On 10/06/2013 10:00 AM, Doug Martin wrote:
> P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> Rglpk, with some nice examples (will send when available).   I will also use
> this for the MIP examples in an advanced constraints chapter (since we don't
> have a QP solver available with MIP capability, unless I can find time to do
> a chapter using CPLEX via PortfolioAnalytics via ROI).

there is also a ROI front end to the MILP Symphony solver.

I'm not sure iof the Symphony solver includes QP constraints.

-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock

From martinrd at comcast.net  Sun Oct  6 17:44:41 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 08:44:41 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52517F57.7060902@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
 <52517F57.7060902@braverock.com>
Message-ID: <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>

Will need to do an in-depth comparison of Rglpk versus Symphony LP (withMIP)
solvers.

I think you mentioned a project for evaluating the various solvers against
commonly used benchmark problems? What is the status and timing of that?

Doug



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 8:19 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

On 10/06/2013 10:00 AM, Doug Martin wrote:
> P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> Rglpk, with some nice examples (will send when available).   I will also
use
> this for the MIP examples in an advanced constraints chapter (since we 
> don't have a QP solver available with MIP capability, unless I can 
> find time to do a chapter using CPLEX via PortfolioAnalytics via ROI).

there is also a ROI front end to the MILP Symphony solver.

I'm not sure iof the Symphony solver includes QP constraints.

--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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


From martinrd at comcast.net  Sun Oct  6 17:44:41 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 08:44:41 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <52517F57.7060902@braverock.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
 <52517F57.7060902@braverock.com>
Message-ID: <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>

Will need to do an in-depth comparison of Rglpk versus Symphony LP (withMIP)
solvers.

I think you mentioned a project for evaluating the various solvers against
commonly used benchmark problems? What is the status and timing of that?

Doug



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Sunday, October 06, 2013 8:19 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

On 10/06/2013 10:00 AM, Doug Martin wrote:
> P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> Rglpk, with some nice examples (will send when available).   I will also
use
> this for the MIP examples in an advanced constraints chapter (since we 
> don't have a QP solver available with MIP capability, unless I can 
> find time to do a chapter using CPLEX via PortfolioAnalytics via ROI).

there is also a ROI front end to the MILP Symphony solver.

I'm not sure iof the Symphony solver includes QP constraints.

--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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


From rossbennett34 at gmail.com  Mon Oct  7 02:55:34 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Sun, 6 Oct 2013 17:55:34 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
 <52517F57.7060902@braverock.com>
 <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>
Message-ID: <CAEESW=XAhH6dQY4S0Zzr-2Mr5CjwF=wJ0UQ+rRstB80jZocUqA@mail.gmail.com>

It will be nice if there is a simple way to formulate this as an LP problem
to maximize mean/ETL. If there is not a simple formulation, one way to
approach this would be similar to finding the tangency portfolio on the
efficient frontier. Generating a finite number of portfolios along the
frontier and finding the portfolio with the highest mean/ETL will find the
approximate tangency portfolio and is what I do for the efficient frontier
code.

Step 1: Calculate the minimum ETL portfolio given the constraints. This is
the minimum possible mean return.

Step 2: Calculate the maximum return portfolio given the constraints. This
is the maximum possible mean return.

Step 3: Increase or decrease the target return constraint and run the
optimization.

Repeat step 3 until we get convergence within a specified tolerance or
reach the maximum number of iterations.

I'm not sure what the right approach or method would be for step 3. Maybe
split the frontier in two equal spaces and iteratively shrink the search
space until we find a solution.

Am I on the right track here? Any thoughts on how to do step 3?

Thanks,
Ross


On Sun, Oct 6, 2013 at 8:44 AM, Doug Martin <martinrd at comcast.net> wrote:

> Will need to do an in-depth comparison of Rglpk versus Symphony LP
> (withMIP)
> solvers.
>
> I think you mentioned a project for evaluating the various solvers against
> commonly used benchmark problems? What is the status and timing of that?
>
> Doug
>
>
>
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
> G. Peterson
> Sent: Sunday, October 06, 2013 8:19 AM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?
>
> On 10/06/2013 10:00 AM, Doug Martin wrote:
> > P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> > Rglpk, with some nice examples (will send when available).   I will also
> use
> > this for the MIP examples in an advanced constraints chapter (since we
> > don't have a QP solver available with MIP capability, unless I can
> > find time to do a chapter using CPLEX via PortfolioAnalytics via ROI).
>
> there is also a ROI front end to the MILP Symphony solver.
>
> I'm not sure iof the Symphony solver includes QP constraints.
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
> _______________________________________________
> 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/20131006/3dc7c1c8/attachment-0001.html>

From peter at braverock.com  Mon Oct  7 02:57:35 2013
From: peter at braverock.com (Peter Carl)
Date: Sun, 6 Oct 2013 19:57:35 -0500
Subject: [GSoC-PortA] Missing extractWeights.rebal?
Message-ID: <6adfae52b2949996ec1551c60caa503f.squirrel@mail.braverock.com>

> EqmETL.w = extractWeights.rebal(EqmETL.DE.t)
Error: could not find function "extractWeights.rebal"

This function was used for extracting and combining weights from a run
using optimize.portfolio.rebalancing, which still works.

Anyone know where it went?

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



From rossbennett34 at gmail.com  Mon Oct  7 03:01:09 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Sun, 6 Oct 2013 18:01:09 -0700
Subject: [GSoC-PortA] Missing extractWeights.rebal?
In-Reply-To: <6adfae52b2949996ec1551c60caa503f.squirrel@mail.braverock.com>
References: <6adfae52b2949996ec1551c60caa503f.squirrel@mail.braverock.com>
Message-ID: <CAEESW=WxNb3eQoLgffL1SathdP6mduFzqAnfu=TOp5tHxrEFhQ@mail.gmail.com>

I made extractWeights a method for optimize.portfolio.rebalancing objects.

extractWeights(EqmETL.DE.t) should do the trick.

Ross


On Sun, Oct 6, 2013 at 5:57 PM, Peter Carl <peter at braverock.com> wrote:

> > EqmETL.w = extractWeights.rebal(EqmETL.DE.t)
> Error: could not find function "extractWeights.rebal"
>
> This function was used for extracting and combining weights from a run
> using optimize.portfolio.rebalancing, which still works.
>
> Anyone know where it went?
>
> pcc
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131006/cfb33c9d/attachment.html>

From martinrd at comcast.net  Mon Oct  7 03:11:36 2013
From: martinrd at comcast.net (Doug Martin)
Date: Sun, 6 Oct 2013 18:11:36 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <CAEESW=XAhH6dQY4S0Zzr-2Mr5CjwF=wJ0UQ+rRstB80jZocUqA@mail.gmail.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
 <52517F57.7060902@braverock.com>
 <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>
 <CAEESW=XAhH6dQY4S0Zzr-2Mr5CjwF=wJ0UQ+rRstB80jZocUqA@mail.gmail.com>
Message-ID: <005f01cec2fa$2bf126c0$83d37440$@comcast.net>

Maybe I'm missing something, and you are concerned about something more than
just mean-ETL optimization, i.e., using random portfolios or DeOptim due to
constraints???     

 

As for the STARR ratio Step 3 is fine, and can also be used for max Sharpe
ratio.  As long as the efficient frontier is concave  both ratios increase
until the maximum and then decrease, so a simple line search will work and
converge pretty rapidly.  I have a placeholder for a max SR section in
Chapter 2 and will do soon.  

 

Am I missing something?

 

Doug

 

 

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Sunday, October 06, 2013 5:56 PM
To: PortfolioAnalytics
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

It will be nice if there is a simple way to formulate this as an LP problem
to maximize mean/ETL. If there is not a simple formulation, one way to
approach this would be similar to finding the tangency portfolio on the
efficient frontier. Generating a finite number of portfolios along the
frontier and finding the portfolio with the highest mean/ETL will find the
approximate tangency portfolio and is what I do for the efficient frontier
code.

 

Step 1: Calculate the minimum ETL portfolio given the constraints. This is
the minimum possible mean return.

 

Step 2: Calculate the maximum return portfolio given the constraints. This
is the maximum possible mean return.

 

Step 3: Increase or decrease the target return constraint and run the
optimization.

 

Repeat step 3 until we get convergence within a specified tolerance or reach
the maximum number of iterations.

 

I'm not sure what the right approach or method would be for step 3. Maybe
split the frontier in two equal spaces and iteratively shrink the search
space until we find a solution. 

 

Am I on the right track here? Any thoughts on how to do step 3?

 

Thanks,

Ross

 

On Sun, Oct 6, 2013 at 8:44 AM, Doug Martin <martinrd at comcast.net> wrote:

Will need to do an in-depth comparison of Rglpk versus Symphony LP (withMIP)
solvers.

I think you mentioned a project for evaluating the various solvers against
commonly used benchmark problems? What is the status and timing of that?


Doug



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson

Sent: Sunday, October 06, 2013 8:19 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

On 10/06/2013 10:00 AM, Doug Martin wrote:
> P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> Rglpk, with some nice examples (will send when available).   I will also
use
> this for the MIP examples in an advanced constraints chapter (since we
> don't have a QP solver available with MIP capability, unless I can
> find time to do a chapter using CPLEX via PortfolioAnalytics via ROI).

there is also a ROI front end to the MILP Symphony solver.

I'm not sure iof the Symphony solver includes QP constraints.

--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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/20131006/63c231fa/attachment.html>

From peter at braverock.com  Mon Oct  7 03:25:26 2013
From: peter at braverock.com (Peter Carl)
Date: Sun, 6 Oct 2013 20:25:26 -0500
Subject: [GSoC-PortA] Volatility weighted benchmark constructor
Message-ID: <98bb178de78433cb5f984d0fa1eabcb1.squirrel@mail.braverock.com>

Ross,

I mimicked your equal-weight constructor to create an "inverse volatility"
benchmark.  I see this used more frequently in managed futures trading,
where the position is proportioned as one over the volatility of the
asset.

In effect, this gives an interesting metric relative to the equal standard
deviation portfolio, and is a special case where the covariance matrix is
homogeneous. When comparing the two, the inverse volatility benchmark
allows you to ask the question of how much information about sizing is in
the covariance assumptions, relative to that in the volatility
assumptions.  I think it's useful for making that tradeoff between
volatility and correlation much more explicit.

There may be another, more formal name.  Usually we just refer to it as
"volatility weighted" as being similar to "equal weighted".

### Construct BUOY 8: Volatility Weighted Portfolio
# There's only one, so create a portfolio object with all the objectives
we want calculated.
VolWgt.portf <- portfolio.spec(assets=colnames(R))
VolWgt.portf <- add.constraint(portfolio=VolWgt.portf, type="leverage",
min_sum=0.99, max_sum=1.01)
VolWgt.portf <- add.objective(portfolio=VolWgt.portf, type="return",
name="mean")
VolWgt.portf <- add.objective(portfolio=VolWgt.portf, type="risk_budget",
name="ES", arguments=list(p=p, clean=clean))
VolWgt.portf <- add.objective(portfolio=VolWgt.portf, type="risk_budget",
name="StdDev", arguments=list(clean=clean))

### Evaluate BUOY 8: Inverse Volatility Portfolio
inverse.volatility <- function (R, portfolio, ...)
{
  if (!is.portfolio(portfolio))
      stop("portfolio object passed in must be of class 'portfolio'")
  assets <- portfolio$assets
  nassets <- length(assets)
  weights <- as.vector((1/StdDev(R))/sum(1/StdDev(R)))
  names(weights) <- names(assets)
  if (ncol(R) != nassets) {
      if (ncol(R) > nassets) {
          R <- R[, 1:nassets]
          warning("number of assets is less than number of columns in
returns object, subsetting returns object.")
      }
      else {
          stop("number of assets is greater than number of columns in
returns object")
      }
  }
  out <- constrained_objective(w = weights, R = R, portfolio = portfolio,
      trace = TRUE, ...)$objective_measures
  return(structure(list(R = R, weights = weights, objective_measures = out,
      call = match.call(), portfolio = portfolio), class =
c("optimize.portfolio.invol",
      "optimize.portfolio")))
}

# Calculate the objective measures for the vol weight portfolio
VolWgt.opt <- volatility.weight(R=R, portfolio=VolWgt.portf)

At any rate, I think it probably makes sense to include alongside the
equal weight function as another special case.  Let me know what you
think.

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



From rossbennett34 at gmail.com  Mon Oct  7 17:30:29 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Mon, 7 Oct 2013 08:30:29 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <005f01cec2fa$2bf126c0$83d37440$@comcast.net>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
 <52517F57.7060902@braverock.com>
 <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>
 <CAEESW=XAhH6dQY4S0Zzr-2Mr5CjwF=wJ0UQ+rRstB80jZocUqA@mail.gmail.com>
 <005f01cec2fa$2bf126c0$83d37440$@comcast.net>
Message-ID: <CAEESW=VyV00bxhmB=SAzzHF8p8Mh+kysH65HGs8j7PZWW2JtZw@mail.gmail.com>

Doug,

I don't think you were missing anything, perhaps I misunderstood. From
previous emails in this thread, I thought that there was a way to formulate
the mean/ETL as an LP problem that would avoid having to do a search for
the maximum mean/ETL portfolio. There is no need to do this for DEoptim or
random portfolios, I was just referring to maximizing mean/ETL using ROI.

I implemented this as of commit r3212. If mean and ETL (also ES or CVaR)
are objectives and optimize_method="ROI", the optimal portfolio returned is
one that maximizes mean/ETL. I use a bisection search to find the portfolio
that maximizes mean/ETL.

Ross



On Sun, Oct 6, 2013 at 6:11 PM, Doug Martin <martinrd at comcast.net> wrote:

> Maybe I?m missing something, and you are concerned about something more
> than just mean-ETL optimization, i.e., using random portfolios or DeOptim
> due to constraints???     ****
>
> ** **
>
> As for the STARR ratio Step 3 is fine, and can also be used for max Sharpe
> ratio.  As long as the efficient frontier is concave  both ratios increase
> until the maximum and then decrease, so a simple line search will work and
> converge pretty rapidly.  I have a placeholder for a max SR section in
> Chapter 2 and will do soon.  ****
>
> ** **
>
> Am I missing something?****
>
> ** **
>
> Doug****
>
> ** **
>
> ** **
>
> *From:* gsoc-porta-bounces at lists.r-forge.r-project.org [mailto:
> gsoc-porta-bounces at lists.r-forge.r-project.org] *On Behalf Of *Ross
> Bennett
> *Sent:* Sunday, October 06, 2013 5:56 PM
> *To:* PortfolioAnalytics
>
> *Subject:* Re: [GSoC-PortA] Mean-mETL objective?****
>
> ** **
>
> It will be nice if there is a simple way to formulate this as an LP
> problem to maximize mean/ETL. If there is not a simple formulation, one way
> to approach this would be similar to finding the tangency portfolio on the
> efficient frontier. Generating a finite number of portfolios along the
> frontier and finding the portfolio with the highest mean/ETL will find the
> approximate tangency portfolio and is what I do for the efficient frontier
> code.****
>
> ** **
>
> Step 1: Calculate the minimum ETL portfolio given the constraints. This is
> the minimum possible mean return.****
>
> ** **
>
> Step 2: Calculate the maximum return portfolio given the constraints. This
> is the maximum possible mean return.****
>
> ** **
>
> Step 3: Increase or decrease the target return constraint and run the
> optimization.****
>
> ** **
>
> Repeat step 3 until we get convergence within a specified tolerance or
> reach the maximum number of iterations.****
>
> ** **
>
> I'm not sure what the right approach or method would be for step 3. Maybe
> split the frontier in two equal spaces and iteratively shrink the search
> space until we find a solution. ****
>
> ** **
>
> Am I on the right track here? Any thoughts on how to do step 3?****
>
> ** **
>
> Thanks,****
>
> Ross****
>
> ** **
>
> On Sun, Oct 6, 2013 at 8:44 AM, Doug Martin <martinrd at comcast.net> wrote:*
> ***
>
> Will need to do an in-depth comparison of Rglpk versus Symphony LP
> (withMIP)
> solvers.
>
> I think you mentioned a project for evaluating the various solvers against
> commonly used benchmark problems? What is the status and timing of that?**
> **
>
>
> Doug
>
>
>
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
> G. Peterson****
>
> Sent: Sunday, October 06, 2013 8:19 AM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?****
>
> On 10/06/2013 10:00 AM, Doug Martin wrote:
> > P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> > Rglpk, with some nice examples (will send when available).   I will also
> use
> > this for the MIP examples in an advanced constraints chapter (since we
> > don't have a QP solver available with MIP capability, unless I can
> > find time to do a chapter using CPLEX via PortfolioAnalytics via ROI).
>
> there is also a ROI front end to the MILP Symphony solver.
>
> I'm not sure iof the Symphony solver includes QP constraints.
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
> _______________________________________________
> 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/20131007/3e4ce72b/attachment.html>

From martinrd at comcast.net  Mon Oct  7 17:51:48 2013
From: martinrd at comcast.net (Doug Martin)
Date: Mon, 7 Oct 2013 08:51:48 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <CAEESW=VyV00bxhmB=SAzzHF8p8Mh+kysH65HGs8j7PZWW2JtZw@mail.gmail.com>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
 <52517F57.7060902@braverock.com>
 <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>
 <CAEESW=XAhH6dQY4S0Zzr-2Mr5CjwF=wJ0UQ+rRstB80jZocUqA@mail.gmail.com>
 <005f01cec2fa$2bf126c0$83d37440$@comcast.net>
 <CAEESW=VyV00bxhmB=SAzzHF8p8Mh+kysH65HGs8j7PZWW2JtZw@mail.gmail.com>
Message-ID: <007f01cec375$220388d0$660a9a70$@comcast.net>

Ross,

 

OK, I see what you mean.   Do keep in mind the following:

 

1)      Before a search is done the code should check that the mean return
of the global minimum ETL (under constraints) - I call this GMETL is less
than the risk free rate (which may be zero by default).  Otherwise the
search is useless as there is no tangent portfolio (well I have to be a
little careful, this is definitely the case for the MVO efficient frontier
without constraints and most likely with most constraints, and ditto for the
mean-ETL efficient frontier).  By this ratio is known as the STARR ratio in
the literature.

 

2)      If in your second paragraph do you mean that is the default
behavior?  If so there should be a default argument whose default is
"maxSTARR", but the user should also be able to choose GMETL.

 

Doug

 

 

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Monday, October 07, 2013 8:30 AM
To: PortfolioAnalytics
Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

Doug,

 

I don't think you were missing anything, perhaps I misunderstood. From
previous emails in this thread, I thought that there was a way to formulate
the mean/ETL as an LP problem that would avoid having to do a search for the
maximum mean/ETL portfolio. There is no need to do this for DEoptim or
random portfolios, I was just referring to maximizing mean/ETL using ROI. 

 

I implemented this as of commit r3212. If mean and ETL (also ES or CVaR) are
objectives and optimize_method="ROI", the optimal portfolio returned is one
that maximizes mean/ETL. I use a bisection search to find the portfolio that
maximizes mean/ETL.

 

Ross

 

 

On Sun, Oct 6, 2013 at 6:11 PM, Doug Martin <martinrd at comcast.net> wrote:

Maybe I'm missing something, and you are concerned about something more than
just mean-ETL optimization, i.e., using random portfolios or DeOptim due to
constraints???     

 

As for the STARR ratio Step 3 is fine, and can also be used for max Sharpe
ratio.  As long as the efficient frontier is concave  both ratios increase
until the maximum and then decrease, so a simple line search will work and
converge pretty rapidly.  I have a placeholder for a max SR section in
Chapter 2 and will do soon.  

 

Am I missing something?

 

Doug

 

 

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Sunday, October 06, 2013 5:56 PM
To: PortfolioAnalytics


Subject: Re: [GSoC-PortA] Mean-mETL objective?

 

It will be nice if there is a simple way to formulate this as an LP problem
to maximize mean/ETL. If there is not a simple formulation, one way to
approach this would be similar to finding the tangency portfolio on the
efficient frontier. Generating a finite number of portfolios along the
frontier and finding the portfolio with the highest mean/ETL will find the
approximate tangency portfolio and is what I do for the efficient frontier
code.

 

Step 1: Calculate the minimum ETL portfolio given the constraints. This is
the minimum possible mean return.

 

Step 2: Calculate the maximum return portfolio given the constraints. This
is the maximum possible mean return.

 

Step 3: Increase or decrease the target return constraint and run the
optimization.

 

Repeat step 3 until we get convergence within a specified tolerance or reach
the maximum number of iterations.

 

I'm not sure what the right approach or method would be for step 3. Maybe
split the frontier in two equal spaces and iteratively shrink the search
space until we find a solution. 

 

Am I on the right track here? Any thoughts on how to do step 3?

 

Thanks,

Ross

 

On Sun, Oct 6, 2013 at 8:44 AM, Doug Martin <martinrd at comcast.net> wrote:

Will need to do an in-depth comparison of Rglpk versus Symphony LP (withMIP)
solvers.

I think you mentioned a project for evaluating the various solvers against
commonly used benchmark problems? What is the status and timing of that?


Doug



-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson

Sent: Sunday, October 06, 2013 8:19 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] Mean-mETL objective?

On 10/06/2013 10:00 AM, Doug Martin wrote:
> P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> Rglpk, with some nice examples (will send when available).   I will also
use
> this for the MIP examples in an advanced constraints chapter (since we
> don't have a QP solver available with MIP capability, unless I can
> find time to do a chapter using CPLEX via PortfolioAnalytics via ROI).

there is also a ROI front end to the MILP Symphony solver.

I'm not sure iof the Symphony solver includes QP constraints.

--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
_______________________________________________
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/20131007/42926129/attachment-0001.html>

From rossbennett34 at gmail.com  Mon Oct  7 21:02:19 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Mon, 7 Oct 2013 12:02:19 -0700
Subject: [GSoC-PortA] Mean-mETL objective?
In-Reply-To: <007f01cec375$220388d0$660a9a70$@comcast.net>
References: <f1c1a9938b4a819c399bad7ac3f077ef.squirrel@mail.braverock.com>
 <CAEESW=VQVhiiWL0RPrgwFQHORs9UKES5Jeja-hCbvg++9zRCPA@mail.gmail.com>
 <524F1DE8.9030301@braverock.com>
 <008f01cec1e4$ebd608a0$c38219e0$@comcast.net>
 <52516748.6090605@braverock.com>
 <002d01cec2a4$c30346c0$4909d440$@comcast.net>
 <52517F57.7060902@braverock.com>
 <003801cec2aa$f99f2b30$ecdd8190$@comcast.net>
 <CAEESW=XAhH6dQY4S0Zzr-2Mr5CjwF=wJ0UQ+rRstB80jZocUqA@mail.gmail.com>
 <005f01cec2fa$2bf126c0$83d37440$@comcast.net>
 <CAEESW=VyV00bxhmB=SAzzHF8p8Mh+kysH65HGs8j7PZWW2JtZw@mail.gmail.com>
 <007f01cec375$220388d0$660a9a70$@comcast.net>
Message-ID: <CAEESW=UNaNPcGE3_gi-woFzRq0tMgZMpzSM6Y30cNsR0BCDMDw@mail.gmail.com>

see comments inline


On Mon, Oct 7, 2013 at 8:51 AM, Doug Martin <martinrd at comcast.net> wrote:

> Ross,****
>
> ** **
>
> OK, I see what you mean.   Do keep in mind the following:****
>
> ** **
>
> **1)      **Before a search is done the code should check that the mean
> return of the global minimum ETL (under constraints) ? I call this GMETL is
> less than the risk free rate (which may be zero by default).  Otherwise the
> search is useless as there is no tangent portfolio (well I have to be a
> little careful, this is definitely the case for the MVO efficient frontier
> without constraints and most likely with most constraints, and ditto for
> the mean-ETL efficient frontier).  By this ratio is known as the STARR
> ratio in the literature.
>
 Thanks for the suggestion, I'll add the check. To clarify, I think you
mean that the mean return of the GMETL portfolio should be greater than the
risk-free rate, correct?

> ****
>
> ** **
>
> **2)      **If in your second paragraph do you mean that is the default
> behavior?  If so there should be a default argument whose default is
> ?maxSTARR?, but the user should also be able to choose GMETL.
>
 Correct. If the portfolio has two objectives, mean and ES, then the
optimal portfolio will be the max STARR portfolio. If the user just wants
the GMETL portfolio, the portfolio should only have a single objective for
ETL.

I did make it possible to pass in maxSTARR=TRUE or maxSTARR=FALSE in the
dots in optimize.portfolio. I did the same for max sharpe ratio (maxSR).
This is important to have for the quadratic utility case because the user
may want to specify a risk_aversion parameter and get the optimal portfolio
at the given risk_aversion parameter. Setting maxSR=TRUE would override any
risk_aversion parameter and find the max sharpe ratio portfolio, so I made
maxSR=FALSE the default.

> ****
>
> ** **
>
> Doug****
>
> ** **
>
> ** **
>
> *From:* gsoc-porta-bounces at lists.r-forge.r-project.org [mailto:
> gsoc-porta-bounces at lists.r-forge.r-project.org] *On Behalf Of *Ross
> Bennett
> *Sent:* Monday, October 07, 2013 8:30 AM
>
> *To:* PortfolioAnalytics
> *Subject:* Re: [GSoC-PortA] Mean-mETL objective?****
>
> ** **
>
> Doug,****
>
> ** **
>
> I don't think you were missing anything, perhaps I misunderstood. From
> previous emails in this thread, I thought that there was a way to formulate
> the mean/ETL as an LP problem that would avoid having to do a search for
> the maximum mean/ETL portfolio. There is no need to do this for DEoptim or
> random portfolios, I was just referring to maximizing mean/ETL using ROI.
> ****
>
> ** **
>
> I implemented this as of commit r3212. If mean and ETL (also ES or CVaR)
> are objectives and optimize_method="ROI", the optimal portfolio returned is
> one that maximizes mean/ETL. I use a bisection search to find the portfolio
> that maximizes mean/ETL.****
>
> ** **
>
> Ross****
>
> ** **
>
> ** **
>
> On Sun, Oct 6, 2013 at 6:11 PM, Doug Martin <martinrd at comcast.net> wrote:*
> ***
>
> Maybe I?m missing something, and you are concerned about something more
> than just mean-ETL optimization, i.e., using random portfolios or DeOptim
> due to constraints???     ****
>
>  ****
>
> As for the STARR ratio Step 3 is fine, and can also be used for max Sharpe
> ratio.  As long as the efficient frontier is concave  both ratios increase
> until the maximum and then decrease, so a simple line search will work and
> converge pretty rapidly.  I have a placeholder for a max SR section in
> Chapter 2 and will do soon.  ****
>
>  ****
>
> Am I missing something?****
>
>  ****
>
> Doug****
>
>  ****
>
>  ****
>
> *From:* gsoc-porta-bounces at lists.r-forge.r-project.org [mailto:
> gsoc-porta-bounces at lists.r-forge.r-project.org] *On Behalf Of *Ross
> Bennett
> *Sent:* Sunday, October 06, 2013 5:56 PM
> *To:* PortfolioAnalytics****
>
>
> *Subject:* Re: [GSoC-PortA] Mean-mETL objective?****
>
>  ****
>
> It will be nice if there is a simple way to formulate this as an LP
> problem to maximize mean/ETL. If there is not a simple formulation, one way
> to approach this would be similar to finding the tangency portfolio on the
> efficient frontier. Generating a finite number of portfolios along the
> frontier and finding the portfolio with the highest mean/ETL will find the
> approximate tangency portfolio and is what I do for the efficient frontier
> code.****
>
>  ****
>
> Step 1: Calculate the minimum ETL portfolio given the constraints. This is
> the minimum possible mean return.****
>
>  ****
>
> Step 2: Calculate the maximum return portfolio given the constraints. This
> is the maximum possible mean return.****
>
>  ****
>
> Step 3: Increase or decrease the target return constraint and run the
> optimization.****
>
>  ****
>
> Repeat step 3 until we get convergence within a specified tolerance or
> reach the maximum number of iterations.****
>
>  ****
>
> I'm not sure what the right approach or method would be for step 3. Maybe
> split the frontier in two equal spaces and iteratively shrink the search
> space until we find a solution. ****
>
>  ****
>
> Am I on the right track here? Any thoughts on how to do step 3?****
>
>  ****
>
> Thanks,****
>
> Ross****
>
>  ****
>
> On Sun, Oct 6, 2013 at 8:44 AM, Doug Martin <martinrd at comcast.net> wrote:*
> ***
>
> Will need to do an in-depth comparison of Rglpk versus Symphony LP
> (withMIP)
> solvers.
>
> I think you mentioned a project for evaluating the various solvers against
> commonly used benchmark problems? What is the status and timing of that?**
> **
>
>
> Doug
>
>
>
> -----Original Message-----
> From: gsoc-porta-bounces at lists.r-forge.r-project.org
> [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
> G. Peterson****
>
> Sent: Sunday, October 06, 2013 8:19 AM
> To: gsoc-porta at r-forge.wu-wien.ac.at
> Subject: Re: [GSoC-PortA] Mean-mETL objective?****
>
> On 10/06/2013 10:00 AM, Doug Martin wrote:
> > P.S. Chapter 4 in the 2nd edition on mean-ETL optimization via LP with
> > Rglpk, with some nice examples (will send when available).   I will also
> use
> > this for the MIP examples in an advanced constraints chapter (since we
> > don't have a QP solver available with MIP capability, unless I can
> > find time to do a chapter using CPLEX via PortfolioAnalytics via ROI).
>
> there is also a ROI front end to the MILP Symphony solver.
>
> I'm not sure iof the Symphony solver includes QP constraints.
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
> _______________________________________________
> 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/20131007/dba7bbde/attachment.html>

From rossbennett34 at gmail.com  Mon Oct  7 21:12:23 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Mon, 7 Oct 2013 12:12:23 -0700
Subject: [GSoC-PortA] Volatility weighted benchmark constructor
In-Reply-To: <98bb178de78433cb5f984d0fa1eabcb1.squirrel@mail.braverock.com>
References: <98bb178de78433cb5f984d0fa1eabcb1.squirrel@mail.braverock.com>
Message-ID: <CAEESW=X5cvQpDsntiM4EQM+Odk1_0cCddXKMy_AysJkwnw3F=A@mail.gmail.com>

Peter,

Thanks for sharing. I think it would be great to include the volatility
weighted like we have the equal weight portfolio. I will work on adding
that.

Thanks,
Ross


On Sun, Oct 6, 2013 at 6:25 PM, Peter Carl <peter at braverock.com> wrote:

> Ross,
>
> I mimicked your equal-weight constructor to create an "inverse volatility"
> benchmark.  I see this used more frequently in managed futures trading,
> where the position is proportioned as one over the volatility of the
> asset.
>
> In effect, this gives an interesting metric relative to the equal standard
> deviation portfolio, and is a special case where the covariance matrix is
> homogeneous. When comparing the two, the inverse volatility benchmark
> allows you to ask the question of how much information about sizing is in
> the covariance assumptions, relative to that in the volatility
> assumptions.  I think it's useful for making that tradeoff between
> volatility and correlation much more explicit.
>
> There may be another, more formal name.  Usually we just refer to it as
> "volatility weighted" as being similar to "equal weighted".
>
> ### Construct BUOY 8: Volatility Weighted Portfolio
> # There's only one, so create a portfolio object with all the objectives
> we want calculated.
> VolWgt.portf <- portfolio.spec(assets=colnames(R))
> VolWgt.portf <- add.constraint(portfolio=VolWgt.portf, type="leverage",
> min_sum=0.99, max_sum=1.01)
> VolWgt.portf <- add.objective(portfolio=VolWgt.portf, type="return",
> name="mean")
> VolWgt.portf <- add.objective(portfolio=VolWgt.portf, type="risk_budget",
> name="ES", arguments=list(p=p, clean=clean))
> VolWgt.portf <- add.objective(portfolio=VolWgt.portf, type="risk_budget",
> name="StdDev", arguments=list(clean=clean))
>
> ### Evaluate BUOY 8: Inverse Volatility Portfolio
> inverse.volatility <- function (R, portfolio, ...)
> {
>   if (!is.portfolio(portfolio))
>       stop("portfolio object passed in must be of class 'portfolio'")
>   assets <- portfolio$assets
>   nassets <- length(assets)
>   weights <- as.vector((1/StdDev(R))/sum(1/StdDev(R)))
>   names(weights) <- names(assets)
>   if (ncol(R) != nassets) {
>       if (ncol(R) > nassets) {
>           R <- R[, 1:nassets]
>           warning("number of assets is less than number of columns in
> returns object, subsetting returns object.")
>       }
>       else {
>           stop("number of assets is greater than number of columns in
> returns object")
>       }
>   }
>   out <- constrained_objective(w = weights, R = R, portfolio = portfolio,
>       trace = TRUE, ...)$objective_measures
>   return(structure(list(R = R, weights = weights, objective_measures = out,
>       call = match.call(), portfolio = portfolio), class =
> c("optimize.portfolio.invol",
>       "optimize.portfolio")))
> }
>
> # Calculate the objective measures for the vol weight portfolio
> VolWgt.opt <- volatility.weight(R=R, portfolio=VolWgt.portf)
>
> At any rate, I think it probably makes sense to include alongside the
> equal weight function as another special case.  Let me know what you
> think.
>
> pcc
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131007/1e4be1b5/attachment-0001.html>

From peter at braverock.com  Tue Oct  8 23:26:03 2013
From: peter at braverock.com (Peter Carl)
Date: Tue, 8 Oct 2013 16:26:03 -0500
Subject: [GSoC-PortA] Excel solver for %Contrib SD
Message-ID: <fdca5431d1cec15f6bb451fe86318cd1.squirrel@mail.braverock.com>

Here's how I use Excel to solve for percent contribution to SD.  This
makes me think that there should be a way to transcribe that objective
into a closed form optimizer as well...

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: Component Contribution EDHEC 2012-07f.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 83223 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131008/a8d978fe/attachment-0001.xlsx>

From peter at braverock.com  Wed Oct  9 22:38:12 2013
From: peter at braverock.com (Peter Carl)
Date: Wed, 9 Oct 2013 15:38:12 -0500
Subject: [GSoC-PortA] Issue passing "clean"?
Message-ID: <aa2d3a80ec953b254453df56c80c80e5.squirrel@mail.braverock.com>

Ross,

I'm running into the following:

> buoys.portfmeas
                Mean      StdDev       mETL
MinSD    0.005435103 0.009286484 0.01357282
MinmETL  0.005846839 0.011196709 0.01371471

Note that the minimum standard deviation portfolio has a lower mETL than
the Min mETL portfolio.  Both were calculated with ROI.

MinSD.portf <- add.objective(portfolio=init.portf,
  type="risk", # the kind of objective this is
  name="var", # name of the function
  arguments=list(clean=clean)
)

> MinSD.ROI<-optimize.portfolio(R=R,
+   portfolio=MinSD.portf,
+   optimize_method='ROI'
+   )
Warning message:
In constrained_objective(w = weights, R = R, portfolio, trace = TRUE,  :
  some arguments stored for var do not match

That warning is true, "var" doesn't take that list of arguments, including
"clean".  But when I use name="StdDev" in the portfolio construction, I
get the following error:

Error in optimize.portfolio(R = R, portfolio = MinSD.portf,
optimize_method = "ROI") :
  ROI only solves mean, var, or sample ETL/ES/CVaR type business
objectives, choose a different optimize_method.
In addition: Warning message:
In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'

So the first issue is to map "StdDev" into the list of acceptable
functions for that solver.  It should then accept the "clean" argument and
that should fix part of the issue.

The second issue is that the Min mETL portfolio being identified isn't
being plotted as the minimum mETL portfolio being identified in the cloud
of random portfolios.  This is the same issue I saw earlier that turned
out to be related to "clean" not being applied consistently across
objectives.

In this case, it should be:
p=1-1/12
clean="boudt"
MinmETL.portf <- add.objective(portfolio=init.portf,
  type="risk", # the kind of objective this is
  name="ES", # the function to minimize
  arguments=list(p=p, clean=clean)
)

> MinmETL.ROI<-optimize.portfolio(R=R,
+   portfolio=MinmETL.portf,
+   optimize_method='ROI',
+   trace=TRUE, verbose=TRUE
+   )
Warning message:
In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'

I'm not sure if the warning is related.  But I'm wondering if "clean" is
getting passed into "ES" with ROI.  If it isn't, then the optimizer is
likely selecting the wrong portfolio.  Could you take a look at this when
you have a moment?

Thanks,

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



From rossbennett34 at gmail.com  Thu Oct 10 00:20:16 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Wed, 9 Oct 2013 15:20:16 -0700
Subject: [GSoC-PortA] Issue passing "clean"?
In-Reply-To: <aa2d3a80ec953b254453df56c80c80e5.squirrel@mail.braverock.com>
References: <aa2d3a80ec953b254453df56c80c80e5.squirrel@mail.braverock.com>
Message-ID: <CAEESW=VfadZUR_A2a8x5fquzjzn7C7jvMbQsA_1-E5zNCub=8A@mail.gmail.com>

Peter,

Thanks for the detailed description of what is going on. I will be able to
dig into this deeper tomorrow afternoon, but here are some initial comments.

See comments in-line.



On Wed, Oct 9, 2013 at 1:38 PM, Peter Carl <peter at braverock.com> wrote:

> Ross,
>
> I'm running into the following:
>
> > buoys.portfmeas
>                 Mean      StdDev       mETL
> MinSD    0.005435103 0.009286484 0.01357282
> MinmETL  0.005846839 0.011196709 0.01371471
>
> Note that the minimum standard deviation portfolio has a lower mETL than
> the Min mETL portfolio.  Both were calculated with ROI.
>
> MinSD.portf <- add.objective(portfolio=init.portf,
>   type="risk", # the kind of objective this is
>   name="var", # name of the function
>   arguments=list(clean=clean)
> )
>
> > MinSD.ROI<-optimize.portfolio(R=R,
> +   portfolio=MinSD.portf,
> +   optimize_method='ROI'
> +   )
> Warning message:
> In constrained_objective(w = weights, R = R, portfolio, trace = TRUE,  :
>   some arguments stored for var do not match
>
> That warning is true, "var" doesn't take that list of arguments, including
> "clean".  But when I use name="StdDev" in the portfolio construction, I
> get the following error:
>
> Error in optimize.portfolio(R = R, portfolio = MinSD.portf,
> optimize_method = "ROI") :
>   ROI only solves mean, var, or sample ETL/ES/CVaR type business
> objectives, choose a different optimize_method.
> In addition: Warning message:
> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>
> So the first issue is to map "StdDev" into the list of acceptable
> functions for that solver.  It should then accept the "clean" argument and
> that should fix part of the issue.
>

Got it, I'll add functionality for StdDev to be accepted by the ROI
solvers. I'll have to add StdDev, but still use "var" to calculate the
variance-covariance matrix used in the objective function. I will also have
to detect the "clean" argument so that the cleaned returns are used to
calculate the variance-covariance matrix.


>
> The second issue is that the Min mETL portfolio being identified isn't
> being plotted as the minimum mETL portfolio being identified in the cloud
> of random portfolios.  This is the same issue I saw earlier that turned
> out to be related to "clean" not being applied consistently across
> objectives.
>
> In this case, it should be:
> p=1-1/12
> clean="boudt"
> MinmETL.portf <- add.objective(portfolio=init.portf,
>   type="risk", # the kind of objective this is
>   name="ES", # the function to minimize
>   arguments=list(p=p, clean=clean)
> )
>
> > MinmETL.ROI<-optimize.portfolio(R=R,
> +   portfolio=MinmETL.portf,
> +   optimize_method='ROI',
> +   trace=TRUE, verbose=TRUE
> +   )
> Warning message:
> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>
> I'm not sure if the warning is related.  But I'm wondering if "clean" is
> getting passed into "ES" with ROI.  If it isn't, then the optimizer is
> likely selecting the wrong portfolio.  Could you take a look at this when
> you have a moment?
>

It could be related, in general, the "clean" argument is not passed to ROI.
I should be able to make some changes so that the cleaned returns are used
for the ROI solvers. I'll take a closer look and report back with my
findings.


>
> Thanks,
>
> pcc
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131009/cfa36776/attachment.html>

From rossbennett34 at gmail.com  Fri Oct 11 07:16:43 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Thu, 10 Oct 2013 22:16:43 -0700
Subject: [GSoC-PortA] Issue passing "clean"?
In-Reply-To: <CAEESW=VfadZUR_A2a8x5fquzjzn7C7jvMbQsA_1-E5zNCub=8A@mail.gmail.com>
References: <aa2d3a80ec953b254453df56c80c80e5.squirrel@mail.braverock.com>
 <CAEESW=VfadZUR_A2a8x5fquzjzn7C7jvMbQsA_1-E5zNCub=8A@mail.gmail.com>
Message-ID: <CAEESW=V6Vszy=GCKLDrv_V2J8fo6JZHpvFs=yCsS6ER=CYJ_sA@mail.gmail.com>

Peter,

In commit r3216 I made revisions so that the ROI solvers recognize clean
and any other arguments in the $arguments slot in each objective. I am
really glad you brought this up because I realized that nothing in the
$arguments slot was being recognized for optimize_method="ROI"... this was
something I overlooked. This is corrected and cleaned returns can now be
used with optimize_method="ROI" for the QP/LP problems. I also added
"StdDev" as a valid objective name, but still use "var" to calculate the
variance-covariance matrix used in the objective function.

Regarding your example above with the min SD portfolio having a lower mETL
than the min mETL. I'm not 100% sure on this, but it could depend on if/how
you call constrained_objective to calculate the objective measures. For
example, the results of the minimum ETL portfolio with ROI will be
different than the minimum mETL portfolio with RP. The LP formulation to
minimize ETL uses empirical returns data whereas the optimization with
random portfolios uses modified ETL by default which will likely result in
different optimal weights. It is a case of comparing "apples to oranges".

Attached is a quick script demonstrating this. Relevant outputs below.

> # Minimum ETL using ROI
> optROI <- optimize.portfolio(R=ret, portfolio=tmp1,
optimize_method="ROI", trace=TRUE)
[1] 0.0833
> extractObjectiveMeasures(optROI)
$ES
[1] 0.01718848

> # Use constrained_objective to calculate mETL with the optimal weights
from optROI
> constrained_objective(w=optROI$weights, R=ret, portfolio=tmp1,
trace=TRUE)$objective_measures
$ES
         [,1]
ES 0.01761023
attr(,"names")
[1] "ES"

> # minimum mETL with random portfolios
> optRP <- optimize.portfolio(R=ret, portfolio=tmp1,
optimize_method="random", search_size=2000, trace=TRUE)
> extractObjectiveMeasures(optRP)
$ES
         [,1]
ES 0.01740961
attr(,"names")
[1] "ES"

Ross



On Wed, Oct 9, 2013 at 3:20 PM, Ross Bennett <rossbennett34 at gmail.com>wrote:

> Peter,
>
> Thanks for the detailed description of what is going on. I will be able to
> dig into this deeper tomorrow afternoon, but here are some initial comments.
>
> See comments in-line.
>
>
>
> On Wed, Oct 9, 2013 at 1:38 PM, Peter Carl <peter at braverock.com> wrote:
>
>> Ross,
>>
>> I'm running into the following:
>>
>> > buoys.portfmeas
>>                 Mean      StdDev       mETL
>> MinSD    0.005435103 0.009286484 0.01357282
>> MinmETL  0.005846839 0.011196709 0.01371471
>>
>> Note that the minimum standard deviation portfolio has a lower mETL than
>> the Min mETL portfolio.  Both were calculated with ROI.
>>
>> MinSD.portf <- add.objective(portfolio=init.portf,
>>   type="risk", # the kind of objective this is
>>   name="var", # name of the function
>>   arguments=list(clean=clean)
>> )
>>
>> > MinSD.ROI<-optimize.portfolio(R=R,
>> +   portfolio=MinSD.portf,
>> +   optimize_method='ROI'
>> +   )
>> Warning message:
>> In constrained_objective(w = weights, R = R, portfolio, trace = TRUE,  :
>>   some arguments stored for var do not match
>>
>> That warning is true, "var" doesn't take that list of arguments, including
>> "clean".  But when I use name="StdDev" in the portfolio construction, I
>> get the following error:
>>
>> Error in optimize.portfolio(R = R, portfolio = MinSD.portf,
>> optimize_method = "ROI") :
>>   ROI only solves mean, var, or sample ETL/ES/CVaR type business
>> objectives, choose a different optimize_method.
>> In addition: Warning message:
>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>>
>> So the first issue is to map "StdDev" into the list of acceptable
>> functions for that solver.  It should then accept the "clean" argument and
>> that should fix part of the issue.
>>
>
> Got it, I'll add functionality for StdDev to be accepted by the ROI
> solvers. I'll have to add StdDev, but still use "var" to calculate the
> variance-covariance matrix used in the objective function. I will also have
> to detect the "clean" argument so that the cleaned returns are used to
> calculate the variance-covariance matrix.
>
>
>>
>> The second issue is that the Min mETL portfolio being identified isn't
>> being plotted as the minimum mETL portfolio being identified in the cloud
>> of random portfolios.  This is the same issue I saw earlier that turned
>> out to be related to "clean" not being applied consistently across
>> objectives.
>>
>> In this case, it should be:
>> p=1-1/12
>> clean="boudt"
>> MinmETL.portf <- add.objective(portfolio=init.portf,
>>   type="risk", # the kind of objective this is
>>   name="ES", # the function to minimize
>>   arguments=list(p=p, clean=clean)
>> )
>>
>> > MinmETL.ROI<-optimize.portfolio(R=R,
>> +   portfolio=MinmETL.portf,
>> +   optimize_method='ROI',
>> +   trace=TRUE, verbose=TRUE
>> +   )
>> Warning message:
>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>>
>> I'm not sure if the warning is related.  But I'm wondering if "clean" is
>> getting passed into "ES" with ROI.  If it isn't, then the optimizer is
>> likely selecting the wrong portfolio.  Could you take a look at this when
>> you have a moment?
>>
>
> It could be related, in general, the "clean" argument is not passed to
> ROI. I should be able to make some changes so that the cleaned returns are
> used for the ROI solvers. I'll take a closer look and report back with my
> findings.
>
>
>>
>> Thanks,
>>
>> pcc
>> --
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131010/8357af2a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testing_ETL_vs_mETL.R
Type: application/octet-stream
Size: 1233 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131010/8357af2a/attachment.obj>

From rossbennett34 at gmail.com  Fri Oct 11 07:17:37 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Thu, 10 Oct 2013 22:17:37 -0700
Subject: [GSoC-PortA] PortfolioAnalytics Failed to Build
Message-ID: <CAEESW=V=7UyeCETerJBJf3uHv6ZksQ8JvWpjGv3Hm_+cJiu_BQ@mail.gmail.com>

PortfolioAnalytics is failing to build on R-forge and the error is below.

Error: processing vignette ?ROI_vignette.Rnw? failed with diagnostics:
 chunk 16
Error in (dir == "<=") | (dir = q = "<") :
  operations are possible only for numeric, logical or complex types
Execution halted
Run time: 32.14 seconds.


This is an ROI error that has always been an issue, but I don't recall this
error being an issue in the R-forge builds previously. This error stems
from the ROI.plugin.quadprog package on CRAN.

Any thoughts on why this is happening or how I can resolve this?

Thanks,
Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20131010/9fa95fc9/attachment.html>

From peter at braverock.com  Fri Oct 11 16:19:19 2013
From: peter at braverock.com (Peter Carl)
Date: Fri, 11 Oct 2013 09:19:19 -0500
Subject: [GSoC-PortA] Issue passing "clean"?
In-Reply-To: <CAEESW=V6Vszy=GCKLDrv_V2J8fo6JZHpvFs=yCsS6ER=CYJ_sA@mail.gmail.com>
References: <aa2d3a80ec953b254453df56c80c80e5.squirrel@mail.braverock.com>
 <CAEESW=VfadZUR_A2a8x5fquzjzn7C7jvMbQsA_1-E5zNCub=8A@mail.gmail.com>
 <CAEESW=V6Vszy=GCKLDrv_V2J8fo6JZHpvFs=yCsS6ER=CYJ_sA@mail.gmail.com>
Message-ID: <81520832124022f74965a5bbfd1a08d1.squirrel@mail.braverock.com>

Thanks for doing this - I'll test it today.

To your point on comparing different methods - I completely agree.  That
said, comparing the outputs of the different methods can be useful for
understanding methodological differences and ferreting out issues like
this one.

The heuristic methods are less accurate and possibly less precise than the
closed form methods (it isn't clear to me how much I care about this in
the face of estimation error), not to mention slower and more compute
intensive (but I know I care about those issues), and we'll always prefer
the latter when they are applicable.  The heuristic methods, of course,
have their place in visualization and developing intuition about the more
'abstract' methods, as well as in more complex objective sets.

I actually identified this issue comparing the two ROI-based methods,
noting that one of the dimensions was "off".  Although I'm guessing that
this will take care of the issue, I'm not entirely sure.  I'm glad you
told me that none of the arguments were being passed - it gives me some
comfort that the mETL measure was probably being calc'd at 95% instead of
91.7% in the ROI optimization - this change should impact the portfolio
selected significantly.  So hopefully this will work.

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

> Peter,
>
> In commit r3216 I made revisions so that the ROI solvers recognize clean
> and any other arguments in the $arguments slot in each objective. I am
> really glad you brought this up because I realized that nothing in the
> $arguments slot was being recognized for optimize_method="ROI"... this was
> something I overlooked. This is corrected and cleaned returns can now be
> used with optimize_method="ROI" for the QP/LP problems. I also added
> "StdDev" as a valid objective name, but still use "var" to calculate the
> variance-covariance matrix used in the objective function.
>
> Regarding your example above with the min SD portfolio having a lower mETL
> than the min mETL. I'm not 100% sure on this, but it could depend on
> if/how
> you call constrained_objective to calculate the objective measures. For
> example, the results of the minimum ETL portfolio with ROI will be
> different than the minimum mETL portfolio with RP. The LP formulation to
> minimize ETL uses empirical returns data whereas the optimization with
> random portfolios uses modified ETL by default which will likely result in
> different optimal weights. It is a case of comparing "apples to oranges".
>
> Attached is a quick script demonstrating this. Relevant outputs below.
>
>> # Minimum ETL using ROI
>> optROI <- optimize.portfolio(R=ret, portfolio=tmp1,
> optimize_method="ROI", trace=TRUE)
> [1] 0.0833
>> extractObjectiveMeasures(optROI)
> $ES
> [1] 0.01718848
>
>> # Use constrained_objective to calculate mETL with the optimal weights
> from optROI
>> constrained_objective(w=optROI$weights, R=ret, portfolio=tmp1,
> trace=TRUE)$objective_measures
> $ES
>          [,1]
> ES 0.01761023
> attr(,"names")
> [1] "ES"
>
>> # minimum mETL with random portfolios
>> optRP <- optimize.portfolio(R=ret, portfolio=tmp1,
> optimize_method="random", search_size=2000, trace=TRUE)
>> extractObjectiveMeasures(optRP)
> $ES
>          [,1]
> ES 0.01740961
> attr(,"names")
> [1] "ES"
>
> Ross
>
>
>
> On Wed, Oct 9, 2013 at 3:20 PM, Ross Bennett
> <rossbennett34 at gmail.com>wrote:
>
>> Peter,
>>
>> Thanks for the detailed description of what is going on. I will be able
>> to
>> dig into this deeper tomorrow afternoon, but here are some initial
>> comments.
>>
>> See comments in-line.
>>
>>
>>
>> On Wed, Oct 9, 2013 at 1:38 PM, Peter Carl <peter at braverock.com> wrote:
>>
>>> Ross,
>>>
>>> I'm running into the following:
>>>
>>> > buoys.portfmeas
>>>                 Mean      StdDev       mETL
>>> MinSD    0.005435103 0.009286484 0.01357282
>>> MinmETL  0.005846839 0.011196709 0.01371471
>>>
>>> Note that the minimum standard deviation portfolio has a lower mETL
>>> than
>>> the Min mETL portfolio.  Both were calculated with ROI.
>>>
>>> MinSD.portf <- add.objective(portfolio=init.portf,
>>>   type="risk", # the kind of objective this is
>>>   name="var", # name of the function
>>>   arguments=list(clean=clean)
>>> )
>>>
>>> > MinSD.ROI<-optimize.portfolio(R=R,
>>> +   portfolio=MinSD.portf,
>>> +   optimize_method='ROI'
>>> +   )
>>> Warning message:
>>> In constrained_objective(w = weights, R = R, portfolio, trace = TRUE,
>>> :
>>>   some arguments stored for var do not match
>>>
>>> That warning is true, "var" doesn't take that list of arguments,
>>> including
>>> "clean".  But when I use name="StdDev" in the portfolio construction, I
>>> get the following error:
>>>
>>> Error in optimize.portfolio(R = R, portfolio = MinSD.portf,
>>> optimize_method = "ROI") :
>>>   ROI only solves mean, var, or sample ETL/ES/CVaR type business
>>> objectives, choose a different optimize_method.
>>> In addition: Warning message:
>>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>>>
>>> So the first issue is to map "StdDev" into the list of acceptable
>>> functions for that solver.  It should then accept the "clean" argument
>>> and
>>> that should fix part of the issue.
>>>
>>
>> Got it, I'll add functionality for StdDev to be accepted by the ROI
>> solvers. I'll have to add StdDev, but still use "var" to calculate the
>> variance-covariance matrix used in the objective function. I will also
>> have
>> to detect the "clean" argument so that the cleaned returns are used to
>> calculate the variance-covariance matrix.
>>
>>
>>>
>>> The second issue is that the Min mETL portfolio being identified isn't
>>> being plotted as the minimum mETL portfolio being identified in the
>>> cloud
>>> of random portfolios.  This is the same issue I saw earlier that turned
>>> out to be related to "clean" not being applied consistently across
>>> objectives.
>>>
>>> In this case, it should be:
>>> p=1-1/12
>>> clean="boudt"
>>> MinmETL.portf <- add.objective(portfolio=init.portf,
>>>   type="risk", # the kind of objective this is
>>>   name="ES", # the function to minimize
>>>   arguments=list(p=p, clean=clean)
>>> )
>>>
>>> > MinmETL.ROI<-optimize.portfolio(R=R,
>>> +   portfolio=MinmETL.portf,
>>> +   optimize_method='ROI',
>>> +   trace=TRUE, verbose=TRUE
>>> +   )
>>> Warning message:
>>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>>>
>>> I'm not sure if the warning is related.  But I'm wondering if "clean"
>>> is
>>> getting passed into "ES" with ROI.  If it isn't, then the optimizer is
>>> likely selecting the wrong portfolio.  Could you take a look at this
>>> when
>>> you have a moment?
>>>
>>
>> It could be related, in general, the "clean" argument is not passed to
>> ROI. I should be able to make some changes so that the cleaned returns
>> are
>> used for the ROI solvers. I'll take a closer look and report back with
>> my
>> findings.
>>
>>
>>>
>>> Thanks,
>>>
>>> pcc
>>> --
>>> 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
>


From peter at braverock.com  Fri Oct 11 16:37:38 2013
From: peter at braverock.com (Peter Carl)
Date: Fri, 11 Oct 2013 09:37:38 -0500
Subject: [GSoC-PortA] Issue passing "clean"?
In-Reply-To: <81520832124022f74965a5bbfd1a08d1.squirrel@mail.braverock.com>
References: <aa2d3a80ec953b254453df56c80c80e5.squirrel@mail.braverock.com>
 <CAEESW=VfadZUR_A2a8x5fquzjzn7C7jvMbQsA_1-E5zNCub=8A@mail.gmail.com>
 <CAEESW=V6Vszy=GCKLDrv_V2J8fo6JZHpvFs=yCsS6ER=CYJ_sA@mail.gmail.com>
 <81520832124022f74965a5bbfd1a08d1.squirrel@mail.braverock.com>
Message-ID: <20ae9bf531745769d310eb03fda6edec.squirrel@mail.braverock.com>

Works great - thanks again...

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

> Thanks for doing this - I'll test it today.
>
> To your point on comparing different methods - I completely agree.  That
> said, comparing the outputs of the different methods can be useful for
> understanding methodological differences and ferreting out issues like
> this one.
>
> The heuristic methods are less accurate and possibly less precise than the
> closed form methods (it isn't clear to me how much I care about this in
> the face of estimation error), not to mention slower and more compute
> intensive (but I know I care about those issues), and we'll always prefer
> the latter when they are applicable.  The heuristic methods, of course,
> have their place in visualization and developing intuition about the more
> 'abstract' methods, as well as in more complex objective sets.
>
> I actually identified this issue comparing the two ROI-based methods,
> noting that one of the dimensions was "off".  Although I'm guessing that
> this will take care of the issue, I'm not entirely sure.  I'm glad you
> told me that none of the arguments were being passed - it gives me some
> comfort that the mETL measure was probably being calc'd at 95% instead of
> 91.7% in the ROI optimization - this change should impact the portfolio
> selected significantly.  So hopefully this will work.
>
> pcc
> --
> Peter Carl
> http://www.braverock.com/peter
>
>> Peter,
>>
>> In commit r3216 I made revisions so that the ROI solvers recognize clean
>> and any other arguments in the $arguments slot in each objective. I am
>> really glad you brought this up because I realized that nothing in the
>> $arguments slot was being recognized for optimize_method="ROI"... this
>> was
>> something I overlooked. This is corrected and cleaned returns can now be
>> used with optimize_method="ROI" for the QP/LP problems. I also added
>> "StdDev" as a valid objective name, but still use "var" to calculate the
>> variance-covariance matrix used in the objective function.
>>
>> Regarding your example above with the min SD portfolio having a lower
>> mETL
>> than the min mETL. I'm not 100% sure on this, but it could depend on
>> if/how
>> you call constrained_objective to calculate the objective measures. For
>> example, the results of the minimum ETL portfolio with ROI will be
>> different than the minimum mETL portfolio with RP. The LP formulation to
>> minimize ETL uses empirical returns data whereas the optimization with
>> random portfolios uses modified ETL by default which will likely result
>> in
>> different optimal weights. It is a case of comparing "apples to
>> oranges".
>>
>> Attached is a quick script demonstrating this. Relevant outputs below.
>>
>>> # Minimum ETL using ROI
>>> optROI <- optimize.portfolio(R=ret, portfolio=tmp1,
>> optimize_method="ROI", trace=TRUE)
>> [1] 0.0833
>>> extractObjectiveMeasures(optROI)
>> $ES
>> [1] 0.01718848
>>
>>> # Use constrained_objective to calculate mETL with the optimal weights
>> from optROI
>>> constrained_objective(w=optROI$weights, R=ret, portfolio=tmp1,
>> trace=TRUE)$objective_measures
>> $ES
>>          [,1]
>> ES 0.01761023
>> attr(,"names")
>> [1] "ES"
>>
>>> # minimum mETL with random portfolios
>>> optRP <- optimize.portfolio(R=ret, portfolio=tmp1,
>> optimize_method="random", search_size=2000, trace=TRUE)
>>> extractObjectiveMeasures(optRP)
>> $ES
>>          [,1]
>> ES 0.01740961
>> attr(,"names")
>> [1] "ES"
>>
>> Ross
>>
>>
>>
>> On Wed, Oct 9, 2013 at 3:20 PM, Ross Bennett
>> <rossbennett34 at gmail.com>wrote:
>>
>>> Peter,
>>>
>>> Thanks for the detailed description of what is going on. I will be able
>>> to
>>> dig into this deeper tomorrow afternoon, but here are some initial
>>> comments.
>>>
>>> See comments in-line.
>>>
>>>
>>>
>>> On Wed, Oct 9, 2013 at 1:38 PM, Peter Carl <peter at braverock.com> wrote:
>>>
>>>> Ross,
>>>>
>>>> I'm running into the following:
>>>>
>>>> > buoys.portfmeas
>>>>                 Mean      StdDev       mETL
>>>> MinSD    0.005435103 0.009286484 0.01357282
>>>> MinmETL  0.005846839 0.011196709 0.01371471
>>>>
>>>> Note that the minimum standard deviation portfolio has a lower mETL
>>>> than
>>>> the Min mETL portfolio.  Both were calculated with ROI.
>>>>
>>>> MinSD.portf <- add.objective(portfolio=init.portf,
>>>>   type="risk", # the kind of objective this is
>>>>   name="var", # name of the function
>>>>   arguments=list(clean=clean)
>>>> )
>>>>
>>>> > MinSD.ROI<-optimize.portfolio(R=R,
>>>> +   portfolio=MinSD.portf,
>>>> +   optimize_method='ROI'
>>>> +   )
>>>> Warning message:
>>>> In constrained_objective(w = weights, R = R, portfolio, trace = TRUE,
>>>> :
>>>>   some arguments stored for var do not match
>>>>
>>>> That warning is true, "var" doesn't take that list of arguments,
>>>> including
>>>> "clean".  But when I use name="StdDev" in the portfolio construction,
>>>> I
>>>> get the following error:
>>>>
>>>> Error in optimize.portfolio(R = R, portfolio = MinSD.portf,
>>>> optimize_method = "ROI") :
>>>>   ROI only solves mean, var, or sample ETL/ES/CVaR type business
>>>> objectives, choose a different optimize_method.
>>>> In addition: Warning message:
>>>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>>>>
>>>> So the first issue is to map "StdDev" into the list of acceptable
>>>> functions for that solver.  It should then accept the "clean" argument
>>>> and
>>>> that should fix part of the issue.
>>>>
>>>
>>> Got it, I'll add functionality for StdDev to be accepted by the ROI
>>> solvers. I'll have to add StdDev, but still use "var" to calculate the
>>> variance-covariance matrix used in the objective function. I will also
>>> have
>>> to detect the "clean" argument so that the cleaned returns are used to
>>> calculate the variance-covariance matrix.
>>>
>>>
>>>>
>>>> The second issue is that the Min mETL portfolio being identified isn't
>>>> being plotted as the minimum mETL portfolio being identified in the
>>>> cloud
>>>> of random portfolios.  This is the same issue I saw earlier that
>>>> turned
>>>> out to be related to "clean" not being applied consistently across
>>>> objectives.
>>>>
>>>> In this case, it should be:
>>>> p=1-1/12
>>>> clean="boudt"
>>>> MinmETL.portf <- add.objective(portfolio=init.portf,
>>>>   type="risk", # the kind of objective this is
>>>>   name="ES", # the function to minimize
>>>>   arguments=list(p=p, clean=clean)
>>>> )
>>>>
>>>> > MinmETL.ROI<-optimize.portfolio(R=R,
>>>> +   portfolio=MinmETL.portf,
>>>> +   optimize_method='ROI',
>>>> +   trace=TRUE, verbose=TRUE
>>>> +   )
>>>> Warning message:
>>>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
>>>>
>>>> I'm not sure if the warning is related.  But I'm wondering if "clean"
>>>> is
>>>> getting passed into "ES" with ROI.  If it isn't, then the optimizer is
>>>> likely selecting the wrong portfolio.  Could you take a look at this
>>>> when
>>>> you have a moment?
>>>>
>>>
>>> It could be related, in general, the "clean" argument is not passed to
>>> ROI. I should be able to make some changes so that the cleaned returns
>>> are
>>> used for the ROI solvers. I'll take a closer look and report back with
>>> my
>>> findings.
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> pcc
>>>> --
>>>> 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
>



From rossbennett34 at gmail.com  Sun Oct 13 03:43:32 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Sat, 12 Oct 2013 18:43:32 -0700
Subject: [GSoC-PortA] Issue passing "clean"?
In-Reply-To: <20ae9bf531745769d310eb03fda6edec.squirrel@mail.braverock.com>
References: <aa2d3a80ec953b254453df56c80c80e5.squirrel@mail.braverock.com>
 <CAEESW=VfadZUR_A2a8x5fquzjzn7C7jvMbQsA_1-E5zNCub=8A@mail.gmail.com>
 <CAEESW=V6Vszy=GCKLDrv_V2J8fo6JZHpvFs=yCsS6ER=CYJ_sA@mail.gmail.com>
 <81520832124022f74965a5bbfd1a08d1.squirrel@mail.braverock.com>
 <20ae9bf531745769d310eb03fda6edec.squirrel@mail.braverock.com>
Message-ID: <CAEESW=Wk_bWStbJXiRSzscXqrhra6T5+59c9o6+of--y+MT8=Q@mail.gmail.com>

I'm glad it works, thanks for the feedback... and thanks for your patience
while I get things like this ironed out.

Ross


On Fri, Oct 11, 2013 at 7:37 AM, Peter Carl <peter at braverock.com> wrote:

> Works great - thanks again...
>
> pcc
> --
> Peter Carl
> http://www.braverock.com/peter
>
> > Thanks for doing this - I'll test it today.
> >
> > To your point on comparing different methods - I completely agree.  That
> > said, comparing the outputs of the different methods can be useful for
> > understanding methodological differences and ferreting out issues like
> > this one.
> >
> > The heuristic methods are less accurate and possibly less precise than
> the
> > closed form methods (it isn't clear to me how much I care about this in
> > the face of estimation error), not to mention slower and more compute
> > intensive (but I know I care about those issues), and we'll always prefer
> > the latter when they are applicable.  The heuristic methods, of course,
> > have their place in visualization and developing intuition about the more
> > 'abstract' methods, as well as in more complex objective sets.
> >
> > I actually identified this issue comparing the two ROI-based methods,
> > noting that one of the dimensions was "off".  Although I'm guessing that
> > this will take care of the issue, I'm not entirely sure.  I'm glad you
> > told me that none of the arguments were being passed - it gives me some
> > comfort that the mETL measure was probably being calc'd at 95% instead of
> > 91.7% in the ROI optimization - this change should impact the portfolio
> > selected significantly.  So hopefully this will work.
> >
> > pcc
> > --
> > Peter Carl
> > http://www.braverock.com/peter
> >
> >> Peter,
> >>
> >> In commit r3216 I made revisions so that the ROI solvers recognize clean
> >> and any other arguments in the $arguments slot in each objective. I am
> >> really glad you brought this up because I realized that nothing in the
> >> $arguments slot was being recognized for optimize_method="ROI"... this
> >> was
> >> something I overlooked. This is corrected and cleaned returns can now be
> >> used with optimize_method="ROI" for the QP/LP problems. I also added
> >> "StdDev" as a valid objective name, but still use "var" to calculate the
> >> variance-covariance matrix used in the objective function.
> >>
> >> Regarding your example above with the min SD portfolio having a lower
> >> mETL
> >> than the min mETL. I'm not 100% sure on this, but it could depend on
> >> if/how
> >> you call constrained_objective to calculate the objective measures. For
> >> example, the results of the minimum ETL portfolio with ROI will be
> >> different than the minimum mETL portfolio with RP. The LP formulation to
> >> minimize ETL uses empirical returns data whereas the optimization with
> >> random portfolios uses modified ETL by default which will likely result
> >> in
> >> different optimal weights. It is a case of comparing "apples to
> >> oranges".
> >>
> >> Attached is a quick script demonstrating this. Relevant outputs below.
> >>
> >>> # Minimum ETL using ROI
> >>> optROI <- optimize.portfolio(R=ret, portfolio=tmp1,
> >> optimize_method="ROI", trace=TRUE)
> >> [1] 0.0833
> >>> extractObjectiveMeasures(optROI)
> >> $ES
> >> [1] 0.01718848
> >>
> >>> # Use constrained_objective to calculate mETL with the optimal weights
> >> from optROI
> >>> constrained_objective(w=optROI$weights, R=ret, portfolio=tmp1,
> >> trace=TRUE)$objective_measures
> >> $ES
> >>          [,1]
> >> ES 0.01761023
> >> attr(,"names")
> >> [1] "ES"
> >>
> >>> # minimum mETL with random portfolios
> >>> optRP <- optimize.portfolio(R=ret, portfolio=tmp1,
> >> optimize_method="random", search_size=2000, trace=TRUE)
> >>> extractObjectiveMeasures(optRP)
> >> $ES
> >>          [,1]
> >> ES 0.01740961
> >> attr(,"names")
> >> [1] "ES"
> >>
> >> Ross
> >>
> >>
> >>
> >> On Wed, Oct 9, 2013 at 3:20 PM, Ross Bennett
> >> <rossbennett34 at gmail.com>wrote:
> >>
> >>> Peter,
> >>>
> >>> Thanks for the detailed description of what is going on. I will be able
> >>> to
> >>> dig into this deeper tomorrow afternoon, but here are some initial
> >>> comments.
> >>>
> >>> See comments in-line.
> >>>
> >>>
> >>>
> >>> On Wed, Oct 9, 2013 at 1:38 PM, Peter Carl <peter at braverock.com>
> wrote:
> >>>
> >>>> Ross,
> >>>>
> >>>> I'm running into the following:
> >>>>
> >>>> > buoys.portfmeas
> >>>>                 Mean      StdDev       mETL
> >>>> MinSD    0.005435103 0.009286484 0.01357282
> >>>> MinmETL  0.005846839 0.011196709 0.01371471
> >>>>
> >>>> Note that the minimum standard deviation portfolio has a lower mETL
> >>>> than
> >>>> the Min mETL portfolio.  Both were calculated with ROI.
> >>>>
> >>>> MinSD.portf <- add.objective(portfolio=init.portf,
> >>>>   type="risk", # the kind of objective this is
> >>>>   name="var", # name of the function
> >>>>   arguments=list(clean=clean)
> >>>> )
> >>>>
> >>>> > MinSD.ROI<-optimize.portfolio(R=R,
> >>>> +   portfolio=MinSD.portf,
> >>>> +   optimize_method='ROI'
> >>>> +   )
> >>>> Warning message:
> >>>> In constrained_objective(w = weights, R = R, portfolio, trace = TRUE,
> >>>> :
> >>>>   some arguments stored for var do not match
> >>>>
> >>>> That warning is true, "var" doesn't take that list of arguments,
> >>>> including
> >>>> "clean".  But when I use name="StdDev" in the portfolio construction,
> >>>> I
> >>>> get the following error:
> >>>>
> >>>> Error in optimize.portfolio(R = R, portfolio = MinSD.portf,
> >>>> optimize_method = "ROI") :
> >>>>   ROI only solves mean, var, or sample ETL/ES/CVaR type business
> >>>> objectives, choose a different optimize_method.
> >>>> In addition: Warning message:
> >>>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
> >>>>
> >>>> So the first issue is to map "StdDev" into the list of acceptable
> >>>> functions for that solver.  It should then accept the "clean" argument
> >>>> and
> >>>> that should fix part of the issue.
> >>>>
> >>>
> >>> Got it, I'll add functionality for StdDev to be accepted by the ROI
> >>> solvers. I'll have to add StdDev, but still use "var" to calculate the
> >>> variance-covariance matrix used in the objective function. I will also
> >>> have
> >>> to detect the "clean" argument so that the cleaned returns are used to
> >>> calculate the variance-covariance matrix.
> >>>
> >>>
> >>>>
> >>>> The second issue is that the Min mETL portfolio being identified isn't
> >>>> being plotted as the minimum mETL portfolio being identified in the
> >>>> cloud
> >>>> of random portfolios.  This is the same issue I saw earlier that
> >>>> turned
> >>>> out to be related to "clean" not being applied consistently across
> >>>> objectives.
> >>>>
> >>>> In this case, it should be:
> >>>> p=1-1/12
> >>>> clean="boudt"
> >>>> MinmETL.portf <- add.objective(portfolio=init.portf,
> >>>>   type="risk", # the kind of objective this is
> >>>>   name="ES", # the function to minimize
> >>>>   arguments=list(p=p, clean=clean)
> >>>> )
> >>>>
> >>>> > MinmETL.ROI<-optimize.portfolio(R=R,
> >>>> +   portfolio=MinmETL.portf,
> >>>> +   optimize_method='ROI',
> >>>> +   trace=TRUE, verbose=TRUE
> >>>> +   )
> >>>> Warning message:
> >>>> In is.na(le) : is.na() applied to non-(list or vector) of type 'NULL'
> >>>>
> >>>> I'm not sure if the warning is related.  But I'm wondering if "clean"
> >>>> is
> >>>> getting passed into "ES" with ROI.  If it isn't, then the optimizer is
> >>>> likely selecting the wrong portfolio.  Could you take a look at this
> >>>> when
> >>>> you have a moment?
> >>>>
> >>>
> >>> It could be related, in general, the "clean" argument is not passed to
> >>> ROI. I should be able to make some changes so that the cleaned returns
> >>> are
> >>> used for the ROI solvers. I'll take a closer look and report back with
> >>> my
> >>> findings.
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> pcc
> >>>> --
> >>>> 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/20131012/c24fce67/attachment.html>

From rossbennett34 at gmail.com  Tue Oct 15 16:28:20 2013
From: rossbennett34 at gmail.com (Ross Bennett)
Date: Tue, 15 Oct 2013 07:28:20 -0700
Subject: [GSoC-PortA] PortfolioAnalytics Failed to Build
In-Reply-To: <CAEESW=V=7UyeCETerJBJf3uHv6ZksQ8JvWpjGv3Hm_+cJiu_BQ@mail.gmail.com>
References: <CAEESW=V=7UyeCETerJBJf3uHv6ZksQ8JvWpjGv3Hm_+cJiu_BQ@mail.gmail.com>
Message-ID: <CAEESW=U0srEM5Uwx_hW-17OZM25zCnXMsUwbp-jM58aEygxprw@mail.gmail.com>

I am considering temporarily changing the affected function to use
solve.QP directly so we don't have this issue. I believe it only
affects one function and is a matter of changing a few lines of code.
I will simply switch back to using ROI when the fixed
ROI.plugin.quadprog package is on CRAN.

Any thoughts on this?

Thanks,
Ross

On Thu, Oct 10, 2013 at 10:17 PM, Ross Bennett <rossbennett34 at gmail.com> wrote:
> PortfolioAnalytics is failing to build on R-forge and the error is below.
>
> Error: processing vignette ?ROI_vignette.Rnw? failed with diagnostics:
>  chunk 16
> Error in (dir == "<=") | (dir = q = "<") :
>   operations are possible only for numeric, logical or complex types
> Execution halted
> Run time: 32.14 seconds.
>
>
> This is an ROI error that has always been an issue, but I don't recall this
> error being an issue in the R-forge builds previously. This error stems from
> the ROI.plugin.quadprog package on CRAN.
>
> Any thoughts on why this is happening or how I can resolve this?
>
> Thanks,
> Ross