cgroll / ModernPortfolioTheory

This is the common repository for the LMU course "Modern Portfolio Theory with Matlab"
1 stars 6 forks source link

portfolio re-balancing and transaction costs #18

Open cgroll opened 10 years ago

cgroll commented 10 years ago

for given historic investments, get intended portfolio re-balancing and actually required transactions (example: choosing equal weights for the complete period results in zero intended re-balancing, but some required transactions to keep weights equal despite of different stock movements)

cgroll commented 10 years ago

@mffuser I do not get the intention behind the following code block:

% either daily rebalancing or not!!!
% not assuming daily rebalancing
portReturns = zeros(size(returns,1),1);
portReturns(1) = CalcPR(returns(1,:), weights(1,:));
for ii = 1:size(returns,1)
    weightsDueToPriceChanges(ii,:) = weights(ii,:).*(1+returns(ii,:))/(1+portReturns(ii));
    if ii<size(returns,1)
        portReturns(ii+1) = CalcPR(returns(ii,:),weightsDueToPriceChanges(ii,:));
    end
    % add something like if some event then rebalance
end

% create return struct
structValues = struct('newWeights', weightsDueToPriceChanges, 'rebalanceAmount'...
    ,dailyOVerallRebalancing, 'portReturns', portReturns);

It seems to me like if you would try to both calculate the transactions and apply a re-balancing strategy (how often to re-balance) in one function?! I'd propose to stay modular here: this function should get a completely defined weight matrix (strategy was already applied), and get the associated intended turnover (from one portfolio within the weight matrix to the next) and the actually required daily and overall turnover (where weight changes due to price changes are taken into account). For example, for a strategy of equal weights, the intended turnover would be zero, since we would like to keep equal weights all the time, however, the actual turnover will be positive due to daily re-balancing.

cgroll commented 10 years ago

@mffuser also, it seems like if the function should be applicable to both tables and matrices. In the first line you call function CalcPR, but I think this function is only allowed for tables yet. I like the idea of being flexible to tables and matrices (simulated data could well come as matrix sometime), but then you either need to make sure that CalcPR is always called with tables nevertheless, or you add this feature to CalcPR. Checking all allowed input structures to a function is something that quite perfectly can be done with unit tests ;-)