Better Fonts in Fedora than in Ubuntu

By default, text in Fedora 19 looks ok but not great. There are good tips to improve fonts on http://fedorasolved.org/Members/khaytsus/improve-fonts

As root user here is what need to be done:

cd /etc/fonts/conf.d

ln -s /usr/share/fontconfig/conf.avail/10-autohint.conf

ln -s /usr/share/fontconfig/conf.avail/11-lcdfilter-default.conf

yum install freetype-freeworld

Reboot, then, in gnome-tweak-tool choose hinting = slight, and antialiasing = rgba. I also choose the liberation sans and liberation mono fonts.

I am not sure which one did the trick, but it looks much better (even better than my laptop under Ubuntu, not sure why).

Better Fonts in Fedora than in Ubuntu

By default, text in Fedora 19 looks ok but not great. There are good tips to improve fonts on http://fedorasolved.org/Members/khaytsus/improve-fonts

As root user here is what need to be done:

cd /etc/fonts/conf.d

ln -s /usr/share/fontconfig/conf.avail/10-autohint.conf

ln -s /usr/share/fontconfig/conf.avail/11-lcdfilter-default.conf

yum install freetype-freeworld

Reboot, then, in gnome-tweak-tool choose hinting = slight, and antialiasing = rgba. I also choose the liberation sans and liberation mono fonts.

I am not sure which one did the trick, but it looks much better (even better than my laptop under Ubuntu, not sure why).

Attari, Lord-Kahl & Cos Methods Comparison on Heston

I recently wrote about the Cos method. While rereading the various papers on Heston semi-analytical pricing, especially the nice summary by Schmelzle, it struck me how close were the Attari/Bates methods and the Cos method derivations. I then started wondering if Attari was really much worse than the Cos method or not.

I noticed that Attari method accuracy is directly linked to the underlying Gaussian quadrature method accuracy. I found that the doubly adaptive Newton-Cotes quadrature by Espelid (coteda) was the most accurate/fastest on this problem (compared to Gauss-Laguerre/Legendre/Extrapolated Simpson/Lobatto). If the accuracy of the integration is 1e-6, Attari maximum accuracy will also be 1E-6, this means that very out of the money options will be completely mispriced (might even be negative). In a sense it is similar to what I observed on the Cos method.

"Lord-Kahl" uses 1e-4 integration accuracy, "Attari" uses 1E-6, and "Cos" uses 128 points. The reference is computed using Lord-Kahl with Newton-Cotes & 1E-10 integration accuracy.
Well here are the results in terms of accuracy:

 

As expected, Lord-Kahl absolute accuracy is only 1E-5 (a bit better than 1E-4 integration accuracy), while Attari is a bit better than 1E-6, and Cos is nearly 1E-7 (higher inaccuracy in the high strikes, probably because of the truncation inherent in the Cos method).

The relative error tells a different story, Lord-Kahl is 1E-4 accurate here, over the full range of strikes. It is the only method to be accurate for very out of the money options: the optimal alpha allows to go beyond machine epsilon without problems. The Cos method can only go to absolute accuracy of around 5E-10 and will oscillate around, while the reference prices can be as low as 1E-25. Similarly Attari method will oscillate around 5E-8.


What's interesting is how much time it takes to price 1000 options of various strikes and same maturity. In Attari, the charateristic function is cached.

Cos 0.012s
Lord-Kahl 0.099s
Attari 0.086s
Reference 0.682s

The Cos method is around 7x faster than Attari, for a higher accuracy. Lord-Kahl is almost 8x slower than Cos, which is still quite impressive given that here, the characteristic function is not cached, plus it can price very OTM options while following a more useful relative accuracy measure. When pricing 10 options only, Lord-Kahl becomes faster than Attari, but Cos is still faster by a factor of 3 to 5.

It's also quite impressive that on my small laptop I can price nearly 100K options per second with Heston.

Attari, Lord-Kahl & Cos Methods Comparison on Heston

I recently wrote about the Cos method. While rereading the various papers on Heston semi-analytical pricing, especially the nice summary by Schmelzle, it struck me how close were the Attari/Bates methods and the Cos method derivations. I then started wondering if Attari was really much worse than the Cos method or not.

I noticed that Attari method accuracy is directly linked to the underlying Gaussian quadrature method accuracy. I found that the doubly adaptive Newton-Cotes quadrature by Espelid (coteda) was the most accurate/fastest on this problem (compared to Gauss-Laguerre/Legendre/Extrapolated Simpson/Lobatto). If the accuracy of the integration is 1e-6, Attari maximum accuracy will also be 1E-6, this means that very out of the money options will be completely mispriced (might even be negative). In a sense it is similar to what I observed on the Cos method.

"Lord-Kahl" uses 1e-4 integration accuracy, "Attari" uses 1E-6, and "Cos" uses 128 points. The reference is computed using Lord-Kahl with Newton-Cotes & 1E-10 integration accuracy.
Well here are the results in terms of accuracy:

 

As expected, Lord-Kahl absolute accuracy is only 1E-5 (a bit better than 1E-4 integration accuracy), while Attari is a bit better than 1E-6, and Cos is nearly 1E-7 (higher inaccuracy in the high strikes, probably because of the truncation inherent in the Cos method).

The relative error tells a different story, Lord-Kahl is 1E-4 accurate here, over the full range of strikes. It is the only method to be accurate for very out of the money options: the optimal alpha allows to go beyond machine epsilon without problems. The Cos method can only go to absolute accuracy of around 5E-10 and will oscillate around, while the reference prices can be as low as 1E-25. Similarly Attari method will oscillate around 5E-8.


What's interesting is how much time it takes to price 1000 options of various strikes and same maturity. In Attari, the charateristic function is cached.

Cos 0.012s
Lord-Kahl 0.099s
Attari 0.086s
Reference 0.682s

The Cos method is around 7x faster than Attari, for a higher accuracy. Lord-Kahl is almost 8x slower than Cos, which is still quite impressive given that here, the characteristic function is not cached, plus it can price very OTM options while following a more useful relative accuracy measure. When pricing 10 options only, Lord-Kahl becomes faster than Attari, but Cos is still faster by a factor of 3 to 5.

It's also quite impressive that on my small laptop I can price nearly 100K options per second with Heston.

Giving Fedora Another Chance

I have had some stability issues with the Ubuntu 13.04 on my home computer, not on my laptop. It might be related to hard disk encryption (out of curiosity I encrypted my main hard drive in the installer option, resulting in a usable but quite slow system - it's incredible how much the hard drive is still important for performance). I did not have any particular issue on my work laptop with it.

Anyway I gave Fedora 19 a try, with Gnome Shell, even if I am no particular fan of it. So far so good, it seems more stable than my previous Fedora 17 trial, and I get used to Gnome Shell. It's quite different, so it takes a while to get used to, but it is as productive as any other env (maybe more so even).

It made me notice that Ubuntu One cloud storage is much less open that it seems: it's extremely difficult to make it work under Fedora. Some people manage this, I did not. I moved to owncloud, which fits my needs.

Giving Fedora Another Chance

I have had some stability issues with the Ubuntu 13.04 on my home computer, not on my laptop. It might be related to hard disk encryption (out of curiosity I encrypted my main hard drive in the installer option, resulting in a usable but quite slow system - it's incredible how much the hard drive is still important for performance). I did not have any particular issue on my work laptop with it.

Anyway I gave Fedora 19 a try, with Gnome Shell, even if I am no particular fan of it. So far so good, it seems more stable than my previous Fedora 17 trial, and I get used to Gnome Shell. It's quite different, so it takes a while to get used to, but it is as productive as any other env (maybe more so even).

It made me notice that Ubuntu One cloud storage is much less open that it seems: it's extremely difficult to make it work under Fedora. Some people manage this, I did not. I moved to owncloud, which fits my needs.

Julia and the Cumulative Normal Distribution

I just stumbled upon Julia, a new programming language aimed at numerical computation. It's quite new but it looks very interesting, with the promise of C like performance (thanks to LLVM compilation) with a much nicer syntax and parallelization features.

Out of curiosity, I looked at their cumulative normal distribution implementation. I found that the (complimentary) error function (directly related to the cumulative normal distribution) algorithm relies on an algorithm that can be found in the Faddeeva library. I had not heard of this algorithm or this library before, but the author, Steven G. Johnson, claims it is faster and as precise as Cody & SLATEC implementations. As I previously had a look at those algorithms and was quite impressed by Cody's implementation.

The source of Faddeeva shows a big list (100) of Chebychev expansions for various ranges of a normalized error function. I slightly modified the Faddeva code to compute directly the cumulative normal distribution, avoiding some exp(-x*x)*exp(x*x) calls on the way.

Is it as accurate? I compared against a high precision implementation as in my previous test of cumulative normal distribution algorithms. And after replacing the exp(-x*x) with Cody's trick to compute it with higher accuracy, here is how it looks (referenced as "Johnson").

I also measured performance on various ranges, and found out that this Johnson algorithm is around 2x faster than Cody (in Scala) and 30% faster than my optimization of Cody (using a table of exponentials for Cody's trick).

Julia and the Cumulative Normal Distribution

I just stumbled upon Julia, a new programming language aimed at numerical computation. It's quite new but it looks very interesting, with the promise of C like performance (thanks to LLVM compilation) with a much nicer syntax and parallelization features.

Out of curiosity, I looked at their cumulative normal distribution implementation. I found that the (complimentary) error function (directly related to the cumulative normal distribution) algorithm relies on an algorithm that can be found in the Faddeeva library. I had not heard of this algorithm or this library before, but the author, Steven G. Johnson, claims it is faster and as precise as Cody & SLATEC implementations. As I previously had a look at those algorithms and was quite impressed by Cody's implementation.

The source of Faddeeva shows a big list (100) of Chebychev expansions for various ranges of a normalized error function. I slightly modified the Faddeva code to compute directly the cumulative normal distribution, avoiding some exp(-x*x)*exp(x*x) calls on the way.

Is it as accurate? I compared against a high precision implementation as in my previous test of cumulative normal distribution algorithms. And after replacing the exp(-x*x) with Cody's trick to compute it with higher accuracy, here is how it looks (referenced as "Johnson").

I also measured performance on various ranges, and found out that this Johnson algorithm is around 2x faster than Cody (in Scala) and 30% faster than my optimization of Cody (using a table of exponentials for Cody's trick).

The COS method for Heston

Fang, in his thesis, has the idea of the COS method and applies it to Heston. There are several published papers around it to price options under various models that have a known characteristic function, as well as to price more exotic options like barriers or bermudans.

The COS method is very close to the more standard Heston quasi analytic formula (use transform of characteristic function for the density and integrates the payoff with the density, exchanging summation), except that the more simple Fourier series are used instead of the standard Fourier transform. As a consequence there are a few more approximations that are done related to the truncation of the domain of integration and the result is already discrete, so no need for a Gaussian quadrature.

In practice, the promise is to be faster. I was wondering how stable it was, especially with regards to short maturities/large strikes.

It's quite easy to code, I made only one mistake initially: I forgot to handle the first element of the sum differently. It is however very unstable for call options prices, because the upper integration boundary is then used in an exponential, which explodes in most cases I have tried, while for put options, the lower boundary is used in an exponential, and the lower boundary is negative.

Price is too low at high strikes

So one has to rely on the put-call parity formula to compute call prices. This means that we are limited to something around machine epsilon accuracy and can't compute a very out-of-the-money call price, contrary to the Lord-Kahl method. However it seemed stable for the various Heston parameters I have tried and accurate as long as the resulting price is not too small as the following graph shows.

Price is way too high at low strikes

I was surprised to see that the more in-the-money put options also have inaccuracy: the price given is actually less than the final payoff. This is related to the domain of truncation. If I double it (L=24 instead of L=12), those disappear, what remains is that OTM puts can't go beyond 1e-12 for the COS method.

In practice the COS method was effectively 2x to 3x faster than my Lord-Kahl implementation. As a side note, on this problem, Java is only 2x faster than Octave.

As long as we don't care about very small option prices, it is an interesting alternative, especially because it is simple.

Update April 2014 - There is more information on the subject in my paper at http://papers.ssrn.com/abstract=2362968

The COS method for Heston

Fang, in his thesis, has the idea of the COS method and applies it to Heston. There are several published papers around it to price options under various models that have a known characteristic function, as well as to price more exotic options like barriers or bermudans.

The COS method is very close to the more standard Heston quasi analytic formula (use transform of characteristic function for the density and integrates the payoff with the density, exchanging summation), except that the more simple Fourier series are used instead of the standard Fourier transform. As a consequence there are a few more approximations that are done related to the truncation of the domain of integration and the result is already discrete, so no need for a Gaussian quadrature.

In practice, the promise is to be faster. I was wondering how stable it was, especially with regards to short maturities/large strikes.

It's quite easy to code, I made only one mistake initially: I forgot to handle the first element of the sum differently. It is however very unstable for call options prices, because the upper integration boundary is then used in an exponential, which explodes in most cases I have tried, while for put options, the lower boundary is used in an exponential, and the lower boundary is negative.

Price is too low at high strikes

So one has to rely on the put-call parity formula to compute call prices. This means that we are limited to something around machine epsilon accuracy and can't compute a very out-of-the-money call price, contrary to the Lord-Kahl method. However it seemed stable for the various Heston parameters I have tried and accurate as long as the resulting price is not too small as the following graph shows.

Price is way too high at low strikes

I was surprised to see that the more in-the-money put options also have inaccuracy: the price given is actually less than the final payoff. This is related to the domain of truncation. If I double it (L=24 instead of L=12), those disappear, what remains is that OTM puts can't go beyond 1e-12 for the COS method.

In practice the COS method was effectively 2x to 3x faster than my Lord-Kahl implementation. As a side note, on this problem, Java is only 2x faster than Octave.

As long as we don't care about very small option prices, it is an interesting alternative, especially because it is simple.

Update April 2014 - There is more information on the subject in my paper at http://papers.ssrn.com/abstract=2362968