[R-SIG-Finance] random portfolios

[Patrick Burns]

I'm coming significantly late to the thread, but I'll throw in a bit of 
my view on the required number of random portfolios to generate.

I think it depends a whole lot on what you are doing.

If you are essentially looking for a p-value, then you'll need a few 
hundred at most.  You shouldn't really care if the p-value is 4.3% 
versus 4.1%, and if you're looking at tiny p-values, then algorithmic 
limitations and the subtleties of what "random" means in the particular 
situation are going to start to have big impacts.

If you are looking at densities, then something like 10,000 portfolios 
is not terrible.  If you are looking at tails, then you want lots more. 
But again, you have lots of model risk in the tails.

Pat

On 20/03/2017 23:21, Brian G. Peterson wrote:
> For this type of problem, I would probably generate one set of random
> portfolios and just reuse that set of feasible portfolios...  My usual
> rule is n-assets + 1-2k feasible portfolios.  You can get a better
> number e.g. from sampling theory, but this should be enough.
>
> Once you have this weights matrix rp, you only need to regenerate rp if
> your universe changes.
>
> Still interested in a more efficient implementation, of course, or we
> can work with you to see if we can find resources to work on it, e.g.
> from academia.
>
> Regards,
>
> Brian
>
> On 03/20/2017 05:28 PM, Kevin Dhingra wrote:
>> Hi Ross,
>>
>> Sure. Even though I have not profiled the bottlenecks quite in detail
>> as of
>> yet, i will give you a decent idea of the problem I am working with. I
>> can
>> have multiple indices with as much as 2000 assets with group, position
>> and
>> turnover limits (Not sure if i can increase the speed by removing
>> constraints and doing rejection sampling later). In order to generate a
>> daily possible set for the market in this case, I was playing around with
>> ~4-5 thousand permutations. Also I think I will end up using the "sample"
>> method because of the type of constraints we have and as you already have
>> mentioned that method is the slowest (takes about 30 times the time using
>> "simplex" for the same constraints). Adding box and position limit
>> constraints are causing it to run a bit slower (but its not a big
>> difference). I can always provide a more thorough analysis of the
>> potential
>> bottlenecks with a lot more detail when I have a chance to start
>> working on
>> translating it to cpp
>>
>> Thank you,
>>
>> On Mon, Mar 20, 2017 at 4:04 PM, Ross Bennett <rossbennett34 at gmail.com>
>> wrote:
>>
>>> Kevin,
>>>
>>> Can you give us a sense of the number of assets in the portfolio and
>>> the constraints? That will help us understand where the potential
>>> bottlenecks are in the random portfolio generation. For example,
>>> generating a set of random portfolios for box and weight constraints
>>> if relatively fast, but adding group or position limit constraints
>>> makes the algorithm more complicated and slower.
>>>
>>> Thanks,
>>> Ross
>>>
>>>
>>> On Mon, Mar 20, 2017 at 2:35 PM, Kevin Dhingra
>>> <kevin.dhingra at appliedacademics.com> wrote:
>>>> Brian,
>>>>
>>>> Thank you for a quick reply. I will soon be working on that problem and
>>>> from what I have played with so far, it is unlikely that for our
>>>> example
>>>> ~2k portfolios will be enough (really hoping it would) to get a good
>>> sense
>>>> of the feasible space and seems like I need to implement an Rcpp
>>>> version
>>> of
>>>> the random portfolios function. I will be happy to collaborate and
>>>> share
>>> my
>>>> code once i get a decent handle on it locally for the purposes of our
>>>> current project.
>>>>
>>>> Regards,
>>>> Kshitij Dhingra
>>>>
>>>>
>>>>
>>>> On Mon, Mar 20, 2017 at 3:17 PM, Brian G. Peterson
>>>> <brian at braverock.com>
>>>> wrote:
>>>>
>>>>> On Mon, 2017-03-20 at 15:09 -0400, Kevin Dhingra wrote:
>>>>>> I have been using the random_portfolios function from the
>>>>>> `PortfolioAnalytics` package to simulate the range of possibilities
>>>>>> for return paths at each step under various portfolio constraints /
>>>>>> mandates for evaluating mutual fund managers. As more managers are
>>>>>> added to the universe, however, and more simulations are needed, the
>>>>>> pure R implementations get pretty heavy and hard to scale. I was
>>>>>> wondering if there has been any work out there thus far on
>>>>>> implementing any of the three random portfolio generation methods
>>>>>> (sample, simplex, and grid search) at a lower level, using something
>>>>>> like `Rcpp` to enhance the efficiency of these algorithms?
>>>>>
>>>>> We've discussed it, but I can't say that it is terribly high on our
>>>>> list of priorities.
>>>>>
>>>>> In most cases, no more than 1-2k portfolios should be required to
>>>>> get a
>>>>> fair view of the feasible space given your constraints and objectives.
>>>>>
>>>>> We'd be happy to work with you if you want to craft a patch to use
>>>>> C or
>>>>> Rcpp for this.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Brian
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Kshitij Dhingra
>>>> Applied Academics LLC
>>>> Office: +1.917.262.0516
>>>> Mobile: +1.206.696.5945
>>>> Email: kshitij.dhingra at appliedacademics.com
>>>> Website: http://www.AppliedAcademics.com
>>>>
>>>>         [[alternative HTML version deleted]]
>>>>
>>>> _______________________________________________
>>>> R-SIG-Finance at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>>>> -- Subscriber-posting only. If you want to post, subscribe first.
>>>> -- Also note that this is not the r-help list where general R questions
>>> should go.
>>>
>>
>>
>>
>
>

-- 
Patrick Burns
patrick at burns-stat.com
http://www.burns-stat.com
http://www.portfolioprobe.com/blog
twitter: @burnsstat @portfolioprobe