[GSoC-PortA] mapping function

[Doug Martin]

Brian,

Thanks for your helpful comments below.  It is fortunate that we will be
meeting in a couple of weeks, and can discuss in more detail then.

Meanwhile, I am going to concentrate on the "standard" stuff that is needed
for the first few chapters of the 2nd edition.

Doug

P.S. When do you head to Alaska?


-----Original Message-----
From: gsoc-porta-bounces at lists.r-forge.r-project.org
[mailto:gsoc-porta-bounces at lists.r-forge.r-project.org] On Behalf Of Brian
G. Peterson
Sent: Monday, July 08, 2013 5:00 AM
To: gsoc-porta at r-forge.wu-wien.ac.at
Subject: Re: [GSoC-PortA] mapping function

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
_______________________________________________
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