Brian, 

I have one other much smaller issue that I've noticed (in this case, I could easily be wrong, so feel free to tell me).  I noticed that even after fixing the tracking error my spreadsheet-based information ratios were very slightly different than the ones calculated by table.CAPM.  The difference seems to be in the roll-up to annualized returns used in calculating the active premium and how the risk free rate factors in.  For example, if I enter in Excess Return as follows:

ActivePremium(bm_xts['1995-03-01::2010-06-30',"Composite..Gross."]-bm_xts["1995-03-01::2010-06-30", "Monthly.Yield.on.3.Month.T.Bills"]  ,   bm_xts['1995-03-01::2010-06-30',"Benchmark"]-bm_xts["1995-03-01::2010-06-30", "Monthly.Yield.on.3.Month.T.Bills"])

it gives me...

[1] 0.0231069

which is what table.CAPM comes up with for Active Premium when the risk free series is specified.  (I later figured out that I could do the RF rate explicitly in table.CAPM rather than subtracting from both portfolio and benchmark.) Meanwhile, 
 
ActivePremium(bm_xts['1995-03-01::2010-06-30',"Composite..Gross."] , bm_xts['1995-03-01::2010-06-30',"Benchmark"]) 

gives me

[1] 0.0238008

which matches what I've been using.  While I might have thought the results would be the same because the risk free rate is being subtracted from both the composite and benchmark, because it is annualized first the numbers are coming out slightly different.  I don't think the Risk-Free rate should affect the ActivePremium (right?), as it is just the difference between the annualized returns of the portfolio and benchmark.  If I put this code in table.CAPM, I match my numbers:

active.premium = (Return.annualized(Ra, scale = scale) - Return.annualized(Rb, scale = scale))

Again, thank you for all of your help.

Best regards,
Russ

On Sep 17, 2010, at 9:16 AM, Brian G. Peterson wrote:

> On 09/17/2010 07:43 AM, devlinme@mac.com wrote:
>> I've been getting up to speed on the Performance Analytics package, and there's one formula I'm having some trouble reconciling with some manual results I have done in spreadsheets.  The table.CAPM function has a tracking error calculation that looks like this:
>> 
>> tracking.error = sqrt(sum(merged.assets[, 1] - merged.assets[,
>>                 2])^2/(length(merged.assets[, 1]) - 1)) * sqrt(scale)
>> 
>> This gives different results than the TrackingError function (which just uses the standard deviation function).  I think the formula in table.CAPM should be this:
>> 
>> tracking.error = sqrt(sum((merged.assets[, 1] - merged.assets[,
>>                 2])^2)/(length(merged.assets[, 1]) - 1)) * sqrt(scale)
>> 
>> This result flows through to the Information Ratio as well.
> 
> I've always been uncomfortable with the code for this table.  In an attempt to make it run marginally faster, the calculations are done inside the table. function rather than calling the underlying (and more closely examined) standalone functions.
> 
> This introduces the strong possibility of cut and paste errors, or of fixes or improvements from other parts of the code not propagating properly into the table (as happened in this case, from a glance at the commit logs).
> 
> Given my little rant above, I've changed the function to simply call TrackingError(), and committed it as R-Forge r1763.
> 
> Thank you for the report.  We appreciate the feedback and careful commentary.
> 
> Regards,
> 
>  - Brian
> 
> -- 
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock


	[[alternative HTML version deleted]]

