[R-sig-finance] Stochastic volatility
Carl
phleum at chello.se
Sun Nov 6 19:57:58 CET 2005
The performance of discrete time (Garch) vs continous time SV models with
stochastic diffusions and/or jumps in returns and/or variances have been
compared and tested for option pricing purposes (search the net for
references; P. Christoffersen and K. Jacobs, "Which Volatility Models for
Option Valuation?", for example).
The main result seems to be that the different models do not compete but
complement each other. In some cases one can prove that a continuos model is
the continuos limit of a Garch model (this is valid for the Heston vs the
Heston-Nandi Garch model). One advantage of Garch models are that they
provide the conditional volatility, which is unknown in the continuous SV
models.
A major obstacle in option pricing is the problem of calibrating the
parameters to the current skew (ie the theoretical option prices should agree
with the market prices for different strikes). Therefore, fast option pricing
models are very important for both pricing and the calculation of greeks in a
trading environment. The "speed" criterion favours closed-form,
semiclosed-form (ie fourier transform, FFT) or approximate models which can
price large number of options w.r.t different strikes. The most known models
that fit this description are Heston's SV model and the Heston-Nandi Garch
model. Today, incredibly many alternative models exist that add features and
flavours to the basic structure of the above-mentioned models.
SV models with jumps seem to better adapted to options with shorter time to
expiry because of steeper skews whereas longer dated options (with their
flatter volatilities) are better treated with stochastic diffusion models
(such as the Heston or Heston-Nandi Garch model).
I have not yet seen the application of the Kalman filter (and the particle
filter) to option pricing. This sounds like a very interesting approach! If
anyone knows about such work, please give me a link!
Carl
On Sunday 06 November 2005 12:00, r-sig-finance-request at stat.math.ethz.ch
wrote:
> Send R-sig-finance mailing list submissions to
> r-sig-finance at stat.math.ethz.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> or, via email, send a message with subject or body 'help' to
> r-sig-finance-request at stat.math.ethz.ch
>
> You can reach the person managing the list at
> r-sig-finance-owner at stat.math.ethz.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of R-sig-finance digest..."
>
>
> Today's Topics:
>
> 1. Re: [R] Stochastic Volatility (Patrick Burns)
> 2. Re: more fCalendar (Spencer Graves)
> 3. Re: [R] Stochastic Volatility (Eric Zivot)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 05 Nov 2005 15:14:02 +0000
> From: Patrick Burns <patrick at burns-stat.com>
> Subject: Re: [R-sig-finance] [R] Stochastic Volatility
> To: Phineas Campbell <pcampbell at econ.bbk.ac.uk>
> Cc: "r-sig-finance at stat.math.ethz.ch"
> <r-sig-finance at stat.math.ethz.ch>
> Message-ID: <436CCC3A.2010609 at burns-stat.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> This seems much more appropriate for R-sig-finance than
> for R-help.
>
> I'm curious why you think garch models are less satisfactory
> than stochastic volatility models. I'm not aware of any literature
> that shows one dominating the other, and not even very much
> that compares the two.
>
>
> Patrick Burns
> patrick at burns-stat.com
> +44 (0)20 8525 0696
> http://www.burns-stat.com
> (home of S Poetry and "A Guide for the Unwilling S User")
>
> Phineas Campbell wrote:
> >Has anybody implemented or tried to implement a stochastic volatility
> > model using the Kalman filter following a series of papers by Harvey,
> > Ruiz and Shepard?
> >
> >This is a sophisticated approach for estimating an important class of
> >models, so I am surprised that no implementation exists, is this because
> >there are unforeseeable problems?
> >
> >In a related but off topic question, it has been a while since I looked at
> >the non homoskedastic time series literature but back then you couldn't
> > pick up a journal without reading another stochastic volatility paper,
> > does anybody have any ideas why the literature has drifted back toward
> > less satisfactory GARCH and EGARCH models?
> >
> >This question is somewhat moot as if I choose to pursue this I will
> >implement a model myself.
> >
> >
> >Phineas Campbell
> >
> >______________________________________________
> >R-help at stat.math.ethz.ch mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-help
> >PLEASE do read the posting guide!
> > http://www.R-project.org/posting-guide.html
>
> ------------------------------
>
> Message: 2
> Date: Sat, 05 Nov 2005 11:59:02 -0800
> From: Spencer Graves <spencer.graves at pdf.com>
> Subject: Re: [R-sig-finance] more fCalendar
> To: Parlamis Franklin <fparlamis at mac.com>
> Cc: r-sig-finance at stat.math.ethz.ch
> Message-ID: <436D0F06.2050303 at pdf.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> If you have not received a reply to this and your other similar post,
> I suggest you send a private email to the Maintainer: Diethelm Wuertz
> <wuertz at itp.phys.ethz.ch>.
>
> I would think he would appreciate your contribution.
>
> Good Luck,
> spencer graves
>
> Parlamis Franklin wrote:
> > It's me again, with Japanese calendar minutiae I'm sure you've all
> > been dying to brush up on.
> >
> > the fCalendar functions don't include the Japanese Vernal Equinox
> > holiday. this is perhaps because there is no easy way to calculate
> > it. at any rate, here's a function i wrote to fill the gap.
> >
> > =====
> >
> > JPVernalEquinox <- function(year) {
> >
> > ## Origin and End Date data from http://aa.usno.navy.mil/data/
> > docs/EarthSeasons.html
> > ## The function Vernal.Equinox delivers correct values at the
> > endpoints of the above data.
> > ## There may be minor variances (+/- a few minutes) in the
> > intermediate values,
> > ## because the function linearly approximates a phenomenon that
> > is apparently
> > ## nonlinear in recorded time.
> >
> > Equinox.Origin <- timeCalendar(1992, 3, 20, 8, 48, 0,
> > FinCenter="GMT")
> > Data.EndDate <- timeCalendar(2020,3,20,3,49,0,FinCenter="GMT")
> > Total.Seconds <- as.numeric(Data.EndDate-Equinox.Origin)*24*60*60
> > Mean.Annual.Seconds <- Total.Seconds/(atoms(Data.EndDate)$Y-atoms
> > (Equinox.Origin)$Y)
> > Vernal.Equinox <- function(year) Equinox.Origin+unclass((year-
> > atoms(Equinox.Origin)$Y)*Mean.Annual.Seconds)
> > JPVernal.Equinox <- function(year) timeDate(as.character
> > (Vernal.Equinox(year)), FinCenter="Tokyo")
> >
> > ## Nota bene: JP Vernal Equinox is celebrated when the equinox
> > occurs in the Japanese time zone
> > ## (see, e.g., 2006, where GMT Vernal Equinox is on 20 March,
> > but Japanese Equinox holiday is 21 March)
> >
> > as.Date(as.character(JPVernal.Equinox(year)))}
> >
> > =====
> >
> > in contrast to the other holiday functions in fCalendar, the above
> > function returns an object of class "Date" rather than "sdate"
> > because use of sdates appears to be deprecated following the
> > introduction of the Date class, and also because the sdate function
> > appears to have a bug.
> > [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-sig-finance at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-sig-finance
More information about the R-sig-finance
mailing list