[GSoC-PortA] Finishing Touches to PortfolioAnalytics

[Doug Martin]

Got it and will take a look tomorrow or on the weekend.

 

Thanks,

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: Thursday, February 20, 2014 11:27 AM
To: PortfolioAnalytics
Subject: Re: [GSoC-PortA] Finishing Touches to PortfolioAnalytics

 

All,

 

I am working on adding functionality to accept a list of portfolio objects
for optimize.portfolio and optimize.portfolio.rebalancing.

 

I added a block of code at the beginning of optimize.portfolio and
optimize.portfolio.rebalancing to detect a list of portfolio objects and
then loop through each portfolio in the list of portfolios and recursively
call optimize.portfolio or optimize.portfolio.rebalancing. I have a return
statement at the end of that block of code. Some frown upon multiple return
statements in a function, is it ok that I do this here or is there a
different approach I should follow.

 

I also added demo/multiple_portfolio_optimization.R so you can test out the
functionality.

 

I just committed my changes with r3318.

 

Ross

 

 

On Wed, Feb 5, 2014 at 6:54 AM, Ross Bennett <rossbennett34 at gmail.com>
wrote:

Makes a lot more sense from that perspective to avoid making
optimize.portfolio and optimize.portfolio.rebalancing S3 generic methods.
I'll proceed as you have outlined.

 

Thanks for the clarification and guidance.

 

Ross

 

 

On Tue, Feb 4, 2014 at 11:29 PM, Brian G. Peterson <brian at braverock.com>
wrote:

On 02/02/2014 10:25 PM, Ross Bennett wrote:

    Enhance the print and summary methods for
    optimize.portfolio.rebalancing. Currently, a list of

    optimize.portfolio objects at each rebalance period is returned.____

    */[Doug] So does that imply one can now input a list of portfolio


    optimization strategy objects to "optimize.portfolio.rebalancing",
    e.g., each with different constraints and different objectives?

    (this would be very useful)/*




No, that is currently not possible, but should not be too hard to
implement. I could do this for optimize.portfolio as well. I think the
most robust way to implement this would be to make optimize.portfolio()
and optimize.portfolio.rebalancing() generic methods.

This would require a few minor design changes and I don't think it would
break backwards compatibility. We would have to change the order of
arguments for optimize.portfolio() and optimize.portfolio.rebalancing()
so that 'portfolio' is the first argument, currently 'R'  is the first
argument.


I think the desired functionality (take a list of portfolio objects) is a
good idea.

I don't think relying on S3 dispatch and making optimize.portfolio.* into S3
generics makes sense though.

I say this because there's far too much shared code.  The sub-functions for
the different optimizer methods and special cases are far less code than the
wrapper/framework function.  I wouldn't want to duplicate all that code, or
add a bunch of extra function calls in code that's called lots and lots of
times.

Also, I *really* hate breaking backwards compatibility by rearranging
arguments unless there's a compelling reason.  For R generics like
print/plot/summary, using S3 dispatch is the obvious and only answer, but
for optimize.portfolio.*, I'd say leaving the arguments list alone makes the
most sense.

I think you could add the loop over portfolio specification list elements
(if it is a list) and collection of the results into a list of optimization
results into the optimize.portfolio.* functions without too much work, and
without breaking existing code.

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
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/20140220/82113d6a/attachment.html>