Hi Simon

(fawce, pls jump in if I get any of this wrong...)

These metrics (Sharpe, Sortino etc.) are calculated within zipline/finance/risk and can be found here on github. From my reading of the vol calculation, it has been annualised (given daily returns). I have an outstanding issue around market practice of 'normally' using log returns in vol calculations, which can be seen here in github, would love to have your comments in addition.

Oh, the vol is not annualized? That might explain it, I will check later. Definitely I was expecting the vol to be the daily volatility annualized with sqrt(252).

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1635484

This provides some explanation why the square root rule only technically applies to log returns. I believe he mentioned the problem in one of his other Quant Nuggets.

I think Taleb wrote a quickie on it too but I can't find it now...

Looking at it closer, I think the intention has been to annualise the volatility by multiplying the daily stdev of returns by return np.std(daily_returns, ddof=1) * math.sqrt(self.trading_days) My initial assumption (without checking - silly) was that self.trading_days here gave the number of trading days in a year (which would render the above the correct translation daily to annual) but having read the the details at the top of the file now, I think trading_days is actually the total number of trading days across the whole back test, which is not going to give the correct annualisation...

Perhaps someone who's better at reading Python can help out here...

Looking at it closer, I think the intention has been to annualise the volatility by translating the stdev of daily returns as follows return np.std(daily_returns, ddof=1) * math.sqrt(self.trading_days) However, my initial assumption (without checking - silly) was that self.trading_days here gave the number of trading days in a year (which would render the above the correct translation daily to annual) but having read the the details at the top of the file now, I think trading_days is actually the total number of trading days across the whole back test, which is not going to give the correct annualisation...

Perhaps someone who's better at reading Python than me can confirm for us...

I just replicated the quantopian vol -- it is indeed std(daily_returns) * sqrt(all_days_in_simulation)

The sharpe ratio, likewise, seems to be the (simulation_return - simulation_treasury_return) / (simulation_vol)

I believe this means that sharpe ratios (and all the stats) are incomparable between backtests of different lengths.

I am not sure about the risk-free return, I had always assumed that the risk-free rate was the daily-compounded overnight risk-free (OIS) rate, not necessarily the long-term treasury of the nearest maturity.

re: log returns:

Using the existing entire-simulation method of calculating the sharpe ratio, arithmetic returns and the stddev of arithmetic returns * sqrt(sim_period) results in a sharpe ratio of, for instance, 1.74. Using logarithmic returns and the stddev of logarithmic returns * sqrt(sim_period) results in a sharpe ratio of, for instance, 1.58, so these distinctions make a difference.

@Simon: you are correct. I've been meaning to refactor the risk calculations for a while and add the proper annualization so that they can be compared between simulations. There are a couple of minor things that have to happen before that but overall it's not too difficult.

http://www.treasury.govt.nz/publications/research-policy/wp/2003/03-28

I finally found the paper that I really wanted to paste here!!

http://economics.sas.upenn.edu/~fdiebold/papers/paper18/dsi.pdf