[GSoC-PortA] Finishing Touches to PortfolioAnalytics

Ross Bennett rossbennett34 at gmail.com
Wed Feb 5 15:54:39 CET 2014


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/20140205/9a11542d/attachment.html>


More information about the GSoC-PortA mailing list