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:**58987**Joined:****Location:**Amsterdam-
**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.

@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.

GZIP: On