[GSoC-PortA] Finishing Touches to PortfolioAnalytics

[Ross Bennett]

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/7b4d5641/attachment.html>