[GSoC-PortA] Incorporating New Portfolio Object

[Ross Bennett]

Brian,

Thanks for the insight and thoughts into making fn_map work with
constrained_objective.

Just to clarify a few points and make sure my understanding is correct. I
am mainly thinking in terms of how this will apply to DEoptim and random
for optimize methods.

constrained_objective is the "fn" argument to DEoptim. The function "fn"
needs to return a single argument, which in our case is the return value
from constrained_objective, out. The store_output object is useful for us
to track the weights vector before and after it is transformed at each
iteration, but does not affect the optimization.

The transformed weights from the output of fn_map will be used to calculate
the objective measures and the return value, out. Does the optimizer, e.g.
DEoptim, keep track of the adjusted weights or the original weights?

Thanks,
Ross

On Thu, Jul 11, 2013 at 12:13 PM, Brian G. Peterson <brian at braverock.com>wrote:

> 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
> ______________________________**_________________
> 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/20130711/1cb50302/attachment.html>