<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoPlainText>I'll eventually catch up on this stuff (sounds like you should call it "exterior point methods"). Meanwhile, do either of you have an electronic version of the following paper by Burns? <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText> <i>Burns, P., 2007, Random Portfolios for Performance Measurement, in Erricos John Kontoghiorghes & Cristian Gatu eds.: Optimization, Econometric and Financial Analysis (Springer).</i><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: gsoc-porta-bounces@lists.r-forge.r-project.org [mailto:gsoc-porta-bounces@lists.r-forge.r-project.org] On Behalf Of Brian G. Peterson<br>Sent: Saturday, June 29, 2013 6:45 AM<br>To: PortfolioAnalytics<br>Subject: [GSoC-PortA] mapping function</p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Based on side conversations with Ross and Peter, I thought I should talk a little bit about next steps related to the mapping function.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Apologies for the long email, I want to be complete, and I hope that some of this can make its way to the documentation.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The purpose of the mapping function is to transform a weights vector that does not meet all the constraints into a weights vector that does meet the constraints, if one exists, hopefully with a minimum of transformation.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>In the random portfolios code, we've used a couple of techniques pioneered by Pat Burns. The philosophical idea is that your optimum portfolio is most likely to exist at the edges of the feasible space.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>At the first R/Finance conference, Pat used the analogy of a mountain lake, where the lake represents the feasible space. With a combination of lots of different constraints, the shore of the lake will not be smooth or regular. The lake (the feasible space) may not take up a large percentage of the terrain.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>If we randomly place a rock anywhere in the terrain, some of them will land in the lake, inside the feasible space, but most will land outside, on the slopes of the mountains that surround the lake. The goal should be to nudge these towards the shores of the lake (our feasible space).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Having exhausted the analogy, let's talk details.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>A slightly more rigorous treatment of the problem is given here:<o:p></o:p></p><p class=MsoPlainText><a href="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1680224"><span style='color:windowtext;text-decoration:none'>http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1680224</span></a><o:p></o:p></p><p class=MsoPlainText>It is possible that can use this method directly for random portfolios (and that we could add the ectra constraint types to DEoptim). If so, much of the rest of what I'll write here is irrelevant. I strongly suspect that there will be some constraint types that will still need to be 'adjusted' via a mapping method like the one laid out below, since a stochastic solver will hand us a vector that needs to be transformed at least in part to move into the feasible space. It's alsom not entirely clear to me that the methods presented in the paper can satisfy all our constraint types.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I think our first step should be to test each constraint type, in some sort of hierarchy, starting with box constraints (almost all solvers support box constraints, of course), since some of the other transformations will violate the box constraints, and we'll need to transform back again.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Each constraint can be evaluated as a logical expression against the weights vector. You can see code for doing something similar with time series data in the sigFormula function in quantstrat. It takes advantage of some base R functionality that can treat an R object (in this case the weights vector) as an environment or 'frame'. This allows the columns of the data to be addressed without any major manipulation, simply by column name (asset name in the weights vector, possibly after adding names back in).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The code looks something like this:<o:p></o:p></p><p class=MsoPlainText>eval(parse(text=formula), data)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>So, 'data' is our weights vector, and 'formula' is an expression that can be evaluated as a formula by R. Evaluating this formula will give us TRUE or FALSE to denote whether the weights vector is in compliance or in violation of that constraint. Then, we'll need to transform the weight vector, if possible, to comply with that constraint.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Specific Cases:<o:p></o:p></p><p class=MsoPlainText>I've implemented this transformation for box constraints in the random portfolios code. We don't need the evaluation I'll describe next for box constraints, because each single weight is handled separately.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>min_sum and max_sum leverage constraints can be evaluated without using the formula, since the formula is simple, and can be expressed in simple R code. The transformation can be accomplished by transforming the entire vector. There's code to do this in both the random portfolios code and in constrained_objective. It is probably preferable to do the transformation one weight at a time, as I do in the random portfolios code, to end closer to the edges of the feasible space, while continuing to take the box constraints into account.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>linear (in)equality constraints and group constraints can be evaluated generically via the formula method I've described above. Then individual weights can be transformed taking the value of the constraint<o:p></o:p></p><p class=MsoPlainText>(<,>,=) into account (along with the box constraints and leverage constraints).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>and so on...<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Challenges:<o:p></o:p></p><p class=MsoPlainText>- recovering the transformed vector from a optimization solver that doesn't directly support a mapping function. I've got some tricks for this using environments that we can revisit after we get the basic methodology working.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-allowing for progressively relaxing constraints when the constraints are simply too restrictive. Perhaps Doug has some documentation on this as he's done it in the past, or perhaps we can simply deal with it in the penalty part of constrained_objective()<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Hopefully this was helpful.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Regards,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Brian<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>--<o:p></o:p></p><p class=MsoPlainText>Brian G. Peterson<o:p></o:p></p><p class=MsoPlainText><a href="http://braverock.com/brian/"><span style='color:windowtext;text-decoration:none'>http://braverock.com/brian/</span></a><o:p></o:p></p><p class=MsoPlainText>Ph: 773-459-4973<o:p></o:p></p><p class=MsoPlainText>IM: bgpbraverock<o:p></o:p></p><p class=MsoPlainText>_______________________________________________<o:p></o:p></p><p class=MsoPlainText>GSoC-PortA mailing list<o:p></o:p></p><p class=MsoPlainText><a href="mailto:GSoC-PortA@lists.r-forge.r-project.org"><span style='color:windowtext;text-decoration:none'>GSoC-PortA@lists.r-forge.r-project.org</span></a><o:p></o:p></p><p class=MsoPlainText><a href="http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta"><span style='color:windowtext;text-decoration:none'>http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta</span></a><o:p></o:p></p></div></body></html>