<div dir="ltr">Thank you for the detailed information and examples of working with turnover as an objective function and working with subsetting data based on whether an asset is in or out in a given time period.<div><br></div>


<div>I am looking for clarification and have a couple thoughts on the structure of the specification object and how a user would go about specifying the objects.</div>
<div><br></div><div>Method 1</div><div><ul>
<li>Create a portfolio object</li><li>Create a constraint object</li><li>Add constraints to the constraint object</li><li>Create an objective object</li><li>Add objectives to the objective object</li>

<li>Add the constraint object and objective object to the portfolio object</li></ul><div>This has the advantage of being more flexible to work with because of the separate constraint and objective objects, but the disadvantage is the multiple steps. The way add.constraint() and add.objective() are currently, they need knowledge of the assets for box_constraint, group_constraint(), and risk_budget_objective(). For example, the box_constraints() function uses the number of assets to make a vector of the minimum and maximum weights if a scalar is passed in for min and max. Or would it make more sense to do these checks and setup inside an update.portfolio() function.</div>
<div><br></div><div>The code would look something like this</div><div>pspec <- portfolio.spec(assets)</div><div>constr <- constraint(pspec)</div><div>constr <- add.constraint(constr, "box", min=0, max=1)</div>

<div>obj <- objective(pspec)</div><div>obj <- add.objective(obj, type="risk", name="var")</div><div>pspec <- update.portfolio(pspec, constr, obj)</div><div style>optimize.portfolio(pspec)</div>

<div><br></div><div>Method 2</div><div><ul><li>Create a portfolio object</li><li>Add constraints to the portfolio object</li><li>Add objectives to the portfolio object</li></ul><div><div>The code would look something like this</div>
<div>pspec <- portfolio.spec(assets)</div><div>constr <- add.constraint(pspec, "box", min=0, max=1)</div><div>obj <- add.objective(obj, type="risk", name="var")</div><div>optimize.portfolio(pspec)</div>
</div><div><br></div><div>This is less flexible and wouldn't allow someone to "re-use" objective or constraints. The current objective functions could be re-used and would just be added to a list in a portfolio.spec object instead of the current constraint object. The structure of the portfolio.spec object would be similar to the current constraint object so we shouldn't need too many changes to optimize.portfolio.</div>
<div><br></div><div style>Please advise as to the direction I should proceed and any thoughts on this.</div><div style><br></div><div style>Thanks,</div><div style>Ross Bennett</div>
</div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 4:28 AM, Brian G. Peterson <span dir="ltr"><<a href="mailto:brian@braverock.com" target="_blank">brian@braverock.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 06/18/2013 03:34 AM, Kris Boudt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Intrinsically, it means that what we used to call "soft constraints"<br>
(the constraints that can be violated) are classified as<br>
"objectives". Seems good to me, but we need to make sure that each<br>
objective has then its multiplier/scaling factor, which by default is<br>
1, but for soft constraints will typically be higher.<br>
</blockquote>
<br></div>
I've never liked the 'soft constraints' construct, as it's not very<br>
clear.  My distinction was between things we can do *before* calling the<br>
objective function, only on the weights vector, which we'll call<br>
'constraints' and things that we can do only by acting on the set of all<br>
possible weights vectors which satisfy the constraints (the objectives).<br>
<br>
We've always supported both multipliers and penalties for the individual objectives, from the very first version of the code.  In practice, two things go into selecting a multiplier:<br>
<br>
a. the objectives must inherently be of similar scale, e.g. both returning a return number of roughly equal magnitude.  if they are not of roughly equal magnitude, then the user needs to use the multiplier to adjust.<br>

<br>
b. the user must understand that to over/under weight a specific objective with respect to other objectives, they need to adjust either the multiplier or the penalty, or both.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. I would also include a turnover objective, whereby there seem to<br>
be two possibilities:<br>
<br>
- provide directly the weights at the time of rebalancing - provide<br>
the weights at the previous rebalancing data and include a function<br>
that, uses the return data to calculate the weights at the time of<br>
rebalancing.<br>
</blockquote>
<br></div>
We demonstrated how to use a turnover objective function in our 2012<br>
R/Finance seminar:<br>
<br>
<a href="http://www.rinfinance.com/agenda/2010/Carl+Peterson+Boudt_Tutorial.pdf" target="_blank">http://www.rinfinance.com/<u></u>agenda/2010/Carl+Peterson+<u></u>Boudt_Tutorial.pdf</a><br>
<br>
see page 36<br>
<br>
with code here:<br>
<a href="https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/PortfolioAnalytics/sandbox/script.workshop2010.R?root=returnanalytics" target="_blank">https://r-forge.r-project.org/<u></u>scm/viewvc.php/*checkout*/pkg/<u></u>PortfolioAnalytics/sandbox/<u></u>script.workshop2010.R?root=<u></u>returnanalytics</a><br>

<br>
It would be nice to get the chart from page 36 into the package if we have time later in the summer.<br>
<br>
In practice, turnover can be dealt with either as a constraint (in some solvers) or as an objective.  Doug would need to comment on using it as a constraint, I know there's a brief discussion of that in MPO(v1) or perhaps Bernd's book, both of which I have at the office right now.<br>

<br>
I've always done it as an objective, which works fine in current code.<br>
<br>
It would probably be nice to include the turnover function in the package directly and document it.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. In practical work,  I work with a price data file that has all<br>
possible constituents and for each selection date a list of allowed<br>
constituents. Typically an xts with in row the selection dates and<br>
columns the assets with 1 if included and 0 otherwise. Such a<br>
constituents check could be in the constraints object.<br>
</blockquote>
<br></div>
It seems to me that this belongs in the portfolio specification.  That is to say that the constituents of the portfolio are defined in the portfolio specification as a time series.<br>
<br>
Another way to think of this, of course, is to say that an equality constraint (weight=0) is imposed on some of the overall universe of constituents at certain times.  You can also do it with box constraints that vary through time.<br>

<br>
I think I prefer the first approach as more intuitive for the user, and dealing with subsetting the input data to match the allowed constituents within optimize.portfolio.  We're better off never giving data to the solvers that they don't need, and if the constituent is out of the portfolio, then the subset can happen before the optimization step. That's just an initial feeling though.<br>

<br>
I think we need to think more about what it does to the code to support time-varying constraints and portfolio specifications, and then put it wherever it makes the most sense.  I don't see any reason to work on that this week though, as the overall structure seems more important to me at this point, and I think we can cover this when we have a more coherent framework to work from.<br>

<br>
Regards,<br>
<br>
Brian<div class="im HOEnZb"><br>
<br>
-- <br>
Brian G. Peterson<br>
<a href="http://braverock.com/brian/" target="_blank">http://braverock.com/brian/</a><br>
Ph: <a href="tel:773-459-4973" value="+17734594973" target="_blank">773-459-4973</a><br>
IM: bgpbraverock<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
GSoC-PortA mailing list<br>
<a href="mailto:GSoC-PortA@lists.r-forge.r-project.org" target="_blank">GSoC-PortA@lists.r-forge.r-<u></u>project.org</a><br>
<a href="http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta" target="_blank">http://lists.r-forge.r-<u></u>project.org/cgi-bin/mailman/<u></u>listinfo/gsoc-porta</a><br>
</div></div></blockquote></div><br></div>