[GSoC-PortA] mapping function

[Brian G. Peterson]

On 07/08/2013 12:51 PM, Doug Martin wrote:
> 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.

It would be helpful to have a list, especially of anything that differs 
from the first few chapters of the first edition.

> P.S. When do you head to Alaska?

I fly to seattle on Saturday, and Will be essentially out of contact, 
except for occasional moments in a wifi coffee shop, from Sun-Sun.  I 
arrive back in Seattle Sunday the 21st in the AM.

Regards,

Brian



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


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