[GSoC-PortA] structure of the specification objects
Ross Bennett
rossbennett34 at gmail.com
Mon Jun 17 19:26:37 CEST 2013
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/gsoc-porta/attachments/20130617/dd4000d6/attachment-0003.html>
More information about the GSoC-PortA
mailing list