[GSoC-PortA] structure of the specification objects

Wed Jun 19 03:35:50 CEST 2013

All,

I have made a series of commits this evening to add constraint objects and
objective objects to a portfolio object. See the file
sandbox/testing_portfolio_specification.R for a demonstration of how it
works. Now that I have fully working portfolio object, I think we are at a
pretty good point with the framework for creating the portfolio
specification object for feedback on the good parts and the bad parts.

I look forward to your feedback.

Regards,
Ross Bennett

On Tue, Jun 18, 2013 at 11:17 AM, Ross Bennett <rossbennett34 at gmail.com>wrote:

> 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/dbf29983/attachment-0003.html>