<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><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 class="gmail_extra"><div class="gmail_quote">
<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 class="im">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 class="im"><br></div></blockquote><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><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 class="im">
<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>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><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 class="im">
> 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 class=""><div class="h5"><br>
<br>
-- <br>
Brian G. Peterson<br>
<a href="http://braverock.com/brian/" target="_blank">http://braverock.com/brian/</a><br>
Ph: 773-459-4973<br>
IM: bgpbraverock<br></div></div></blockquote></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>