<br><br><div class="gmail_quote">
On Mon, Jul 8, 2013 at 6:59 AM, Brian G. Peterson <span dir="ltr"><<a href="mailto:brian@braverock.com" target="_blank">brian@braverock.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The Burns-style method 'walks' the portfolio closer to the edges of the feasible space, one weight at a time.<br>
<br>
It's obviously a bit more complicated than this, but not much.  I think it would be good to add a complete outline of the modified algorithm to the documentation once we're happy with the approach.<br></blockquote>
<div><br></div><div>I started working on a mapping function vignette that will document the process of the mapping function and outline the algorithm for rp_transform.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Also elsewhere in this thread was a discussion of transforming the entire vector to meet the leverage constraint.  While this 'works', it has two drawbacks.  The first is that you may then violate the box constraints.  The second is that you will be further from the edges of the feasible space.  It may make sense to write a simple test script  on 50,100,200,500 assets that either transforms one asset at a time, or *first* transforms the entire vector, and then transforms individual assets<br>
</blockquote><div> </div><div>I will write the simple test script per your comments to compare the two methods. I agree with you that the major downside is that the box constraints will likely be violated. it is also likely that group constraint will be violated and the weights vector will just have to be transformed again to satisfy the constraints.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Shaw's reliance on vertex combinations between pairs of assets doesn't seem as useful to me as the number of assets increases, but perhaps it's only because it has been 20 years since I stared at Mathematica code.<br>


<br>
Overall, I'd like to implement the Shaw methods, but I'd like that to be secondary to getting something that works which has the flexibility to handle all the constraint types we've identified.<br></blockquote>
<div> </div><div>Over the weekend I wrote a script to replicate the results in section 4.5 and 5.1 of the Shaw 2011 paper and I got results that were very close to his. I put the script in the sandbox folder and named it rp_shaw.R. It would be interesting to include the Shaw method with the caveat to the user that it only works for limited constraints. I'll shelve this until later.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So far, I think the progress on fn_map has been phenomenal.  For Random Portfolios or DEoptim, this should give us what we need to have feasible portfolios with any sort of layered constraints.  We'll need to integrate the use of fn_map into constrained_objective for solvers that don't specify all the constraint types.  I'll try to spend some time outlining that later today.<br>
</blockquote><div> </div><div>Looking forward to seeing your outline of integrating fn_map into constrained_objective... it's interesting seeing the pieces come together. Are you happy with where fn_map is at for now or are there any more changes you would like to see?</div>
<div><br></div><div>Thanks,</div><div>Ross</div></div>