<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Java Finance on Chase the Devil</title>
		<link>https://31416.org/tags/java-finance/</link>
		<description>Recent content in Java Finance on Chase the Devil</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 17 Aug 2009 12:04:00 +0000</lastBuildDate>
		
			<atom:link href="https://31416.org/tags/java-finance/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Implicit Finite Differences Method For Pricing Barrier Option</title>
				<link>https://31416.org/post/implicit-finite-differences-method-for-pricing-barrier-option/</link>
				<pubDate>Mon, 17 Aug 2009 12:04:00 +0000</pubDate>
				<guid>https://31416.org/post/implicit-finite-differences-method-for-pricing-barrier-option/</guid>
				<description>&lt;a onblur=&#34;try {parent.deselectBloggerImageGracefully();} catch(e) {}&#34; href=&#34;http://3.bp.blogspot.com/_9RyqGT46Fbk/Sokrd-84xhI/AAAAAAAAERE/-gs3_MMw0oo/s1600-h/implicit_method_barrier_option_html_m531cf9ea.jpg&#34;&gt;&lt;img style=&#34;float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 74px;&#34; src=&#34;http://3.bp.blogspot.com/_9RyqGT46Fbk/Sokrd-84xhI/AAAAAAAAERE/-gs3_MMw0oo/s320/implicit_method_barrier_option_html_m531cf9ea.jpg&#34; border=&#34;0&#34; alt=&#34;&#34;id=&#34;BLOGGER_PHOTO_ID_5370871824730605074&#34; /&gt;&lt;/a&gt;&lt;br /&gt;While trying to price a simple knock down and out barrier option, I encountered several difficulties I did not expect with the implicit finite differences method. The explicit method has less issues with barrier options pricing. I will show here what the tricky parts are and why explicit seems simpler in this case.&lt;br /&gt;&lt;br /&gt;The full article is &lt;a href=&#34;http://www.31416.org/static/implicitbarrier/implicit_method_barrier_option.pdf&#34;&gt;here (pdf)&lt;/a&gt; or &lt;a href=&#34;http://www.31416.org/static/implicitbarrier/implicit_method_barrier_option.html&#34;&gt;here (html)&lt;/a&gt; (the later is not very well formatted).&lt;br /&gt;&lt;br /&gt;Algorithms used in this article can be found at &lt;a href=&#34;http://code.google.com/p/javamc/&#34;&gt;http://code.google.com/p/javamc/&lt;/a&gt;</description>
			</item>
			<item>
				<title>On Quasi Random Numbers - MersenneTwister vs Sobol precision in Asian Option Pricing</title>
				<link>https://31416.org/post/on-quasi-random-numbers---mersennetwister-vs-sobol-precision-in-asian-option-pricing/</link>
				<pubDate>Tue, 05 May 2009 15:02:00 +0000</pubDate>
				<guid>https://31416.org/post/on-quasi-random-numbers---mersennetwister-vs-sobol-precision-in-asian-option-pricing/</guid>
				<description>While starting a side project that does Monte Carlo pricing in Java (&lt;a href=&#34;http://code.google.com/p/javamc/&#34;&gt;http://code.google.com/p/javamc/&lt;/a&gt; - nothing yet there I am waiting for Mercurial repository support), I wondered what was the importance of quasi random numbers versus more regular pseudo random numbers in Monte Carlo simulations.&lt;br /&gt;&lt;br /&gt;This brought me to read more carefully several books about Monte Carlo and Finance (&lt;a href=&#34;http://www.amazon.com/Complete-Guide-Option-Pricing-Formulas/dp/0786312408&#34;&gt;Haug Option Pricing&lt;/a&gt;, &lt;a href=&#34;http://www.amazon.com/Primer-Monte-Carlo-Method/dp/084938673X&#34;&gt;Sobol Primer on Monte Carlo&lt;/a&gt;, and &lt;a href=&#34;http://www.amazon.com/Financial-Engineering-Stochastic-Modelling-Probability/dp/0387004513&#34;&gt;Glasserman Monte Carlo Methods in Finance Engineering&lt;/a&gt;). I had quite a hard time to understand why the dimension of the quasi random generator was so important to price an asian option. Intuitively I thought the averaging points of an asian option were all on the same path, so they should be using the same random generator. This is very wrong as one does not care about the path in the first place but just in simulating each point in the average (using the regular black and scholes hypothesis). Finding the estimation for the average on the given points forces to use independent random generators for each point, because we want to approximate the estimation by the sum over those random points for each point.&lt;br /&gt;&lt;br /&gt;There is another simple argument to explain why independence of the random generators is so important. If we use the same generator for each point, then each point will move exactly the same way at each simulation. The average of those point will therefore behave exactly the same way as if there was only 1 point using the same generator. And we don&#39;t price an asian anymore but just a regular vanilla option.&lt;br /&gt;&lt;br /&gt;Using a pseudo random generator, one does not see the problem of dimension, because we can create N independent dimensions by just taking numbers N by N on a pseudo random generator. So effectively having 1 or N dimensions is the same on a pseudo random generator.&lt;br /&gt;&lt;br /&gt;Still I wrote a small test to see if a 1D quasi random generator was so bad when simulating N dimensions (taking values N by N on the quasi random generator). Here are the results:&lt;br /&gt;&lt;br /&gt;&lt;span style=&#34;font-size:85%;&#34;&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;MersenneTwister vs MersenneTwister on 10D asian:&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:43:51,111  INFO MonteCarloSimulationTest:114 - 867970000 -- expPrice=0.978958644504466&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:43:51,428  INFO MonteCarloSimulationTest:120 - 314619000 -- expPrice=0.9733220318545934&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:43:51,430  INFO MonteCarloSimulationTest:122 - relative difference=-0.005757763804951897&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new; font-weight: bold;&#34;&gt;can be as high as 2%&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;Sobol vs MersenneTwister on 10D asian:&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:48:46,909  INFO MonteCarloSimulationTest:115 - 980209000 -- expPrice=0.9895032774079221&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:48:47,345  INFO MonteCarloSimulationTest:121 - 433685000 -- expPrice=0.9790264042895171&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:48:47,348  INFO MonteCarloSimulationTest:123 - relative difference=-0.010588012548932534&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new; font-weight: bold;&#34;&gt;about 1% it is actually bounded by MersenneTwister precision.&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;Sobol vs Sobol1D on 10D asian:&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:47:08,614  INFO MonteCarloSimulationTest:115 - 717444000 -- expPrice=0.8810736428068913&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:47:08,925  INFO MonteCarloSimulationTest:121 - 308499000 -- expPrice=0.9791449305055208&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new;&#34;&gt;14:47:08,927  INFO MonteCarloSimulationTest:123 - relative difference=0.11130884290920073&lt;/span&gt;&lt;br /&gt;&lt;span style=&#34;font-family: courier new; font-weight: bold;&#34;&gt;about 10% and stays that way even when increasing number of simulations.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;Using an asian rate with 10 points, we see that Sobol1D will always give a very bad estimate, no matter the number of simulations. While Sobol used properly will give (much) better precision for less iterations. So even though there is the word random in quasi random, the numbers are very far from being random or even behaving like random numbers. It helped me to read about Van der Corput and Halton numbers to really understand quasi random numbers.</description>
			</item>
	</channel>
</rss>
