I'm trying to do a precise implementation of a Heston vanilla option pricer. Does there exist some reliable test cases that I can compare to? Preferable including some difficult combinations of parameters / maturity.

There was a very nice thread here where I posted high precision test cases, which were confirmed by other forum participants to at least 15-16 digits. (If I recall, they are actually good to at least 30 digits). But it got corrupted under some forum re-do, so is pretty unreadable. However, some of the cases got copied into some QuantLib code here. Search the page for "Testing Alan Lewis reference prices..".

p.s Here's the old thread if you can make any sense out of it. As you will read, Wilson2 confirmed the first batch of results to 15-16 digits. If you compare to QuantLib, you can probably infer where the missing line breaks are.

p.s Here's the old thread if you can make any sense out of it. As you will read, Wilson2 confirmed the first batch of results to 15-16 digits. If you compare to QuantLib, you can probably infer where the missing line breaks are.

I've deciphered the two first, but I can't make sense of the third one with the short maturity low vol of vol. Would you mind helping? It would be great to have this more challenging parameter set.

It's too bad the thread has been corrupted, it is immensely useful.

It's too bad the thread has been corrupted, it is immensely useful.

I'll see what I can do.

OK, I re-posted the first set from that thread at my blog here , as well as the set Mark Joshi asked for with [$]V_0 = T = 0.01[$]

OK, I re-posted the first set from that thread at my blog here , as well as the set Mark Joshi asked for with [$]V_0 = T = 0.01[$]

- Cuchulainn
**Posts:**64439**Joined:****Location:**Drosophila melanogaster-
**Contact:**

Huge shame. I needed some results on CIR today, but all gobbly gook as well.

It's too bad the thread has been corrupted, it is immensely useful.

"Compatibility means deliberately repeating other people's mistakes."

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

@Daniel,

Try printing the post you want with the Chrome browser. You get a bolder font with a different set of breaks -- might be slightly better.

@zukimaten,

Does the blog have what you wanted?

Try printing the post you want with the Chrome browser. You get a bolder font with a different set of breaks -- might be slightly better.

@zukimaten,

Does the blog have what you wanted?

Yes, that is perfect! Thank you very much!@zukimaten,

Does the blog have what you wanted?

Okay. So for the first test case I get agreement up to machine precision.

The second case the ITM I get an error of 1e-16 to ~1e-13 for OTM - this does though provide confirmation of a few more digits. I will try to do better, but I'm almost out of tricks.

The second case the ITM I get an error of 1e-16 to ~1e-13 for OTM - this does though provide confirmation of a few more digits. I will try to do better, but I'm almost out of tricks.

Thanks for the report. My results for the second case are less trustworthy. In both cases there is a Fourier integral that needs a cutoff. In the first case, I was able to give it to Mathematica with the cutoff literally set to Infinity, a built-in symbol. In the second, that didn't work, and I had to use a finite cutoff that I keep increasing (maybe by a factor of 10 each time, don't recall), until the results stopped changing.

Whatever number of digits you're able to finally agree with, I'll update my blog entry and mention that number, so I appreciate the report.

BTW, just to be clear, let's consider the last entry, the OTM call with strike = 110. When you say your error is ~ 10^(-13), do you mean absolute or relative? (AccuracyGoal or PrecisionGoal in Mathematica). In other words, since my answer comes with a 10^(-13), you confirm just the first couple digits of that one or do you match ~13 significant digits of it?

Now that I think about it, in that corrupted thread, mj mentioned agreement to "6 decimal places". This now seems ambiguous to me --- he may have just gotten 0 for the example in question. If so, even a couple good digits agreement may be a major advance!

Whatever number of digits you're able to finally agree with, I'll update my blog entry and mention that number, so I appreciate the report.

BTW, just to be clear, let's consider the last entry, the OTM call with strike = 110. When you say your error is ~ 10^(-13), do you mean absolute or relative? (AccuracyGoal or PrecisionGoal in Mathematica). In other words, since my answer comes with a 10^(-13), you confirm just the first couple digits of that one or do you match ~13 significant digits of it?

Now that I think about it, in that corrupted thread, mj mentioned agreement to "6 decimal places". This now seems ambiguous to me --- he may have just gotten 0 for the example in question. If so, even a couple good digits agreement may be a major advance!

I implemented a couple of methods slightly differently. The underlined digits are common between two methods, but disagree with the third.

9.98900159506528

4.98996347973817

0.467782671512844

2.52744782319478e-6

1.29932760052592e-13

9.98900159506528

4.98996347973817

0.467782671512844

2.52744782319478e-6

1.29932760052592e-13

I see -- thanks. That's a very good check and I just updated the blog to acknowledge it.

- jherekhealy
**Posts:**18**Joined:**

I don't think that the reference prices on the blog are accurate to all digits stated. I tried a Julia implementation of the cos method, using arbitrary precision real and complex balls, and end up with

7.9588781132567682852132606076142930308986569372596 for strike 80.

The error with the table is -2E-24.

I took care of setting up the parameters in multiple precision (for example, 0.02 is not exactly represented in 64-bit double format).

For Mark Joshi example, I find an error of 8e-26 for strike 90. This corresponds to the 18th digit.

7.9588781132567682852132606076142930308986569372596 for strike 80.

The error with the table is -2E-24.

I took care of setting up the parameters in multiple precision (for example, 0.02 is not exactly represented in 64-bit double format).

For Mark Joshi example, I find an error of 8e-26 for strike 90. This corresponds to the 18th digit.

I don't think that the reference prices on the blog are accurate to all digits stated. I tried a Julia implementation of the cos method, using arbitrary precision real and complex balls, and end up with

7.9588781132567682852132606076142930308986569372596 for strike 80.

The error with the table is -2E-24.

I took care of setting up the parameters in multiple precision (for example, 0.02 is not exactly represented in 64-bit double format).

For Mark Joshi example, I find an error of 8e-26 for strike 90. This corresponds to the 18th digit.

Thanks -- your results sound very plausible and compatible.

As I say in the blog, for the first table:

"With WorkingPrecision=50, I asked Mathematica for 20 good digits, which is probably a conservative estimate of how many good digits there are in the result."

Your results suggest that there are actually 23 good digits for that one.

For the more difficult 2nd table, I mentioned that at least 15 digits were confirmed for the 90 strike, and your results suggest no more than 18 are reliable.

- Cuchulainn
**Posts:**64439**Joined:****Location:**Drosophila melanogaster-
**Contact:**

aka FUBAR

"Compatibility means deliberately repeating other people's mistakes."

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl