[R-SIG-Finance] fOptions::CND versus pnorm
Hi, I was recently looking at the fOptions package and I was wondering if anyone knows why the authors of the package bothered to write functions for CND and NDF, when they exist as pnorm and dnorm? I realize there's the possibility that pnorm and dnorm may not have existed when fOptions was written. Regardless, I was wondering it there's some non-obvious advantage to using CND or NDF versus the base stats functions. If anything, from http://svn.r-project.org/R/trunk/src/nmath/pnorm.c it sounds like pnorm could be slightly more accurate. This transportable program uses rational functions that theoretically approximate the normal distribution function to at least 18 significant decimal digits. The accuracy achieved depends on the arithmetic system, the compiler, the intrinsic functions, and proper selection of the machine-dependent constants. They seem to basically return the same values plus or minus some extremely small floating point error. library(fOptions) x - seq(-4, 4, 0.01) all.equal(pnorm(x), CND(x)) [1] Mean relative difference: 8.845649e-08 all.equal(dnorm(x), NDF(x)) [1] TRUE Thanks, James [[alternative HTML version deleted]] ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
[R-SIG-Finance] sufficient n for a binomial option pricing model
Hi,
I have a question regarding the selection of n, the number of time
steps, in a binomial option pricing model. I suppose my question is
not strictly related to R. As larger values should be more accurate,
what I've read on the subject simply suggests that you use a
sufficiently large value for your purposes. So I've been trying to
evaluate what is a sufficiently large value of n for my purposes. Is
there any rule of thumb regarding the value of n?
When using the fOptions package CRRBinomialTreeOption function, with
varying n, the price oscillates back and forth converging on a price.
This can be clearly seen through plotting.
require(fOptions)
x - function(n) {
CRRBinomialTreeOption(TypeFlag = ca,
S = 50,
X = 50,
Time = 1/12,
r = 0.02,
b = 0.02,
sigma = 0.18,
n = n)@price
}
y - sapply(1:100, x) # mean(y) == 1.079693
plot(y)
Given this oscillation, my question is whether it would be better to
compute two prices using two smaller, consecutive values of n rather
than one large value? Or is there some other better way?
For example, using n =1000 or 1001, the option prices are within 5
hundredths of a cent, but the calculation is extremely slow for
either.
x(1000)# 1.077408
x(1001)# 1.077926
mean(sapply(1000:1001, x)) # 1.077667
Comparatively, taking the mean of n= 40 and 41 yields a value very
close to the middle of the range, yet is much faster.
mean(sapply(40:41, x)) # 1.0776
It seems like averaging two smaller, consecutive values of n is
basically as accurate and far faster than using large values of n. I
was hoping someone might have some insight into why this might or
might not be a valid approach. Thanks.
James
___
R-SIG-Finance@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
-- Subscriber-posting only. If you want to post, subscribe first.
-- Also note that this is not the r-help list where general R questions should
go.
Re: [R-SIG-Finance] sufficient n for a binomial option pricing model
On Thu, Sep 6, 2012 at 9:40 AM, Smith, Dale dale.sm...@fiserv.com wrote:
One way to terminate is to look at the consecutive differences between
the averages and terminate if the difference is less than your
tolerance. However, you should guard against the case where the
consecutive differences are never less than the tolerance. In this case,
just put in a maximum number of steps n and log the last average, the
number of steps, and a message. This allows the user to determine
whether they want to accept or reject the result.
Dale,
Thanks for the suggested method. Actually, that's probably overkill
for what I'm trying to do, but it definitely puts the process in
perspective and gives some insight into what I could be doing to boost
the reliability of my pricing. Thanks again.
Best,
James
-Original Message-
From: r-sig-finance-boun...@r-project.org
[mailto:r-sig-finance-boun...@r-project.org] On Behalf Of J Toll
Sent: Thursday, September 06, 2012 10:25 AM
To: r-sig-finance@r-project.org
Subject: [R-SIG-Finance] sufficient n for a binomial option pricing
model
Hi,
I have a question regarding the selection of n, the number of time
steps, in a binomial option pricing model. I suppose my question is not
strictly related to R. As larger values should be more accurate, what
I've read on the subject simply suggests that you use a sufficiently
large value for your purposes. So I've been trying to evaluate what is
a sufficiently large value of n for my purposes. Is there any rule of
thumb regarding the value of n?
When using the fOptions package CRRBinomialTreeOption function, with
varying n, the price oscillates back and forth converging on a price.
This can be clearly seen through plotting.
require(fOptions)
x - function(n) {
CRRBinomialTreeOption(TypeFlag = ca,
S = 50,
X = 50,
Time = 1/12,
r = 0.02,
b = 0.02,
sigma = 0.18,
n = n)@price
}
y - sapply(1:100, x) # mean(y) == 1.079693
plot(y)
Given this oscillation, my question is whether it would be better to
compute two prices using two smaller, consecutive values of n rather
than one large value? Or is there some other better way?
For example, using n =1000 or 1001, the option prices are within 5
hundredths of a cent, but the calculation is extremely slow for either.
x(1000)# 1.077408
x(1001)# 1.077926
mean(sapply(1000:1001, x)) # 1.077667
Comparatively, taking the mean of n= 40 and 41 yields a value very close
to the middle of the range, yet is much faster.
mean(sapply(40:41, x)) # 1.0776
It seems like averaging two smaller, consecutive values of n is
basically as accurate and far faster than using large values of n. I
was hoping someone might have some insight into why this might or might
not be a valid approach. Thanks.
James
___
R-SIG-Finance@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
-- Subscriber-posting only. If you want to post, subscribe first.
-- Also note that this is not the r-help list where general R questions
should go.
___
R-SIG-Finance@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-sig-finance
-- Subscriber-posting only. If you want to post, subscribe first.
-- Also note that this is not the r-help list where general R questions should
go.
Re: [R-SIG-Finance] error in yang.zhang volatility{TTR}
On Tue, May 29, 2012 at 10:08 PM, Joshua Ulrich josh.m.ulr...@gmail.com wrote: Sorry, to get that to work, it should actually be: s2o - N * runVar(log(OHLC[, 1] / Cl1), n = n) s2c - N * runVar(log(OHLC[, 4] / OHLC[, 1]), n = n) It needs to be n = n, otherwise runVar confuses n for y. Thank you for another very helpful patch. From looking at the svn log, it looks like I got more things wrong than right with this calculation. :) I also added the ability for users to specify alpha via '...' (the default value is 1.34). Best, -- Joshua Ulrich | FOSS Trading: www.fosstrading.com Joshua, Thanks for taking a look at that. I know you were joking about getting more things wrong than right, but I think I partially melted my brain thinking through the vectorization. One stand-alone calculation may be fairly easy, but then vectorizing the whole thing can be tricky. I think the patches all look good on r-forge. Thanks again. Best, James ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
Re: [R-SIG-Finance] error in yang.zhang volatility{TTR}
On Mon, May 21, 2012 at 9:20 PM, Hideyoshi Maeda hideyoshi.ma...@gmail.comwrote: Doing a quick comparison of the difference in code for the volatility estimate in using 'yang.zhang' as a calculation method, on SP 500 data, going back from the beginning of 2001 till today (22 May 2012). These were the results from the following lines of code: N.B. volatility.new is the edited code with the suggestion of using runVar instead of runSum, as suggested by James N.B SPX.ohlc is an xts object of that contains OHLC data for the Bloomberg ticker SPX Index original.vol.code - volatility(SPX.ohlc, calc=yang.zhang) new.vol.code - volatility.new(SPX.ohlc, calc=yang.zhang) plot((new.vol.code-original.vol.code)*100/original.vol.code, main=% difference in volatility esitimates + when comparing new and old code) Some quite significant percentage differences getting up to approx. -10% viewing it as a histogram in terms of differences, you get... I was actually surprised that the calculation isn't off by more, but the inner runSum which calculates a rolling mean is usually fairly stable, especially for longer n. I don't know if Bloomberg can calculate volatility via yang.zhang, but that would be a worthwhile reference to compare. Best, James [[alternative HTML version deleted]] ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
[R-SIG-Finance] error in yang.zhang volatility{TTR}
Hi, I've been going through the code for the yang.zhang calculation method of volatility in the TTR package and believe I've found the same error as the one from last year on the Close to Close volatility estimator. https://stat.ethz.ch/pipermail/r-sig-finance/2011q2/007989.html Like the previous error, one of the first clues that there was a problem was an excessive number of NA values generated at the beginning of the output (e.g. 40 NA's for n = 20). I believe the errors are in these two calculations: s2o - N/(n - 1) * runSum((log(OHLC[, 1]/Cl1) - 1/n * runSum(log(OHLC[, 1]/Cl1), n))^2, n) s2c - N/(n - 1) * runSum((log(OHLC[, 4]/OHLC[, 1]) - 1/n * runSum(log(OHLC[, 4]/OHLC[, 1]), n))^2, n) Basically, s2o is just supposed to be the variance of the normalized open, log(OHLC[, 1]/Cl1 and s2c is the variance of the normalized close. log(OHLC[, 4]/OHLC[, 1] The problem in both formula is, as in Close to Close, that you have two nested runSum calculations being used to calculate variance. For example, if n = 20, the first 20 values should be differenced against the same mean. That's not happening here. The first value is being differenced against the first mean, the second value is being differenced against the second mean, and so on. As a simple fix, I would suggest these corrections: s2o - N * runVar(log(OHLC[, 1] / Cl1), n) s2c - N * runVar(log(OHLC[, 4] / OHLC[, 1]), n) I would welcome the input of someone with reference data that could double-check this against a known value. Thanks, James ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
Re: [R-SIG-Finance] error in yang.zhang volatility{TTR}
On Mon, May 21, 2012 at 11:32 AM, J Toll jct...@gmail.com wrote: Hi, I've been going through the code for the yang.zhang calculation method of volatility in the TTR package and believe I've found the same error as the one from last year on the Close to Close volatility estimator. https://stat.ethz.ch/pipermail/r-sig-finance/2011q2/007989.html Like the previous error, one of the first clues that there was a problem was an excessive number of NA values generated at the beginning of the output (e.g. 40 NA's for n = 20). I believe the errors are in these two calculations: s2o - N/(n - 1) * runSum((log(OHLC[, 1]/Cl1) - 1/n * runSum(log(OHLC[, 1]/Cl1), n))^2, n) s2c - N/(n - 1) * runSum((log(OHLC[, 4]/OHLC[, 1]) - 1/n * runSum(log(OHLC[, 4]/OHLC[, 1]), n))^2, n) Basically, s2o is just supposed to be the variance of the normalized open, log(OHLC[, 1]/Cl1 and s2c is the variance of the normalized close. log(OHLC[, 4]/OHLC[, 1] The problem in both formula is, as in Close to Close, that you have two nested runSum calculations being used to calculate variance. For example, if n = 20, the first 20 values should be differenced against the same mean. That's not happening here. The first value is being differenced against the first mean, the second value is being differenced against the second mean, and so on. As a simple fix, I would suggest these corrections: s2o - N * runVar(log(OHLC[, 1] / Cl1), n) s2c - N * runVar(log(OHLC[, 4] / OHLC[, 1]), n) Sorry, to get that to work, it should actually be: s2o - N * runVar(log(OHLC[, 1] / Cl1), n = n) s2c - N * runVar(log(OHLC[, 4] / OHLC[, 1]), n = n) It needs to be n = n, otherwise runVar confuses n for y. James ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
Re: [R-SIG-Finance] American option sensitivities
On Fri, Feb 10, 2012 at 3:18 AM, Enrico Schumann enricoschum...@yahoo.de wrote: Hi all, (comments below) Am 10.02.2012 01:02, schrieb J Toll: On Thu, Feb 9, 2012 at 5:17 PM, Dirk Eddelbuettele...@debian.org wrote: On 9 February 2012 at 17:06, J Toll wrote: | Hi, | | I'd like to calculate sensitivities on American options. I was hoping | somebody might be able to summarize of the current state of that | functionality within the various R packages. It's my understanding | that the fOptions package can calculate greeks for European options | but not American. RQuantLib appears to have had the ability to | calculate greeks for American options at one point, but it appears | that functionality was removed in Release 0.1.8 sometime around | 2003-11-28. ... because that functionality was removed upstream by QuantLib. | | http://lists.r-forge.r-project.org/pipermail/rquantlib-commits/2010-August/000117.html | | Additionally, from RQuantLib ?AmericanOptions says, | | Note that under the new pricing framework used in QuantLib, binary | pricers do not provide analytics for 'Greeks'. This is expected to be | addressed in future releases of QuantLib. | | I haven't found any other packages for calculating option | sensitivities. Are there any other packages? | | Regarding RQuantLib, is the issue that that functionality hasn't been | implemented in R yet, or is it QuantLib that's broken? There is a third door behind which you find the price: numerical shocks. Evaluate your american option, then shift the various parameters (spot, vol, int.rate, time to mat, ...) each by a small amount and calculate the change in option price -- voila for the approximate change in option value for change input. You can also compute twice at 'x - eps' and 'x + eps' etc. Dirk Dirk, Thank you for your response. I was hoping you might reply. I understand the concept of your suggestion, although I don't have any practical experience implementing it. I'm guessing this is what's generally referred to as finite difference methods. In theory, the first order greeks should be simple enough, although my impression is the second or third order greeks may be a bit more challenging. I hate to trouble you for more information, but I'm curious why? Is this the standard method of calculating greeks for American options? Has QuantLib decided not to implement this calculation? Just curious. Thanks again, A simple forward difference is [f(x + h) - f(x)] / h 'f' is the option pricing formula; 'x' are the arguments to the formula, and 'h' is a small offset. Numerically, 'h' should not be made too small: (1) Even for smooth functions, we trade off truncation error (which is large when 'h' is large) against roundoff-error (in the extreme, 'x + h' may still be 'x' for a very small 'h'). (2) American options are typically valued via finite-difference or tree methods, and hence 'f' is not smooth and any 'bumps' in the function will be magnified by dividing by a very small 'h'. So when 'h' is too small, the results will become nonsensical. Here is an example. As a first test, I use a European option. require(RQuantLib) h - 1e-4 S - 100 K - 100 tau - 0.5 vol - 0.3 C0 - EuropeanOption(type = call, underlying = S, strike = K, dividendYield = 0.0, riskFreeRate = 0.03, maturity = tau, volatility = 0.3) Cplus - EuropeanOption(type=call, underlying = S + h, strike = K, dividendYield = 0.0, riskFreeRate=0.03, maturity=tau, volatility=0.3) Cminus - EuropeanOption(type=call, underlying = S - h, strike=K, dividendYield=0.0, riskFreeRate=0.03, maturity=tau, volatility=0.3) ## a first-order difference: delta (Cplus$value-C0$value)/h ## [1] 0.570159 C0$delta ## [1] 0.5701581 ## a second-order difference (Cplus$delta-C0$delta)/h ## [1] 0.01851474 C0$gamma ## [1] 0.01851475 Now for an American option. Here we don't have the delta, so we first need to compute it as well. C0 - AmericanOption(type=put, underlying = S, strike=K, dividendYield=0.0, riskFreeRate=0.03, maturity=tau, volatility=vol) Cplus - AmericanOption(type=put, underlying = S + h, strike=K, dividendYield=0.0, riskFreeRate=0.03, maturity=tau, volatility=vol) Cminus - AmericanOption(type=put, underlying = S - h, strike=K, dividendYield=0.0, riskFreeRate=0.03, maturity=tau, volatility=vol) ## a first-order difference: delta (dplus
[R-SIG-Finance] American option sensitivities
Hi, I'd like to calculate sensitivities on American options. I was hoping somebody might be able to summarize of the current state of that functionality within the various R packages. It's my understanding that the fOptions package can calculate greeks for European options but not American. RQuantLib appears to have had the ability to calculate greeks for American options at one point, but it appears that functionality was removed in Release 0.1.8 sometime around 2003-11-28. http://lists.r-forge.r-project.org/pipermail/rquantlib-commits/2010-August/000117.html Additionally, from RQuantLib ?AmericanOptions says, Note that under the new pricing framework used in QuantLib, binary pricers do not provide analytics for 'Greeks'. This is expected to be addressed in future releases of QuantLib. I haven't found any other packages for calculating option sensitivities. Are there any other packages? Regarding RQuantLib, is the issue that that functionality hasn't been implemented in R yet, or is it QuantLib that's broken? Thanks for any clarification. Best, James ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
Re: [R-SIG-Finance] American option sensitivities
On Thu, Feb 9, 2012 at 5:17 PM, Dirk Eddelbuettel e...@debian.org wrote: On 9 February 2012 at 17:06, J Toll wrote: | Hi, | | I'd like to calculate sensitivities on American options. I was hoping | somebody might be able to summarize of the current state of that | functionality within the various R packages. It's my understanding | that the fOptions package can calculate greeks for European options | but not American. RQuantLib appears to have had the ability to | calculate greeks for American options at one point, but it appears | that functionality was removed in Release 0.1.8 sometime around | 2003-11-28. ... because that functionality was removed upstream by QuantLib. | | http://lists.r-forge.r-project.org/pipermail/rquantlib-commits/2010-August/000117.html | | Additionally, from RQuantLib ?AmericanOptions says, | | Note that under the new pricing framework used in QuantLib, binary | pricers do not provide analytics for 'Greeks'. This is expected to be | addressed in future releases of QuantLib. | | I haven't found any other packages for calculating option | sensitivities. Are there any other packages? | | Regarding RQuantLib, is the issue that that functionality hasn't been | implemented in R yet, or is it QuantLib that's broken? There is a third door behind which you find the price: numerical shocks. Evaluate your american option, then shift the various parameters (spot, vol, int.rate, time to mat, ...) each by a small amount and calculate the change in option price -- voila for the approximate change in option value for change input. You can also compute twice at 'x - eps' and 'x + eps' etc. Dirk Dirk, Thank you for your response. I was hoping you might reply. I understand the concept of your suggestion, although I don't have any practical experience implementing it. I'm guessing this is what's generally referred to as finite difference methods. In theory, the first order greeks should be simple enough, although my impression is the second or third order greeks may be a bit more challenging. I hate to trouble you for more information, but I'm curious why? Is this the standard method of calculating greeks for American options? Has QuantLib decided not to implement this calculation? Just curious. Thanks again, James | | Thanks for any clarification. | | Best, | | | James | | ___ | R-SIG-Finance@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-sig-finance | -- Subscriber-posting only. If you want to post, subscribe first. | -- Also note that this is not the r-help list where general R questions should go. -- Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read. -- Groucho Marx ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
[R-SIG-Finance] fix yahooKeystats
Hi, I wanted to get some input from the more experienced R users regarding the yahooKeystats function in the fImport package. I believe that the function is currently broken (Version: 2110.79). It appears that Yahoo changed their HTML slightly which has caused the function to break. Several months ago, I managed to get it working and posted those changes to this list in case anyone else was interested. https://stat.ethz.ch/pipermail/r-sig-finance/2011q1/007250.html Since then, I rewrote the yahooKeystats function using the XML package. I tried contacting the Rmetrics Core Team to offer up this working code as a possible alternative but haven't gotten a response. What should I do? It seems like it would be a good idea to fix/replace the current function with something that works. Or should I just leave it be and not worry about it. Thanks. James ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
Re: [R-SIG-Finance] Excessive data needed for volatility{TTR} calculation?
Joshua, On Sat, May 28, 2011 at 7:13 AM, Joshua Ulrich josh.m.ulr...@gmail.com wrote: Actually, because the first return in the moving window would always be NA, it should be: sqrt(N/(n-2)*sum((r[-1]-mean(r[-1]))^2)) which yields the same result as: last(sqrt(N) * runSD(r, n-1)) I've been trying both lines of code and unfortunately I'm not getting the same results. The first line seems to only work properly for me in those instances when NCOL(OHLC) = n. For the more common situation where NCOL(OHLC) n, you would want a rolling window of vol calculations. I'm still thinking that the code should be: s - sqrt(N) * runSD(r, (n - 1)) As a frame of reference, I believe the output should be: getSymbols(SPY) tail(volatility(SPY)) [,1] 2011-05-20 0.1206382 2011-05-23 0.1181380 2011-05-24 0.1095445 2011-05-25 0.1069024 2011-05-26 0.1068434 2011-05-27 0.1038008 I've manually calculated the value for 2011-05-27 using a spreadsheet to confirm the value. I believe the other values to be correct also. After getting some sleep, it's clear that your initial solution (n-1) is correct. Your patch will be on R-forge shortly. Many thanks again! Best, -- Joshua Ulrich | FOSS Trading: www.fosstrading.com You may want to hold off on a patch in the short term. I still think there might be an error in there. I'm sorry to be such a nuisance about this, but thanks so much for your help. James ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
[R-SIG-Finance] Excessive data needed for volatility{TTR} calculation?
Hi, I have been using the volatility function from the TTR package and I noticed something that I thought was a bit unusual. I expected that I should be able to calculate the default 10-day volatility using the close estimator starting with 10 or maybe 11 days of data. That's not what I found. It appears that 18 days of data is necessary to calculate a 10-day volatility. For example: getSymbols(SPY) [1] SPY volatility(tail(SPY, 10), n = 10, calc = close, N = 260) Error in `[.xts`(x, beg:(n + beg - 1)) : subscript out of bounds volatility(tail(SPY, 11), n = 10, calc = close, N = 260) Error in `[.xts`(x, beg:(n + beg - 1)) : subscript out of bounds volatility(tail(SPY, 18), n = 10, calc = close, N = 260) [,1] 2011-05-03 NA 2011-05-04 NA 2011-05-05 NA - edited for brevity - 2011-05-23 NA 2011-05-24 NA 2011-05-25 NA 2011-05-26 0.09481466 Stranger still (at least to me), it appears that 38 days worth of data is necessary to start calculating a 20-day volatility. volatility(tail(SPY, 37), n = 20, calc = close, N = 260) Error in `[.xts`(x, beg:(n + beg - 1)) : subscript out of bounds volatility(tail(SPY, 38), n = 20, calc = close, N = 260) [,1] 2011-04-04NA 2011-04-05NA 2011-04-06NA - edited for brevity - 2011-05-23NA 2011-05-24NA 2011-05-25NA 2011-05-26 0.1088309 58 days of data is necessary for a 30-day volatility calculation. From looking at the code for the volatility function, I'm not seeing why so much additional data is needed to calculate the volatility. Does anybody have an idea of why so much additional data is necessary? Thanks. James R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
Re: [R-SIG-Finance] Excessive data needed for volatility{TTR} calculation?
On Fri, May 27, 2011 at 10:39 PM, Joshua Ulrich josh.m.ulr...@gmail.com wrote: I think your solution will work, but using 'n' instead of 'n-1'. The code below shows the same results using your solution and a formula similar to the one found here (which I mis-interpreted when I originally wrote the function): http://web.archive.org/web/20081224134043/http://www.sitmo.com/eq/172 set.seed(21) N - 260 n - 100 r - rnorm(n)/100 last(sqrt(N) * runSD(r, n)) sqrt(N/(n-1)*sum((r-mean(r))^2)) Thanks! -- Joshua Ulrich | FOSS Trading: www.fosstrading.com Hi Joshua, Thanks for replying and confirming my suspicions. However, I'm curious why you would use 'n' rather than 'n-1'. My thinking is that a 10-day volatility (n = 10) is calculated as the annualized standard deviation of 9 (n - 1) price returns (i.e. ln(p1/p0), ROC()). The sample standard deviation of 9 price returns would be the sum of the squared deviations divided by 9 - 1, or n - 2. Therefore, I believe your line sqrt(N / (n - 1) * sum((r - mean(r)) ^ 2)) should actually be sqrt(N / (n - 2) * sum((r - mean(r)) ^ 2)) I've been double-checking my work and went ahead and calculated 10 and 20-day vols by hand and I'm pretty sure s - sqrt(N) * runSD(r, (n - 1)) is correct, unless your defining 10-day volatility as 11 days of data and 10 price returns. Please let me know otherwise. Thanks. James ___ R-SIG-Finance@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-sig-finance -- Subscriber-posting only. If you want to post, subscribe first. -- Also note that this is not the r-help list where general R questions should go.
