[GSoC-PortA] structure of the specification objects

[Brian G. Peterson]

On 06/18/2013 03:34 AM, Kris Boudt wrote:
> Intrinsically, it means that what we used to call "soft constraints"
> (the constraints that can be violated) are classified as
> "objectives". Seems good to me, but we need to make sure that each
> objective has then its multiplier/scaling factor, which by default is
> 1, but for soft constraints will typically be higher.

I've never liked the 'soft constraints' construct, as it's not very
clear.  My distinction was between things we can do *before* calling the
objective function, only on the weights vector, which we'll call
'constraints' and things that we can do only by acting on the set of all
possible weights vectors which satisfy the constraints (the objectives).

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:

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.

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.

> 1. I would also include a turnover objective, whereby there seem to
> be two possibilities:
>
> - provide directly the weights at the time of rebalancing - provide
> the weights at the previous rebalancing data and include a function
> that, uses the return data to calculate the weights at the time of
> rebalancing.

We demonstrated how to use a turnover objective function in our 2012
R/Finance seminar:

http://www.rinfinance.com/agenda/2010/Carl+Peterson+Boudt_Tutorial.pdf

see page 36

with code here:
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/PortfolioAnalytics/sandbox/script.workshop2010.R?root=returnanalytics

It would be nice to get the chart from page 36 into the package if we 
have time later in the summer.

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.

I've always done it as an objective, which works fine in current code.

It would probably be nice to include the turnover function in the 
package directly and document it.

> 2. In practical work,  I work with a price data file that has all
> possible constituents and for each selection date a list of allowed
> constituents. Typically an xts with in row the selection dates and
> columns the assets with 1 if included and 0 otherwise. Such a
> constituents check could be in the constraints object.

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.

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.

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.

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.

Regards,

Brian

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