[GSoC-PortA] mapping function

[Brian G. Peterson]

On 07/06/2013 03:27 PM, Ross Bennett wrote:
> I'm sure Brian will provide more detail, but hopefully this will provide
> some initial clarification about random portfolios and the logic I am
> using in rp_transform().
>
> The random portfolio weights are being generated with a user specified
> leverage constraint, min_sum and max_sum. One could generate a dollar
> neutral portfolio by specifying min_sum=-0.01 and max_sum=1.01 or a
> leveraged portfolio with min_sum=1.49 and max_sum=1.51. I think this
> gives more flexibility than the method proposed by Shaw.

> I need to spend some more time understanding the Shaw (2011) paper, but
> it is unclear to me if Shaw's method will work if we want to specify
> constraints such as min=c(0.05, 0.12, 0.15, 0.05, 0.08) and max=c(0.85,
> 0.92, 0.73, 0.75, 0.82) or if it only works for box constraints where
> all the values of min and max are equal.

Shaw's approach is quite interesting, but I think it is also rather 
limited in the types of constraints he examines.

Also, the 'reject everything that doesn't meet the constraints' approach 
isn't practical, in my opinion.  Perhaps in C/C++ code, but even then, 
as the number of assets increases (all his examples are toy ones), the 
number of non-conforming portfolios will also increase.

Doug asked elsewhere on this thread for a concise description of how the 
random portfolios code worked before Ross started improving things (and 
all his changes looks like an improvement to me so far).

___________________________________________________________________

So, the original algorithm, developed by trial and error from my notes 
of a private conversation with Pat:

- generate a uniform random draw satisfying box constraints
   for all assets

- check to see if it is feasible (leverage constraints)
   + assuming it is not feasible,

     randomly choose one weight from the weights vector

     do another random draw for that weight that is larger or smaller 
than the original
     draw to move the portfolio closer to the leverage constraint

^
\--return to check to see if the portfolio is feasible

The Burns-style method 'walks' the portfolio closer to the edges of the 
feasible space, one weight at a time.

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.
______________________________________________________________________

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


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.

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.

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.

Regards,

   - Brian

-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock