[GSoC-PortA] structure of the specification objects

Thu Jun 20 05:41:07 CEST 2013

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Monday, June 17, 2013 12:36 PM
To: PortfolioAnalytics
Cc: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] structure of the specification objects

See comments inline below.

Regards,

Ross Bennett

On Mon, Jun 17, 2013 at 1:17 PM, Doug Martin <martinrd at comcast.net> wrote:

Ross and Brian,

Ross, have you or Brian had a chance to take  a careful look at the code
(attached) that Kirk Li developed for my class this spring to see if the
ideas there may be useful?

I have gone through the code from Kirk Li, but will take closer look to make
sure I did not miss anything.

I note that add.constraint needs to check for compatibility with the
existing constraint object, and give a sensible message if not.  See for
example the segment "# sum constraint are not combinable with propcost
constraint"  just below Scenario 10  in the attached constraint.sets.test.r.

The way Kirk's code checks for compatibility constraints should be helpful
and hopefully I can borrow some of the ideas.

At the moment I have forgotten what the constraint set conventions are in
PortfolioAnalytics, and will look at it again on Wed.  But I think we need
the something like the types that are in constraint.sets.r attached.  Ross,
since you have seen these before in computing homework problems, so you may
already have some thoughts about this?

The way that constraints.sets.R handles the constraints is similar to
PortfolioAnalytics in that the different constraints are stored in a list
object. The main differences I see is how the constraints are combined and
passed to the solver. The different functions for the constraints such as
cset.box() and cset.lo() do a lot of work setting up the A matrix and b
vector for solve.QP(). 

[Doug] Indeed.

In PortfolioAnalytics, this is handled inside of optimize.portfolio() and
handled differently based on the chosen optimizer. 

[Doug] I need to look at optimize.portfolio again

In Kirk Li's code, all of the constraints are fed into gmv(), which if I
recall correctly is just a wrapper around solve.QP(). So this means the
constraints are pretty specific to one solver. The way the constraints are
specified in PortfolioAnalytics currently, the same constraint object can be
passed to the DEoptim, ROI (Rglpk and quadprog), Random Portfolios, pso, and
GenSA solvers. 

[Doug] In the next few days I'll look at the way it is done in PA.  However,
I seem to recall that neither general linear inequality constraints or group
constraints were supported.  Am I recalling correctly?  If so we need to
agree on a convention for doing so.  For the case of general linear
inequality constraints I like the convention of specifying equalities and
inequalities in Rglpk_solve_LP.  Let's get this convention agreed upon and
then move on to the groups constraints.

Also, I seem to recall that at the end of last summer there was still a
problem in calling solve.QP and Rglpk_solve_LP, and it involved having to
use ROI and create a mapping from the PortfolioAnalytics to the solve.QP and
Rglpk_solve_LP conventions.  Brian do you recall the situation as of the end
of last summer (I think you had thought a bit about fixing this small
problem)?

Doug

FYI, in the 2nd edition MPO2 of the MPO book I intend to briefly use
solve.QP and Rglpk_solve_LP for a little bit in the first computing chapter,
but then quickly move to PortfolioAnalytics for everything we do that will
be supported by PortfolioAnlytics.  The goal is that MPO2 will equally well
support instructional pedagogy and real-world applications use.

Very cool that you plan on using PortfolioAnalytics in the 2nd edition of
your book!

Doug

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Monday, June 17, 2013 10:27 AM

To: PortfolioAnalytics
Cc: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] structure of the specification objects

All,

With finals being over (for me at least, I do realize that Prof. Yollin and
Prof. Martin still have grading) I am anxious to get started today with the
first day of coding. 

When I am writing or editing code, should I be working directly in the
PortfolioAnalytics/R files or should I work in the sandbox folder so that I
have a safe area to "play" without worrying about messing up existing code?

With the recent discussions of separating the objectives from the
constraints and adding a portfoliospec object, here is a list of
functions/features I am proposing to add to accomplish this.

constraint_v2()

*	Constraints object constructor as an S3 object that will hold the
constraints. Similar to the current constraints_v1 object, but will keep
separate from objectives.

add.constraint()

*	Helper function to add constraints to the constraint_v2 object such
as box, group, etc. constraints.

box_constraint()

*	Function to be called by add.constraint that will set minimum and
maximum weight for box constraints

group_constraint()

*	Function to be called by add.constraint that will set minimum and
maximum group weights for group constraints

objective_v2()

*	Objective object constructor as an S3 object that will hold the
objectives. Similar to the current constraints_v1 object, but will be
separate from constraints.

add.objective()

*	Helper function to add objectives to the objective object.

Note that there is currently an objective constructor of class=objclass and
add.objective() function. These currently update the constraints_v1 object
with the objectives. I should be able to re-use most of these and make
revisions so that they update the objectives object.

portfoliospec()

*	Portfolio specification constructor that holds the constraints and
objectives. A constraint_v2 object and objective_v2 object will be passed in
to create the portfoliospec object.

may need additional helper functions for portfoliospec that do checks on the
portfoliospec and/or the constraints and objectives objects that are passed
in.

optimize.portfolio() will have to be modified so that it takes in a
portfoliospec object instead of a constraints object.

Thoughts?

Ross Bennett

On Mon, Jun 17, 2013 at 9:57 AM, Doug Martin <martinrd at comcast.net> wrote:

Brian and Ross,

I couldn't agree more with the proposal to separate constraints and
objectives (Brian, as you and I have discussed earlier this year or last
year).

I will have further comments on checking validity of adding constraints late
tomorrow or early Wed. after I have completed grading of my spring quarter
course.

Doug

From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Ross
Bennett
Sent: Monday, June 17, 2013 7:09 AM
To: PortfolioAnalytics
Cc: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] structure of the specification objects

Brian,

I really like your thoughts on separating constraints and objectives. I
learned objectives and constraints in the same way that you mention them.
Intuitively, it is easier to understand that the user would create the
constraint object, the objective object, and then combine in a portfolio
object.

Separating out the objectives and creating templates of objectives for
minimum variance and other basic objective functions should make it easy to
understand for the user as well how it is handled with the solvers.

The way the constraints object looks today seems to be very similar to what
you have in mind for the portfoliospec object. Was that your intent so that
the solvers see pretty much the same  object in the call to
optimize.portfolio? Only now the portfoliospec object will be passed instead
of the constraints object, is my understanding of your intentions correct?

This is what I am thinking the code will look *something* like to run a
simple optimization problem.

#### Example R code

# Specify a constraints object and add box constraints

gen.constr = constraint(assets, min_sum=1, max_sum=1)

gen.constr = add.constraint(gen.constr, min_weight=0.10, max_weight=0.4,
type="box")

# Specify an objective object for global minimum variance

gen.obj = objective(type="GMV")

# Specify a portfolio object

port.spec = portfoliospec(gen.constr, gen.obj)

# Run the optimization

solution = optimize.portfolio(data, port.spec)

#####

Thanks,

Ross Bennett

On Mon, Jun 17, 2013 at 6:51 AM, Brian G. Peterson <brian at braverock.com>
wrote:

I've been thinking a lot about this over the last week, and I'm going to
propose an architecture for discussion.

Right now, we have an object of type 'constraints' which also includes
'objectives'.

I have always logically separated objectives from constraints in my head by
saying that
- constraints are something that are:
  1. operable only on the weight vector and
  2. metadata information about the portfolio (e.g. groups, asset names)
  3. describe the *inputs* to the objective function

- objectives are part of the *objective function* that
  1. you calculate on the weight vector
  2. describe business objectives for the *outcome* of the optimization

I think we need to split these apart explicitly, and make the distinctions,
and why they exist, more obvious to the user.

First, I think we need a container object of type 'portfolio' or
'portfoliospec' that know what assets you have, and how you want to group
them (e.g. sectors, size, whatever).  This is data about the portfolio, and
is *independent* of and constraints or objectives you might have on that
portfolio.

Next, I think we need a constraints object.  Constraints, by their nature,
are tied to the portfolio that they are created for.  They require knowledge
of the portfolio metadata, or at the very least things like box constraints
are typically derived from the size of the portfolio.

Finally, I think we need a separate 'objectives' object.  To have objectives
objects, with names, that specify things like minimum variance, maximum
Sharpe ratio, or risk parity objectives.  These can be completely separate
from the assets in the portfolio, and we could provide a number of template
objective objects with the package.  I think the current way objectives are
added and manipulated is fine, we just need to break it off a bit.

For the template objectives that can be acted on by specific more efficient
solvers, I think separating the objectives out will make it easier to
identify that.

optimize.portfolio needs all three of these components, even today, to do
anything.  So I think we need to sort out how to specify them, then how to
combine them.

I suggest that we start by getting these specifications right first. Then we
can start surgery in other parts of the code to use the new specification
forms.

My current thoughts are that a portfolio *contains* one or more constraints
objects, since the constraints objects are dependent on the portfolio
composition.  Then you optimize a portfolio by passing a portfolio
specification into the optimizer, and telling it which constraints object to
use (if you have more than one attached to the portfolio) and what
objectives object you want to apply.

Hopefully this is clear.  It's a proposal, so comments/critique/ideas always
welcome.

Today is officially the first day of coding, so we need to get moving.

Regards,

Brian

On 06/06/2013 06:54 AM, Ross Bennett wrote:

Professor Martin,

Thank you for the feedback. Based on the suggestions from yourself and
Brian Peterson, I will start with the constraints portion. I'll spend
some more time looking at Kirk Li's code to understand it better and
think about how to best integrate into PortfolioAnalytics. I should be
able to use some ideas from it.

I have been reviewing the code for PortfolioAnalytics and it seems that
there is already a lot of the infrastructure in place for the constraint
object and the optimizer so I don't want to maintain the interface to
the optimize.portfolio function as much as possible.

As an example, here is a code snippet of how box constraints and group
constraints are currently specified.
# General constraints object
# Box constraints of minimum weight = 0.1 and maximum weight = 0.5 for
assets
gen.constr <- constraint(assets = colnames(edhec), min=0.1, max =0.5,
min_sum=1, max_sum=1)

# Add group constraints to the gen.constr object
groups <- c(3,3,3,4)
gen.constr$groups <- groups
gen.constr$cLO <- rep(0.15,length(groups))
gen.constr$cUP <- rep(0.30,length(groups))

Following the outline on the GSOC2013 PortfolioAnalytics rwiki page, we
would remove box constraints from the constraint() function and create
an add.constraint() function to add/update box, group, and other
constraint types as applicable.

# Create the initial constraint object
# Pass in a character vector of asset names for assets
# Portfolio weights must sum to 1 (min_sum=1 and max_sum=1)
gen.constr <- constraint(assets = colnames(edhec), min_sum=1, max_sum=1)

# Add box constraints with asset weights greater than 0.1 and less than 0.5
gen.constr <- add.constraint(constraints=gen.constr, type="box",
                                           min=0.1, max=0.5)

# Group constraints for 10 assets
# Separate assets into groups of 3, 3, and 4 assets
# Specify the group weights as a vector
# The first 3 assets shall have a group weight of greater than 0.15 and
less than 0.3
# The next 3 assets shall have a group weight of greater than 0.1 and
less than 0.35
# The last 4 assets shall have a group weight greater than 0 and less
than 0.4
constr <- add.constraint(constraints=constr, type="group",
                                     groups=c(3, 3, 4),
                                     group_min=c(0.15, 0.1, 0),
                                     group_max=c(0.3, 0.35, 0.4))

This keeps the constraint object and interface to optimize.portfolio()
consistent with the existing code, but simplifies it and makes adding
box and group constraints very similar.

I will continue to review the PortfolioAnalytics source code and we can
revisit this so that I can hit the ground running when finals are over
and start as soon as possible.

Regards,
Ross Bennett

On Wed, Jun 5, 2013 at 9:23 AM, Doug Martin <martinrd at comcast.net
<mailto:martinrd at comcast.net>> wrote:

    Ross and all,____

    __ __

    I think starting with the constraints is a good idea.  But I think a
    review of where PortfolioAnalytics functionality is as of last
    year's GSoC should be the first priority.  How planning on that week
    after next (Guy, Eric and I all have finals week to get out of the
    way next week).____

    __ __

    With regard to constraints, that approach that Kirk Li (UW
    Statistics Ph.D. student and AMATH 543 TA this spring) developed
    looks useful.  Ross you already have the code which I posted to the
    class web site.  I have attached it here for others on this project
    to have a look at.   Let's review that after the end of next week
    when final exams and the spring quarter are completely behind us.____

    __ __

    Doug____

    __ __

    __ __

    *From:*gsoc-porta-bounces at lists.r-forge.r-project.org
    <mailto:gsoc-porta-bounces at lists.r-forge.r-project.org>
    [mailto:gsoc-porta-bounces at lists.r-forge.r-project.org
    <mailto:gsoc-porta-bounces at lists.r-forge.r-project.org>] *On Behalf
    Of *Ross Bennett
    *Sent:* Wednesday, June 05, 2013 4:22 AM
    *To:* gsoc-porta at lists.r-forge.r-project.org
    <mailto:gsoc-porta at lists.r-forge.r-project.org>
    *Subject:* [GSoC-PortA] Schedule for PortfolioAnalytics Coding____

    __ __

    All,____

    __ __

    In my GSOC proposal, the order of what components I planned to write
    code for was as follows:____

     1. Utility Functions (print, summary, plot, etc.)____
     2. Constraints____
     3. Example Functionality____

    In speaking with Brian Peterson at R/Finance, he suggested that the
    constraints portion be done first. I am fine with doing constraints
    first. Would you like me to submit a revised schedule and
    implementation plan with constraints first?____

    __ __

    Thanks,____

    Ross Bennett____

_______________________________________________
GSoC-PortA mailing list
GSoC-PortA at lists.r-forge.r-project.org
http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta

_______________________________________________
GSoC-PortA mailing list
GSoC-PortA at lists.r-forge.r-project.org
http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta

_______________________________________________
GSoC-PortA mailing list
GSoC-PortA at lists.r-forge.r-project.org
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/20130619/caf6ab89/attachment-0003.html>