[GSoC-PortA] Incorporating New Portfolio Object

[Brian G. Peterson]

On 07/10/2013 07:54 PM, Ross Bennett wrote:
> I'd like to begin work on making changes to the code to accept the new
> portfolio object. My plan is to first make the changes to
> constrained_objective, optimize.portfolio, and random_portfolios to
> accept a portfolio object instead of a constraint object. I'll make "v2"
> versions of the functions so that I can test against the current
> versions. If our next step is to integrate the mapping function into
>   constrained_objective, I think it would be good to have a working
> version of constrained_objective that accepts a portfolio object because
> fn_map also accepts a portfolio object.
>
> Is this a good time to make these changes? Any thoughts/concerns?

As I already said in a private email, and as Ross has already started 
doing, I think we're in a good position to move forward to the _v2 steps 
that Ross has proposed.

I promised to talk about integrating fn_map into constrained_objective().

There are a handful of potential pitfalls from modifying the weights 
vector inside the objective function.

The largest of these is that the optimizer won't know what the 'real' 
weights (parameters) vector is.  A related pitfall is that we need to 
know what the 'right' (adjusted) weighs vector is after we adjust it.

The solution to this lies in the 'store_output' option.  If store_output 
is TRUE, constrained_objective() will store the (transformed/adjusted) 
weights vector.

That is just a list.  We'd need to add a slot to that list for the 
un-transformed weights vector, but that's about it.  (feel free to add 
anything else you think might be useful too).

on line 95 of the current code (constrained_objective.R r2538), on line 
95, starts a block for the fn parameters 'normalize'.  I think that 
integrating fn_map means replacing the body of the if block from line 95 
to the else clause on line 118 can be replaced with an appropriate call 
to fn_map.

Some additional wrinkles:

optimize.portfolio.rebalancing:
the environment for storing the extra output will exist on each of the 
workers, we'll need to write a custom .combine function for foreach to 
collect all the extra info and put it in the master process' 
environment, but we can cover that after it works for the main case.

DEoptim (in parallel mode):
DEoptim's parallel mode may also need a custom .combine function for its 
calls to foreach.

Other:
As a reminder, I'll have very limited access to email from Sun Jul 14th 
to Sun Jul 21st.  From the 21st-224th I'll be spending time with Doug 
and Guy, and expect to spend a lot of time talking and thinking about 
PortfolioAnalytics.

Regards,

Brian


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