<div dir="ltr">Josh and Brian,<div><br></div><div style>Thank you both for the detailed explanations. It went a long way helping me understand how to improve the efficiency and performance of writing R code.</div><div style>
<br></div><div style>As a first step, I am going to add a formal "moments" argument to constrained_objective. Once I have that working, I am going to take Josh's suggestion of using environments. Using environments in this way is new territory for me so I just want to make sure it works passing moments as an argument.</div>
<div style><br></div><div style>Thanks again!</div><div style><br></div><div style>Ross</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 5:40 AM, Joshua Ulrich <span dir="ltr"><<a href="mailto:josh.m.ulrich@gmail.com" target="_blank">josh.m.ulrich@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>To clarify a point Brian made about how DEoptim creates the objective function call in C: it currently creates the call using the actual SEXP arguments, rather than their names, so it suffers from the same inefficiency that made quantstrat slow on large mktdata objects. Fixing this is on my to-do list.<br>
</div><div class="im"><div><br></div>On Fri, Nov 15, 2013 at 4:51 AM, Brian G. Peterson <span dir="ltr"><<a href="mailto:brian@braverock.com" target="_blank">brian@braverock.com</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 11/14/2013 10:25 PM, Ross Bennett wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think I found the culprit for the slow performance of<br>
constrained_objective. It has to do with the moments being re-calculated<br>
in set.portfolio.moments at each iteration of constrained_objective.<br>
<br>
You can verify this putting a print(str(momentargs)) or browser()<br>
statement at the beginning of set.portfolio.moments.<br>
<br>
Here is a small reproducible example to mimic how the moments are passed<br>
from optimize.portfolio to constrained_objective.<br>
</blockquote>
<br></div>
Well, the whole point was always that those were to be calculated once and then passed in.<br>
<br>
If that was somehow no longer happening (we did significantly rewrite a lot of that code this year), then yes, it would really slow things down.<br>
<br>
<... code removed ...><div><br></div></blockquote></div><div>Recalculating the moments will certainly slow things down, but optimize.portfolio will be faster still if it didn't pass the evaluated moment objects to the constrainted_objective function. This will be especially true for large portfolios. It currently calculates them and puts them in the dotargs list.</div>
<div><br></div><div>optimize.portfolio.R:528</div><div><div> mout <- try((do.call(momentFUN, .formals)) ,silent=TRUE)</div><div> if(inherits(mout,"try-error")) { </div><div> message(paste("portfolio moment function failed with message",mout))</div>
<div> } else {</div><div> dotargs <- mout</div><div> }</div></div><div><br></div><div>Then, as you note below, it passes dotargs as: ... = dotargs, which causes a problem.</div><div><br></div><div>The most efficient solution would create a new environment and assign each element of mout to it, and then also assign any other objects the objective$name function needs to that same environment. Then you could evaluate the call to objective$name (with unevaluated arguments) in that environment.</div>
<div><br></div><div>Look at quantstrat:::ruleProc as an example. I don't create a new environment in that case, but all the objects I need are in the environment of the function calling ruleProc. This is the change that provided a huge speed improvement when mktdata is very large.</div>
<div><br></div><div>As an aside, you can easily see the actual call if you debug the function being called by do.call because it will print: debugging in: <printed call>. Unevaluated arguments will be represented by their name, while evaluated arguments will be represented by their deparsed contents.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
<br>
> You can see that '...' is prepended when the list is constructed in<br>
> fun2. This is why set.portfolio.moments can't find momentargs$mu,<br>
> momentargs$sigma, etc. and has to be recalculated at each iteration.<br>
> So the problem is '...' is actually the first element of the list.<br>
><br>
> Have any of you run into this before? Any suggestions for a fix?<br>
><br></div></blockquote></div><div>I've never run into this before, but the problem is that 'dotargs' is a list and the call sets '...' equal to dotargs. So '...' isn't a pairlist of 4 (mu, sigma, m3, m4); it's a pairlist of one list (dotargs). Your current solution of using the "reuse_moments" argument to control this will work, but it would be cleaner, more straight-forward, and more efficient to avoid it entirely like I describe above.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
> I think we could add a formal "moments" argument to constrained<br>
> objective and pass the moments set in optimize.portfolio to<br>
> constrained_objective directly through the "moments" argument. Is<br>
> there any downside to this approach that I might be overlooking?<br>
<br></div>
No, this sounds like it should work. we control constrained_objective, so being more explicit about what it receives should help.<br>
<br>
Thanks,<br>
<br>
Brian<div><div><br>
<br>
-- <br>
Brian G. Peterson<br>
<a href="http://braverock.com/brian/" target="_blank">http://braverock.com/brian/</a><br>
Ph: <a href="tel:773-459-4973" value="+17734594973" target="_blank">773-459-4973</a><br>
IM: bgpbraverock<br></div></div></blockquote></div></div><div class="gmail_extra"><br></div>Best,<br clear="all"><div>--<br>Joshua Ulrich | <a href="http://about.me/joshuaulrich" target="_blank">about.me/joshuaulrich</a><br>
FOSS Trading | <a href="http://www.fosstrading.com/" target="_blank">www.fosstrading.com</a></div><br><br></div></div>
<br>_______________________________________________<br>
GSoC-PortA mailing list<br>
<a href="mailto:GSoC-PortA@lists.r-forge.r-project.org">GSoC-PortA@lists.r-forge.r-project.org</a><br>
<a href="http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta" target="_blank">http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta</a><br>
<br></blockquote></div><br></div>