[GSoC-PortA] Finishing Touches to PortfolioAnalytics
Ross Bennett
rossbennett34 at gmail.com
Fri Apr 11 22:51:14 CEST 2014
A brief update.
I've been in communication with Martin Pacala and Stefan Theussl at R-Forge
regarding this error and we were not able to find out exactly where the
error is coming from or how to fix it. Stefan added PortfolioAnalytics to
the Windows and Linux stop list only for the building vignettes part and
the build status is now current on R-Forge.
Ross
On Wed, Apr 2, 2014 at 9:00 AM, Ross Bennett <rossbennett34 at gmail.com>wrote:
> I sent an email to R-Forge at R-Project.org in the beginning of March and
> have yet to hear back so I sent a follow up email on Monday. I spent some
> time earlier in the week trying to figure out where this error is coming
> from and still am unable to replicate the error we are getting on R-Forge.
> I heard back from someone yesterday, so hopefully we can get this taken
> care of.
>
> I suppose an option is to leave the .Rnw files in the vignettes/ folder,
> move the .pdf files to inst/doc/ and add 'BuildVignettes: false' to the
> DESCRIPTION file.
>
> Ross
>
>
> On Mon, Feb 24, 2014 at 11:16 AM, Brian G. Peterson <brian at braverock.com>wrote:
>
>> I'm guessing the vignettes might just take too long for R-Forge. We
>> should ask them to see if they have any other data. I had no trouble
>> building it here from the command line and RStudio.
>>
>> Brian
>>
>>
>> On 02/24/2014 11:23 AM, Ross Bennett wrote:
>>
>>> All,
>>>
>>> PortfolioAnalytics is not building on R-forge and part of the error
>>> message is shown below.
>>>
>>> Error: processing vignette 'risk_budget_optimization.Rnw' failed with
>>> diagnostics:
>>> subscript out of bounds
>>> Execution halted
>>> Run time: 437.89 seconds.
>>>
>>> However, when I run R CMD Check, the R code in the vignettes runs
>>> successfully so I am not sure how to address this error or if there is
>>> something else I am missing. I also tried building the vignette in
>>> Rstudio with the 'compile pdf' button and it compiled successfully. For
>>> your reference, I am attaching the 00check.log file.
>>>
>>> Ross
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 10:48 AM, Doug Martin <martinrd at comcast.net
>>> <mailto:martinrd at comcast.net>> wrote:
>>>
>>> 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>
>>> [mailto: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 <mailto: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 <mailto: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 <tel:773-459-4973>
>>> IM: bgpbraverock____
>>>
>>>
>>>
>>> _______________________________________________
>>> GSoC-PortA mailing list
>>> GSoC-PortA at lists.r-forge.r-project.org
>>> <mailto:GSoC-PortA at lists.r-forge.r-project.org>
>>> http://lists.r-forge.r-project.org/cgi-bin/mailman/
>>> listinfo/gsoc-porta____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>>
>>>
>>> _______________________________________________
>>> GSoC-PortA mailing list
>>> GSoC-PortA at lists.r-forge.r-project.org
>>> <mailto:GSoC-PortA at lists.r-forge.r-project.org>
>>>
>>> http://lists.r-forge.r-project.org/cgi-bin/mailman/
>>> listinfo/gsoc-porta
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>> --
>> 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/20140411/6f908e80/attachment.html>
More information about the GSoC-PortA
mailing list