[GSoC-PortA] structure of the specification objects

[Ross Bennett]

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.

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.

Method 1

   - Create a portfolio object
   - Create a constraint object
   - Add constraints to the constraint object
   - Create an objective object
   - Add objectives to the objective object
   - Add the constraint object and objective object to the portfolio object

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.

The code would look something like this
pspec <- portfolio.spec(assets)
constr <- constraint(pspec)
constr <- add.constraint(constr, "box", min=0, max=1)
obj <- objective(pspec)
obj <- add.objective(obj, type="risk", name="var")
pspec <- update.portfolio(pspec, constr, obj)
optimize.portfolio(pspec)

Method 2

   - Create a portfolio object
   - Add constraints to the portfolio object
   - Add objectives to the portfolio object

The code would look something like this
pspec <- portfolio.spec(assets)
constr <- add.constraint(pspec, "box", min=0, max=1)
obj <- add.objective(obj, type="risk", name="var")
optimize.portfolio(pspec)

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.

Please advise as to the direction I should proceed and any thoughts on this.

Thanks,
Ross Bennett


On Tue, Jun 18, 2013 at 4:28 AM, Brian G. Peterson <brian at braverock.com>wrote:

> 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<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<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
> ______________________________**_________________
> GSoC-PortA mailing list
> 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/20130618/a9fc3f13/attachment-0003.html>