The most recent trading strategy I've been researching has been based on so-called volatility arbitrage, a horrible misnomer for the strategy of trading volatility like an asset by taking a view and getting exposure (generally) through options. But since the modern options market has all but adopted a notion of equivalence between volatility and price, trading volatility really amounts to determining the true fair value of options written on a particular underlying. It's not really a forecasting problem so much as a modeling problem, although elementary forecasting does play a role in a good model.
I shared a bit of this information with a reader of this blog last night, and to my surprise, he commented that vol arb had been "picked clean" -- a term applied to strategies whose popularity has eclipsed their profitability. This term gets thrown around a lot with reference to "statistical arbitrage," a similarly misnamed strategy by which traders exploit gaps between correlated securities and bet that the gap will disappear over time.
The reason statistical arbitrage (as it is now known) is possible is because of two Nobel Prize winners named Robert Engle and Clive Granger. They won the prize for the development of a number of related time-series analysis techniques, one of which was the measure of "cointegration," which aptly embodies the "gap-ungap" property of a good stat arb pair.
The study of cointegration was borne of Engle and Granger's realization that correlation was really a terrible metric in most cases of statistical analysis. Thus, the statistical arbitrage opportunity was borne of a simple realization that one of the core beliefs of the markets -- that correlation is the correct measure of similarity -- was wrong. A paradigm shift takes place, and an opportunity arises until information diffusion has the opportunity to destroy it.
Once enough people knew how to implement a cointegration test, they could implement stat arb. And stat arb got picked flat. And it will remain flat until another paradigm shift comes along, and we are able to discover similar time series with great precision or quality, and then stat arb is back in full force.
The point is: opportunity is created by widespread misunderstanding. And to demonstrate just how much work there is left to do in quantitative finance, and how many opportunities still exist to exploit widespread ignorance, let me guide you through some of the theory of options valuation, and present some startling contradictions that you may find quite shocking.
But first, let me bore you with some mathematical history. The St. Petersburg Paradox is a problem worked on jointly by the Bernoulli brothers. It describes a lottery in which one buys a ticket, and the "dealer" of sorts flips a coin in succession until a tails comes up. If a tails comes up on the first flip, the gambler gets $1. If it comes up on the second, he gets $2, and the third, $4, and so on ad infinitum.
The problem: determine the fair price of a ticket. Most people would do this by taking expectations over the probability distribution defined by the payoffs, but get this -- the expectation is infinite! That implies that a human being would pay any price for a ticket!
Clearly, a human being wouldn't pay any price for a ticket. The Bernoulli brothers solve the problem by expressing the payoffs in terms of a diminishing marginal utility function (logarithmic) and show the fair value to be $2, which is a lot more sensible. The point of the paradox is how nonsensical an answer you can get by naively taking expectations.
Now let's turn our attention to the original work of Black and Scholes, something I intend to discuss plenty on this blog. Black and Scholes begin by dreaming up a portfolio containing a delta-hedged option position, and by no-arbitrage arguments reason that the portfolio must yield the risk-free rate, since it is itself risk-free.
This is the celebrated Black-Scholes differential equation, the form of which is the basis for the great majority of all derivative pricing methods. Since the equation has no risk-dependent parameters in it, like the stock's drift rate, they reason that the derivative's value is not dependent on the level of risk, or even the expected return, on a stock.
This is where it starts to get weird. They reason that since the derivative's value is independent of risk, that the value of an option in our world is the same as that of a derivative in a hypothetical universe called the "risk neutral world."
The risk-neutral world is a bit like Eden. All investors are 100% tolerant of risk. All securities earn the risk-free rate. Securities are all equal to their discounted expected value under the correct probability measure.
They reason that since the value of the derivative in our world is the same as in theirs, we may as well make life simple and value the derivative in their world. So they do -- they combine the differential equation obtained above with the solution to an Ito integral representing the stock price's lognormal diffusion (with drift equal to the risk free rate). That yields the Black-Scholes solution.
I hope the St. Petersburg paradox is contrasting nicely with this Nobel Prize-winning reasoning of Black and Scholes. We're going to make the comparison even more explicit by extending the discussion to the pricing of American options, which have the capability to be exercised at any point during their lifetime, not just at expiry.
The Black Scholes-style way to value an American option is using a binomial tree representation, popularized initially by Cox, Rubinstein and Ross. A tree is constructed in order to represent the lognormal process described above; each leaf node is annotated with its value; the other nodes are annotated with the discounted expected value of their children under the tree's induced probability measure.
Now, if the stock doesn't pay a dividend, we have a bizarre situation. Under the induced probability measure of the binomial tree, the discounted price process (by the Black-Scholes theory) is a martingale. Thus, we know there is no optimal stopping time. So, the value of the early exercise never exceeds the discounted expected value, and therefore is never taken. Therefore, the value of an American option on a non-dividend paying stock is equal to the value of the same European option on that stock.
You might need a minute to digest that. Yes, it's true. Under the Black-Scholes assumptions, an American option has the same value as a European one so long as there is no dividend. And these same assumptions that yield such a terrifying paradox also underlie the rest of the models used for pricing and risk management of derivative contracts.
The source of the contradiction is similar to the case of the St. Petersburg Paradox; the reckless taking of expectations, that reduction of a probability distribution to a scalar, is such a dangerous approach. And much more importantly, the idealistic assumptions of Black-Scholes don't just manifest themselves in an unrealistic price process with skinny tails, as people frequently point out, but in the very modeling of human behavior that underlies the model.
See, with European options, there's no behavior to model, since nobody really has much of a choice. The only choice happens at expiry, and you can bet your bottom dollar that the option will be exercised if and only if the option is in the money. With American options, on the other hand, the option holder is forced to make the choice of whether to exercise every second that the option is in the money. As in the case of the St. Petersburg Paradox, the assumption that humans are rational, expectations-taking automata is highly inappropriate in finance. In fact, options investors will tell you it's common knowledge to never hold an option to expiry; how ironic, then, that the behavior modeling of Black and Scholes leads to a scenario in which this is not just possible but unavoidable.
The real point of this article isn't about American options or the St. Petersburg Paradox, but the "standard of proof" in our nascent field. Will we accept gross generalizations, and ignore their shortcomings to the point we award the Nobel Prize to the mathematicians who created the above model? Or will we enforce a standard of rigor, look at problems on their face, and imagine creative solutions in real-life conditions?
The question isn't so much about proof as assumptions. It is one of the assumptions of Black and Scholes that leads to the notion of risk-neutral valuation, and hence this odd model of human behavior.
When I ask people what they think the worst assumption in Black-Scholes is, you usually get some swagger about fat tails and normal distributions, or maybe complete markets from those in the know. But here's the bigger one, the much, much bigger one:
Black and Scholes ignore transaction costs.
Is this a fair assumption? In most of economics, it is. Let's examine the case of stocks and bonds. Is it valid to ignore transaction costs when discussing a deal in stocks or bonds? I think so. It's possible that eventually transaction costs for simple assets like this will be driven to zero if humans are more able to find the appropriate counterparty due to greater access to information. And in the meantime, to be honest, it's really a fair assumption. Transaction costs here are low relative to the cost of carry and cost of buying the security, and they don't make much of a difference.
But options? Options aren't like stocks, in my mind. Remember, the basis of the Black-Scholes thinking was the delta-hedged portfolio yielding a risk-free rate. But in order to actually create that kind of portfolio, you need to hire a trader to sit there and manually hedge and re-hedge. In fact, the Black-Scholes differential equation represents a continuously re-hedged portfolio, implying virtually infinite transaction costs. And, since the derivative didn't exist in the first place, the transaction cost also includes writing the option and selling it. For options, transaction costs aren't a negligible factor -- they're everything.
It's clear that quantitative finance professionals have a long hill to climb in order to engender the kind of progress that would legitimize our work to the rest of the scientific community. But in this lack there lies a great amount of opportunity, not just for monetary gain, but for intellectual exploration and the fun of pushing the envelope. Clearly, there's something amiss about the theory underlying the most common of derivative pricing formulas. But it's unclear whether an easy solution exists. It seems there are still many questions to answer, not just mathematical, but behavioral and psychological. There is no doubt that quantitative finance has developed into a scientific discipline, but we may be surprised to find the aftertaste of other fields in papers to come.
Monday, August 30, 2010
Wednesday, August 25, 2010
The Difference Between a Pricing Model and a Trading Model
This morning on the brand new quant finance reddit, a user asked about the difference between a pricing model and a quant trading model. I realized that this is a question that often arises due to indiscriminate use of the world "model." And it becomes even murkier because pricing models can often play a part in quant trading models, in the sense that they are used to manage risks and potentially perform relative value analysis.
My comment and a link to the whole thread can be found here:
http://www.reddit.com/r/quantfinance/comments/d58sc/whats_the_difference_between_a_pricing_model_and/c0xnsli
I used to be rather unenthusiastic about pricing models; I wanted to learn the closely guarded secrets of the quant trading world, some kind of hidden spellbook of trading and mathematics that would teach me how to become a billionaire. But as I've learned more, and the wide world of finance has humbled me plenty, I've found that the two are more intertwined than I had thought. If nothing else, learning about pricing models helps you to think critically about the behavior of investors and markets.
Furthermore, risk, which is obviously quite related to pricing models, is fundamental to any good trading operation. In a comment (here) this morning I related a story about a meeting with a trader the other day. A few of his positions were missing their proprietary duration measures, a key interest rate risk statistic, and he remarked: "Without my risk, I'm flying blind." While quant models are extremely valuable if they can predict fundamental market occurrences like interest rate movements or stock market movements, they are worth nothing if you can't evaluate how these changes will affect your portfolio. And in that sense, risk and trading are inextricably connected.
My comment and a link to the whole thread can be found here:
http://www.reddit.com/r/quantfinance/comments/d58sc/whats_the_difference_between_a_pricing_model_and/c0xnsli
I used to be rather unenthusiastic about pricing models; I wanted to learn the closely guarded secrets of the quant trading world, some kind of hidden spellbook of trading and mathematics that would teach me how to become a billionaire. But as I've learned more, and the wide world of finance has humbled me plenty, I've found that the two are more intertwined than I had thought. If nothing else, learning about pricing models helps you to think critically about the behavior of investors and markets.
Furthermore, risk, which is obviously quite related to pricing models, is fundamental to any good trading operation. In a comment (here) this morning I related a story about a meeting with a trader the other day. A few of his positions were missing their proprietary duration measures, a key interest rate risk statistic, and he remarked: "Without my risk, I'm flying blind." While quant models are extremely valuable if they can predict fundamental market occurrences like interest rate movements or stock market movements, they are worth nothing if you can't evaluate how these changes will affect your portfolio. And in that sense, risk and trading are inextricably connected.
Monday, August 23, 2010
Introducing the Quant Finance Subreddit
http://www.reddit.com/r/quantfinance/
As I've said before, quantitative finance is a truly fascinating field of study. I think it appeals most to those who are attracted to new, unexplored territory, since so much of the theory is still under heated debate and it's clear to most that the best methods have yet to come. Working on quantitative finance now -- or more specifically, computational finance -- would be like working on geometry in ancient Greece or physics in the time of Newton.
Many people mistakenly blame the financial crisis on the quants. In fact, there was an article that made the cover of Wired about how a model called the Gaussian copula was to blame for the meltdown. But it also explained that the inventor of the model had time and again protested that management didn't understand the model's limitations. They make mention of his personal anguish at seeing the risk managers herald his simple formula as the solution to modelling risk in CDOs, when he knew very well that over-reliance on his simplistic formulation could be disastrous for the CDO market. This is the reason more people need to help this field along, in order to help avoid future such disasters.
But enough of this digression -- I started the quant finance subreddit in order to allow those of us with this very niche interest to share interesting papers we come across, ideas we have or software we write. There's a wonderful community of intellectual types on reddit and it would be great to have a community for discussing this subject matter without being off topic on either programming or math reddits. So please feel free to post whatever you like!
As I've said before, quantitative finance is a truly fascinating field of study. I think it appeals most to those who are attracted to new, unexplored territory, since so much of the theory is still under heated debate and it's clear to most that the best methods have yet to come. Working on quantitative finance now -- or more specifically, computational finance -- would be like working on geometry in ancient Greece or physics in the time of Newton.
Many people mistakenly blame the financial crisis on the quants. In fact, there was an article that made the cover of Wired about how a model called the Gaussian copula was to blame for the meltdown. But it also explained that the inventor of the model had time and again protested that management didn't understand the model's limitations. They make mention of his personal anguish at seeing the risk managers herald his simple formula as the solution to modelling risk in CDOs, when he knew very well that over-reliance on his simplistic formulation could be disastrous for the CDO market. This is the reason more people need to help this field along, in order to help avoid future such disasters.
But enough of this digression -- I started the quant finance subreddit in order to allow those of us with this very niche interest to share interesting papers we come across, ideas we have or software we write. There's a wonderful community of intellectual types on reddit and it would be great to have a community for discussing this subject matter without being off topic on either programming or math reddits. So please feel free to post whatever you like!
Monday, August 16, 2010
In Support of Oracle and Java
There's been a lot of Java hate recently, particularly from the open source world, and I have always struggled to see why. Perhaps its opponents lack the pragmatism to see value in diversification. Yes, Java is not a 100% free-as-in-speech platform. But there is immense value in an open source-friendly yet commercially backed platform upon which to build our projects.
Anybody functioning within the four walls of a company knows that, when it comes to big decisions, the executives tend to want to invest in a platform that isn't going anywhere -- and that means, backed by a big bad company. A company with real, long-term economic interest in the success of the technology. And so the adage goes, nobody ever got fired for buying IBM.
But today on Reddit, one of the few places I frequent where I notice this brand of Java hate, I remarked that Mr. Mueller of FOSS Patents blog had an interesting post about the Google-Oracle dispute, available here:
http://fosspatents.blogspot.com/2010/08/oracle-vs-google-licensing-issues.html
Since my current project is written in Java, you can likely imagine I have particularly strong feelings regarding the future direction of the Java platform following Oracle's acquisition. In fact, I thought long and hard about the environment upon which to build my newest creation -- a platform for financial analytics geared towards the quantitative trader/risk manager type -- before writing a single line of code.
Certainly, Mr. Mueller, whose techno-political inclinations can swiftly be ascertained from the name of his blog, has an aptitude with the minutiae of licensing agreements and a legal expertise that I clearly lack. However, I believe that in his dedication to his principles, it's possible that he overlooks what's best for the advancement of technology as a whole. He argues that a flawed, almost duplicitous community process for the Java platform brought about a pseudo-free environment that Google misperceived as genuinely so, ultimately landing them in hot water when they tried to build a mobile Java platform that deviated from the core specification. However, it is specifically this community process that makes Java a commercially viable platform. Java's unique hybrid quality, whereby it has an obvious affinity with the open source world (think Apache projects) while still being backed commercially by a company people trust, makes it an extraordinarily valuable platform not just for open source, nor for commercial software, but for the industry in its entirety.
Droid Does
Every wonder why "Droid Does"? Because Android code is written in Java, the most popular and most commonly taught programming language in the world. That means every coder and his grandmother can write code for an Android phone, since they already know the language, and they can likely write the majority of their app without even getting the Android developer tools (everything except the graphical components).
In order to use Java code on the phones, Google (with its infinite resource) actually re-implemented the Java technologies for mobile devices, basing it on the official Java specification. However, Oracle claims that Google made changes, additions or omissions that compromised the integrity of their implementation. This is actually a violation of the license agreements for the spec itself. One thing is for certain -- Google's "Dalvik" produces .dex files, which aren't compatible with the .class files typically used by the Java platform.
It might seem curious to the non-technical why this is so vitally important to technology companies -- what does Oracle care if Google adds a new feature to their implementation of Java? The reason is compatibility. The entire cohesiveness of the community and the reliability of the platform is compromised when competing dialects get introduced into the wild. When a user downloads Java code, he no longer knows whether Oracle's JVM can run it. Perhaps it's Dalvik code, using special Dalvik-only features.
"Why do we use FinCad?"
I think the value of Java is best illustrated by an example of what I will term "Layman's Paranoia."
The Layman's Paranoia is a simple concept, and since my readers may be technically oriented, I will switch to an example about cars, about which I know absolutely nothing. When something happens to my computer, I slowly work to diagnose the problem, search for the appropriate keywords on Google, and ultimately locate a forum post or HOWTO giving me a solution. Since I am well-acquainted with the diction of the IT world, it is easy for me to handle a computer issue in a calm, collected manner.
But when my car breaks down on the side of the road, I absolutely panic. I certainly don't know how to fix a car. I don't even know enough to diagnose how big my problem is, nor what kind of specialist I may need to call, nor how long the fix will take. This uncertainty is, quite simply, an operational risk sustained by anyone as ignorant as me driving an automobile. And that's precisely the situation you're in as a manager of a technology company with little-to-no genuine technology background (save Excel macros).
Because I'm ignorant about cars, I'm flighty, scared, and prone to pay exorbitant amounts of money to AAA or some kind of insurance club in order to have a tow truck to call when my car breaks down in rural Vermont. That way, when the going gets tough, the risk (whose magnitude I cannot assess a priori) will be handled.
This creates a triangular information asymmetry between customer, mechanic and club. And these asymmetries drive the business. The situation is precisely the same as when, while working as a consultant for a large hedge fund to build a risk management solution, I suggested using a FOSS financial math library.
We were paying unheard of amounts of money to use FinCad, a commercial financial software package, and at the risk of disparaging their good work, it didn't seem to be the ideal tool for our particular application. Meanwhile, the open source option was fairly incredible, allowing us scores of different algorithms for calculating the fair value of an option, or the OAS on a mortgage.
And he said: "But who do we call when it breaks?" He was unwilling to have a non-commercial application underlie the fund's risk management operations. Because if everything goes to hell and the risk system goes down -- well, everyone's going to be looking at him.
Now, I'm not talking about support contracts. Clearly, third-party vendors can offer support for whatever FLOSS packages they please. But, the survival of a genuine platform -- in the way that Java is a platform and .NET is a platform -- requires long-term interest from a corporation with vested financial interest in the success and longevity of the technology.
The Middle Road
Anybody functioning within the four walls of a company knows that, when it comes to big decisions, the executives tend to want to invest in a platform that isn't going anywhere -- and that means, backed by a big bad company. A company with real, long-term economic interest in the success of the technology. And so the adage goes, nobody ever got fired for buying IBM.
But today on Reddit, one of the few places I frequent where I notice this brand of Java hate, I remarked that Mr. Mueller of FOSS Patents blog had an interesting post about the Google-Oracle dispute, available here:
http://fosspatents.blogspot.com/2010/08/oracle-vs-google-licensing-issues.html
Since my current project is written in Java, you can likely imagine I have particularly strong feelings regarding the future direction of the Java platform following Oracle's acquisition. In fact, I thought long and hard about the environment upon which to build my newest creation -- a platform for financial analytics geared towards the quantitative trader/risk manager type -- before writing a single line of code.
Certainly, Mr. Mueller, whose techno-political inclinations can swiftly be ascertained from the name of his blog, has an aptitude with the minutiae of licensing agreements and a legal expertise that I clearly lack. However, I believe that in his dedication to his principles, it's possible that he overlooks what's best for the advancement of technology as a whole. He argues that a flawed, almost duplicitous community process for the Java platform brought about a pseudo-free environment that Google misperceived as genuinely so, ultimately landing them in hot water when they tried to build a mobile Java platform that deviated from the core specification. However, it is specifically this community process that makes Java a commercially viable platform. Java's unique hybrid quality, whereby it has an obvious affinity with the open source world (think Apache projects) while still being backed commercially by a company people trust, makes it an extraordinarily valuable platform not just for open source, nor for commercial software, but for the industry in its entirety.
Droid Does
Every wonder why "Droid Does"? Because Android code is written in Java, the most popular and most commonly taught programming language in the world. That means every coder and his grandmother can write code for an Android phone, since they already know the language, and they can likely write the majority of their app without even getting the Android developer tools (everything except the graphical components).
In order to use Java code on the phones, Google (with its infinite resource) actually re-implemented the Java technologies for mobile devices, basing it on the official Java specification. However, Oracle claims that Google made changes, additions or omissions that compromised the integrity of their implementation. This is actually a violation of the license agreements for the spec itself. One thing is for certain -- Google's "Dalvik" produces .dex files, which aren't compatible with the .class files typically used by the Java platform.
It might seem curious to the non-technical why this is so vitally important to technology companies -- what does Oracle care if Google adds a new feature to their implementation of Java? The reason is compatibility. The entire cohesiveness of the community and the reliability of the platform is compromised when competing dialects get introduced into the wild. When a user downloads Java code, he no longer knows whether Oracle's JVM can run it. Perhaps it's Dalvik code, using special Dalvik-only features.
"Why do we use FinCad?"
I think the value of Java is best illustrated by an example of what I will term "Layman's Paranoia."
The Layman's Paranoia is a simple concept, and since my readers may be technically oriented, I will switch to an example about cars, about which I know absolutely nothing. When something happens to my computer, I slowly work to diagnose the problem, search for the appropriate keywords on Google, and ultimately locate a forum post or HOWTO giving me a solution. Since I am well-acquainted with the diction of the IT world, it is easy for me to handle a computer issue in a calm, collected manner.
But when my car breaks down on the side of the road, I absolutely panic. I certainly don't know how to fix a car. I don't even know enough to diagnose how big my problem is, nor what kind of specialist I may need to call, nor how long the fix will take. This uncertainty is, quite simply, an operational risk sustained by anyone as ignorant as me driving an automobile. And that's precisely the situation you're in as a manager of a technology company with little-to-no genuine technology background (save Excel macros).
Because I'm ignorant about cars, I'm flighty, scared, and prone to pay exorbitant amounts of money to AAA or some kind of insurance club in order to have a tow truck to call when my car breaks down in rural Vermont. That way, when the going gets tough, the risk (whose magnitude I cannot assess a priori) will be handled.
This creates a triangular information asymmetry between customer, mechanic and club. And these asymmetries drive the business. The situation is precisely the same as when, while working as a consultant for a large hedge fund to build a risk management solution, I suggested using a FOSS financial math library.
We were paying unheard of amounts of money to use FinCad, a commercial financial software package, and at the risk of disparaging their good work, it didn't seem to be the ideal tool for our particular application. Meanwhile, the open source option was fairly incredible, allowing us scores of different algorithms for calculating the fair value of an option, or the OAS on a mortgage.
And he said: "But who do we call when it breaks?" He was unwilling to have a non-commercial application underlie the fund's risk management operations. Because if everything goes to hell and the risk system goes down -- well, everyone's going to be looking at him.
Now, I'm not talking about support contracts. Clearly, third-party vendors can offer support for whatever FLOSS packages they please. But, the survival of a genuine platform -- in the way that Java is a platform and .NET is a platform -- requires long-term interest from a corporation with vested financial interest in the success and longevity of the technology.
The Middle Road
The strong-fisted approach to community development portrayed by Mr. Mueller is certainly no exaggeration. But how else can Oracle (previously, Sun) make good on that implicit claim to the aforementioned executives that with Java comes reliability? Java supports a thriving open source ecosystem, including a multitude of scripting and dynamic languages, none of which would ever have been possible if Java had never gained the widespread adoption that it has.
There are some issues with the lawsuit. In basing its Android platform on Java, Google actually did a solid for Oracle and the Java community by publicizing their endorsement of the platform and precipitating yet another swathe of legacy Java code to be maintained for decades to come. Thanks to the network effect, this adds nothing but value to the Java community.
Nonetheless, I applaud Oracle for taking on Goliath in defense of the promise made to their users and shareholders. Java is something worth protecting, and something of great value to developers. Not only does it allow us to write once and run anywhere, but it actually bridges the two worlds of commercial viability and open source idealism in an elegant, if neither popular nor legally clearcut, way. It is important to keep the economic realities of intellectual property in mind, because often the survival of a technology depends on the kind of corporate stewardship Java enjoys. As a community, open source advocates need to stop pushing their ideas on people to the exclusion of all else, and instead recognize the symbiosis that can develop between the free and the proprietary.
Thursday, August 12, 2010
Obligatory First Post
I'm Jason Victor. I recently graduated from my alma mater in '09 (hence the handle "Jason Victor Dartmouth") where I studied computer science. I am generally enthused by mathematics and work in or around the financial markets.
But let me start a little farther back. I started programming when I was six. By about sixteen, I had figured out the craft of programming, as it were, and began searching for a more specific interest. I found it in what was then called "artificial intelligence." Now, I call it "machine learning." But no matter. More on that later.
Anyway, I was poor, since I was a kid, and I needed free data. And one source I found was financial data -- it's abundant, it's confusing, and it provides an interesting way to test statistical techniques. Little did I know that would lead me down a much more interesting path than even I had anticipated.
To my more academic readers, please don't immediately disregard my thoughts regarding finance. It's really a fascinating field. I find a lot of similarities between finance and physics -- in practice, both involve stretching current computational and mathematical boundaries, and in theory, there's so much conflict and argument that it's abundantly clear it really hasn't been figured out yet. Just as physicists come up with theories for different pieces of physics that inherently conflict with others, grappling tirelessly for the elusive Theory of Everything, the theory of finance is equally wrought with disturbing half-truths, unrealistic assumptions, and conflicting ideologies. It's poorly understood, at best. For those with a quantitative inclination and a trailblazing ideology, the financial markets are a literal paradise.
In the following pages, I plan to record my thoughts about these wonderfully interesting subjects. And I want to accomplish a couple different things.
For one, as someone that started programming at a young age and had to teach myself for most of my life, I feel for those in the same situation. I want to document everything I wish I had access to when I was learning; I want to chart a clearer course for those looking to learn how to hack beautifully.
I want to create something similar for those looking to understand quantitative finance. That is a particularly difficult thing to get your head around. Most start with either an ill-conceived plan to make millions or a meek interest in building a career around it -- and frankly, I don't hold it against either group. But, the world around us, for some reason, does make it a pain to learn.
Here's why. There are two parts to what I will from now on call "quantness":
Really, it would be easier to start off by learning about quantitative investment strategies. But, alas, those are a whole lot harder to get anyone to explain to you. If a strategy works, the last thing anyone is going to do would be tell you about it.
So, I will try to make what little order I can of the madness that is computer science, math and quant finance. I'm no professor, and I'm certainly not an expert in anything -- but, I have managed to get my head around these concepts just enough to truly fall in love with them, and I want to help others to do the same.
All the best,
Jason Victor
But let me start a little farther back. I started programming when I was six. By about sixteen, I had figured out the craft of programming, as it were, and began searching for a more specific interest. I found it in what was then called "artificial intelligence." Now, I call it "machine learning." But no matter. More on that later.
Anyway, I was poor, since I was a kid, and I needed free data. And one source I found was financial data -- it's abundant, it's confusing, and it provides an interesting way to test statistical techniques. Little did I know that would lead me down a much more interesting path than even I had anticipated.
To my more academic readers, please don't immediately disregard my thoughts regarding finance. It's really a fascinating field. I find a lot of similarities between finance and physics -- in practice, both involve stretching current computational and mathematical boundaries, and in theory, there's so much conflict and argument that it's abundantly clear it really hasn't been figured out yet. Just as physicists come up with theories for different pieces of physics that inherently conflict with others, grappling tirelessly for the elusive Theory of Everything, the theory of finance is equally wrought with disturbing half-truths, unrealistic assumptions, and conflicting ideologies. It's poorly understood, at best. For those with a quantitative inclination and a trailblazing ideology, the financial markets are a literal paradise.
In the following pages, I plan to record my thoughts about these wonderfully interesting subjects. And I want to accomplish a couple different things.
For one, as someone that started programming at a young age and had to teach myself for most of my life, I feel for those in the same situation. I want to document everything I wish I had access to when I was learning; I want to chart a clearer course for those looking to learn how to hack beautifully.
I want to create something similar for those looking to understand quantitative finance. That is a particularly difficult thing to get your head around. Most start with either an ill-conceived plan to make millions or a meek interest in building a career around it -- and frankly, I don't hold it against either group. But, the world around us, for some reason, does make it a pain to learn.
Here's why. There are two parts to what I will from now on call "quantness":
- The parts that have to do with making money
- The parts that don't have to do with making money
Really, it would be easier to start off by learning about quantitative investment strategies. But, alas, those are a whole lot harder to get anyone to explain to you. If a strategy works, the last thing anyone is going to do would be tell you about it.
So, I will try to make what little order I can of the madness that is computer science, math and quant finance. I'm no professor, and I'm certainly not an expert in anything -- but, I have managed to get my head around these concepts just enough to truly fall in love with them, and I want to help others to do the same.
All the best,
Jason Victor
Subscribe to:
Posts (Atom)