2
$\begingroup$

I'm computing downside market capture ratio in R. The PerformanceAnalytics R package has a built-in UpDownRatios function which does this, but it computes the ratio using sums of returns, not products.

Since the ratio is the "compound return when the benchmark was down divided by the benchmark's compound return when the benchmark was down", shouldn't that be product?

$\endgroup$
  • 3
    $\begingroup$ Maybe it is expecting log returns? $\endgroup$ – msitt Apr 12 '17 at 23:22
  • $\begingroup$ @msitt Perhaps. So you agree that, if you assume arithmetic returns, the use of sums of incorrect? $\endgroup$ – lebelinoz Apr 13 '17 at 4:05
  • 1
    $\begingroup$ Interesting point, I contacted the maintainer of the package, let's see what he has to say about the issue. $\endgroup$ – vonjd Apr 14 '17 at 8:57
2
$\begingroup$

I am not familiar with that R package, but I've written a few performance tracking libraries in my past life, so I might be able to add some insight.

While it is indeed true that logarithmic returns may be added and subtracted, all non-quant investors and hedge funds present their performances in percent returns. The reason one can't simply add and subtract percent returns is because the denominators changes instantaneously.

For a Numeraire, $\mathbb{N}_t$ representing one's bank account, the wealth process may evolves as such:

$\frac{\mathbb{N}_{t}}{\mathbb{N}_{t-1}} = (1 + m_{t-1}) =e^{ \mu_{t-1}} \approx e^{m_{t-1} - \frac{\sigma^2}{2}} $

where: $m_t$ is the geometric rate of return; $\mu$ is logarithmic rate of return; and, $\sigma^2$ is the variance of $\mathbb{E}[\mu]$.

If you're programming is taking the sum of percent returns, then clearly it will result in the following inequality:

$$(\sum_{t}^{T} m_t) +1 \ne \frac{\mathbb{N}_{T}}{\mathbb{N}_{t}}$$

You are correct, however, about the following equality:

$$\prod_{t}^{T}( 1 + m_t) = \frac{\mathbb{N}_{T}}{\mathbb{N}_{t}} = e^{\Sigma_t^T \mu_t}$$

If changing something about the source code is too onerous, there are two options which will get you the same result:

Option A: convert the percent return to natural logs through the following:

$\mu_t = ln(1+m_t) \, , \forall t \in T $

And then convert them back to percents in the final step:

$m_t = e^{\mu_t} -1 \, , \forall t \in T $

Option B: take the ratios of the compounded periodic returns as such

$\frac{\prod_{t}^{T}( 1 + m_t)}{\prod_{0}^{t-1}( 1 + m_t)}$

|improve this answer|||||
$\endgroup$
2
$\begingroup$

David Addison's discussion of log versus simple(arithmetic) returns in his answer is correct, but this particular calculation has nothing to do with arithmetic versus log returns.

Up Capture is defined by Bacon(2004), p. 47 as:

$$Up Capture = \frac{\bar{r+}}{\bar{b+}} $$

(mean of the asset returns over mean of the benchmark return)

So simple versus log returns makes no difference in this calculation.

The code is implemented using

$$ \frac{sum(UpRa)}{sum(UpRb)}$$

which is what is causing the confusion.

The ratio of sums and the ratio of means is the same. So the calculation in the code is correct.

Sum is a more efficient vectorized calculation than mean. mean involves an additional division by the total number of observations. This is why the calculation is implemented the way it is.

Another way to think about why the calculations are equivalent is that both means would have the same denominator. So you could consider the ratio of sums as having factored out the common denominators (the number of observations).

Ref: Bacon, Carl. Practical Portfolio Performance Measurement and Attribution, Second Edition. Wiley. 2004. p. 47

|improve this answer|||||
$\endgroup$
  • $\begingroup$ @BrianG.Peterson. What you say makes sense if $N_a =N_b$, because $\frac{\sum_n^N R_a}{\sum_n^N R_b} = \frac{m_a}{ m_b}$. I won't argue that the software calculates the metric as intended within the reference text. Question though: why wouldn't a comparison of geometric and/or log means of returns be more appropriate for a variable which is assumed to be log-normally distributed? $\endgroup$ – David Addison Apr 14 '17 at 23:49
  • $\begingroup$ Whether you use log or arithmetic returns depends on many different things. frequency matters here, as do potential distortions introduced by the compounding process. Reported returns are always simple/arithmetic returns for asset managers. You can make a theoretical argument that the central tendency is better represented by comparing geometric means, I don't think you have a lot of support in the portfolio literature for that approach, so you'd have a lot of explaining to do to any stakeholder that wanted to tie your numbers back to what they were expecting. $\endgroup$ – Brian G. Peterson Apr 17 '17 at 15:17
  • $\begingroup$ The sum doesn't really make sense if you have a long, volatile series where sums of returns could potentially add to -100%. By contrast, the product returns are a useful number: take the product of upside return and downside return, and get the return. So these numbers feel like a "factorisation" of a portfolio or benchmark returns into its top and bottom halves. $\endgroup$ – lebelinoz Apr 18 '17 at 0:39
  • $\begingroup$ @BrianG.Peterson. That makes sense. Thank you for the explanation. $\endgroup$ – David Addison Apr 18 '17 at 1:04
  • 1
    $\begingroup$ @lebelinoz You are free to choose to use log returns. Bacon's Up Capture Ratio and Down Capture Ratio are defined as a ratio of means (which is identical to a ratio of sums, per the commutative property), not a ratio of products or a ratio of geometric means. So, whether using log returns or artithmetic returns, the ratio of means will be calculated as implemented in PerformanceAnalytics. Any other way of calculating it would not be Bacon's Up/Down Capture Ratio, and would therefore be an incorrect implementation of the method. $\endgroup$ – Brian G. Peterson Apr 19 '17 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.