[R-SIG-Finance] returns convention

[Peter Carl]

On Monday 08 October 2007 6:23:21 am paul sorenson wrote:
> Is it usually assumed that references to "returns" are calculated as
> diff(log(prices))?  Compared with say the simple fractional change from
> one price to the next?
>
> For example, in PerformanceAnalytics I notice that the default value of
> CalculateReturns is diff(log(prices)).
>
> I guess it probably doesn't matter much either way for small changes, I
> just wanted to know if there was some common convention when I see an R
> function that expects a returns vector.
>
> cheers
>
> _______________________________________________
> R-SIG-Finance at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> -- Subscriber-posting only.
> -- If you want to post, subscribe first.

Despite the default you point out, most of the functions in  
PerformanceAnalytics assume simple returns.  Perhaps an underlying question  
is "which is the 'correct' way to calculate returns?"  but the answer for  
what to is "neither", which is somewhat unsatisfying (to point to Jeff's 
earlier comment).  The "better" method depends what you are trying to 
accomplish.  Most of PerformanceAnalytics' functions are about performance 
description, so we have erred to the simple which is slightly more 
conservative.

Before we get to 1.0, I hope to have methods included for handling both  
explicitly where needed.

As Eric already pointed out, continuously compounded returns have an advantage 
over simple returns in that they are additive through time and they include 
the effects of compounding.   The drawback to log returns is that they are 
not additive in a portfolio.  

The simple return on a portfolio of assets is a weighted average of the 
simple returns on the individual assets.  Average simple returns can be 
thought of as a reasonable one-step-ahead forecast; average compound returns 
are a better representation of the expected return over a longer period.  

But what really matters is that you are consistent, so that the comparisons 
you make are imprecise in the same direction and the resulting relative 
ranking is correct.

I can't speak for the assumptions of other packages or functions expecting 
returns, but I would note that there seem to be relatively few.  If I recall 
correctly, many functions assume prices and make the conversion.

pcc

-- 
Peter Carl
145 Scottswood Rd
Riverside, IL 60546
708 447 6465