Skip to content

PerformanceAnalytics package

22 messages · financial engineer, Joshua Ulrich, Jeff Ryan +4 more

#
hi,



I've been trying to familiarize myself with the PerformanceAnalytics package.



As I go through the examples (in the attached file), I faced a hiccup.

When I run the following code, it only prints the first chart



charts.PerformanceSummary(managers[, c(manager.col,

indexes.cols)],colorset = rich6equal, lwd = 2, ylog = TRUE)



and gives me the following error:


Error in UseMethod("time<-") :

  no applicable method for 'time<-' applied to an object of class

"c('xts', 'zoo')"



Can you please let me know how I can fix it.



Thanks!

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20111022/1037953d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PA-charts.pdf
Type: application/pdf
Size: 256508 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20111022/1037953d/attachment.pdf>
#
I know Dirk told you to post here, but please mention that you've
cross-posted so other can find answers easier.
http://stackoverflow.com/questions/7862410/r-performanceanalytics-package

Also, please follow the posting guide.  Specifically note the sections
"Surprising behavior and bugs" and "Common posting mistakes".
Following the guide will make it easier--therefore more likely--for
people to help you.
http://www.r-project.org/posting-guide.html

Best,
--
Joshua Ulrich ?| ?FOSS Trading: www.fosstrading.com



On Sat, Oct 22, 2011 at 5:10 PM, financial engineer
<fin_engr at hotmail.com> wrote:
#
This is most likely a conflict between xts/zoo and the various f* Rmetrics
packages 
(or possibly the timeSeries package from Rmetrics).  You'll like see a
warning that function 'time' is being masked.

the zoo/xts and Rmetrics teams are aware of the issue, and are trying to
sort out a modle that will avoid trhe conflict.

For now, the most likely way for you to avoid this issue is to not load
the Rmetrics packages, or to load zoo/xts *after* you've loaded any
Rmetrics packages you need. 

On Sat, 22 Oct 2011 18:10:15 -0400, financial engineer
<fin_engr at hotmail.com> wrote:

  
    
#
Can you include your sessionInfo() output as well. 

You may be running old packages or some strange combination. Without knowing your context a guess is all that we can muster. 

Best,
Jeff

PS. StackOverflow may be the current 'cool' but it is mostly fracturing the answer base when it comes to R and Finance. In general that's a very bad thing. Unless of course those SO points you accumulate have some sort of store you can cash them in at. I think the store is Joel's pocket. 



Jeffrey Ryan    |    Founder    |    jeffrey.ryan at lemnica.com

www.lemnica.com
On Oct 22, 2011, at 5:34 PM, financial engineer <fin_engr at hotmail.com> wrote:

            
#
Something is obviously not consistent, as the sessionInfo you just sent doesn't even include PerformanceAnalytics. 

Can you try and run your example again to the point of breakage and send the sessionInfo() from that one?

Thanks
Jeff

Jeffrey Ryan    |    Founder    |    jeffrey.ryan at lemnica.com

www.lemnica.com
On Oct 22, 2011, at 6:08 PM, financial engineer <fin_engr at hotmail.com> wrote:

            
#
It could be that you have fSeries (deprecated) instead of timeSeries (new version of fSeries), but if you no longer have a conflict, I suppose we should just be happy. 

Best,
Jeff

Jeffrey Ryan    |    Founder    |    jeffrey.ryan at lemnica.com

www.lemnica.com
On Oct 22, 2011, at 7:06 PM, financial engineer <fin_engr at hotmail.com> wrote:

            
#
I don't know if Josh/Brian/Jeff got you an answer on this, but on my
version of PerformanceAnalytics (1.0.3.2), these different VaR methods
seem to have been collapsed into VaR with different methods available.
Perhaps your reference is for an older version of the package in which
these have been deprecated.

I also don't see table.MonthlyReturns() only table.AnnualizedReturns()
available. I believe I read somewhere that the package is designed
with monthly data in mind (though most of the analytical techniques
are scale invariant) so it's perhaps not surprising that there's no
aggregation tool to monthly.

Michael

On Sun, Oct 23, 2011 at 3:56 PM, financial engineer
<fin_engr at hotmail.com> wrote:
#
On Mon, 2011-10-24 at 11:49 -0400, financial engineer wrote:
You didn't include your data to make this reproducible, so I need to
speak in generalities.
Modified expected shortfall should always be higher than modified
 Value at Risk. Due to estimation problems, this might not always
 be the case. Set operational = TRUE to replace modified ES with
 modified VaR in the (exceptional) case where the modified ES is
 smaller than modified VaR.

If you're seeing this, I expect your data is highly skewed and/or
kurtotic.

Cornish Fisher Modified VaR can exhibit what Jorion referred to as
'wrong tailed  behavior', migrating rapidly to zero or infinity.  While
this is a problem, it is only a problem if you aren't paying attention.
I use this as an indicator that I either don't have enough data or that
my data is likely unreliable.  It is also often an indication that your
preferred probability (99%) is too high for a reliable answer.

Look at function chart.VaRSensitivity to see how the VaR and ES play out
at different probability thresholds. 

The good news is that it's really obvious when this happens, you can
easily see it in the chart, and tell where you don't and probably
shouldn't have confidence in your estimating powers.

Just because some other methodologies will give you an answer that
claims to be precise doesn't mean that they are truly doing so.  Many
many people have written about the pitfalls of looking for too high a
precision in VaR/ES estimates.  I, for example, find 95% to be a good
number on daily return data, as this indicates a 1 in 20 'bad day', so
you can interpret the 95% ES as approximately your 'average one really
bad day a month' on daily return data.  I have a colleague who uses 92%
on monthly return data to estimate the 'average really bad month once a
year' on his portfolios.

I prefer 'approximately correct' to 'precisely wrong' statistics.

I could speak in more specifics about the characteristics of your data
with a reproducible example.

Regards,

  - Brian
#
table.MonthlyReturns was replaced with table.CalendarReturns, which is
somewhat more flexible than the old function.

In general, PerformanceAnalytics is most tested on regular returns data.
Most of the functions will work with any xts/zoo time series of returns
(hourly, daily, weekly, monthly, annual, etc) .  Some will work on cash
P&L, prices, or a NAV/wealth index, as noted in the documentation for
those functions.  Where specific periodicities are required by a
function, this will be noted in the documentation for that function.

It is also true that all the VaR and ES functions were collapsed into a
single function for each with various univariate and portfolio methods.

Regards,

   - Brian
On Mon, 2011-10-24 at 13:19 -0400, R. Michael Weylandt wrote:
#
I don't have the OP's data, but, just for the record, the same
phenomenon can be seen with SPY returns.

library(quantmod)
getSymbols("SPY")
R = na.omit(ROC(Ad(SPY)))

identical((ES(R, p = 0.99)-VaR(R, p = 0.99))[1,1],0)
TRUE

And thanks for the insightful explanation. Do you happen to have the
Jorion reference handy? If not, no worries, I can hunt it down.

Michael
On Mon, Oct 24, 2011 at 2:11 PM, Brian G. Peterson <brian at braverock.com> wrote:
#
On Mon, 2011-10-24 at 14:20 -0400, financial engineer wrote:
I've attached the output of chart.VaRSensitivity on the MCO data.

You can see how the modified VaR tracks to the historical VaR very well,
much better than the Gaussian approximation.  

You can also see where the modified ES breaks down, at around 98%, and
starts climbing towards zero.  The operational assumption will return
the modified VaR.

You can also see that at high probability levels modified ES will give
larger loss estimates than the historical.  I tend to think conservative
risk estimates are a good thing, but others have opinions that differ on
the desirability of this.

I previously gave my rationale for using lower p values than p=.99 with
daily or lower frequency data.

Regards,

  - Brian
2 days later
#
Hi All,

Measuring price impact of trade is very topical in institutional space, so I looked into that over the past few weeks to see if there was anything done in R. 

Apart of the attached code done by so-called "MaxDama" that tries to replicate the attached paper not much was there.

In particular, the issue related how to extrapolate the power-law coefficient across different participation rates of daily average volume.
 
RTAQ has a function called realized spread but the very assumption (that difference between transaction Price and Midpoint 5 mins later reflects price impact) is very dubious as it assumes no impact of trades in between. At least the testing of it gives inconclusive result.

I wonder if anyone in R SIG Finance finds this topical and would be happy to share thoughts so we can come up with reasonable function to implement it. 

Thanks.

__________________________________________________
Darko Roupell 

************** IMPORTANT MESSAGE *****************************       
This e-mail message is intended only for the addressee(s) and contains information which may be
confidential. 
If you are not the intended recipient please advise the sender by return email, do not use or
disclose the contents, and delete the message and any attachments from your system. Unless
specifically indicated, this email does not constitute formal advice or commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us, please reply to this
e-mail by typing Unsubscribe in the subject line. 
**************************************************************


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Single Curve Collapse of the Price Impact.pdf
Type: application/pdf
Size: 174137 bytes
Desc: Single Curve Collapse of the Price Impact.pdf
URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20111027/4336563b/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: impact.r
Type: application/octet-stream
Size: 1106 bytes
Desc: impact.r
URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20111027/4336563b/attachment.obj>