In a rare straight up pointer to somebody else’s blog!:

How Has Functional Programming Influenced Your Coding Style?

When I have time, I will comment – but needless to say – my exposure to FP really has changed (in a positive way) my coding style.

-Chris

Responses are currently closed, but you can trackback from your own site.

Here are a few images that I have been showing people for the past several weeks.

and

These lovely images tell us things like:

• JP Chase seems to have some 84 Trillion in derivs exposure (and 1.3 trillion in actual assets)
• Citi seems to be in 2nd place with some less than half that derivs exposure (and 1.2 trillion in actual assets)
• Lehman and Deutsche are way at the lower end of the spectrum of total exposure
• Most of the big firms have their holdings in rate related contracts
• It is ALL about the OTC market contracts

It is an interesting picture, there are more here, but some folks have mentioned that cannot read this link behind most big bank internet content constraints.

Responses are currently closed, but you can trackback from your own site.

I was looking @ moving some code for a project that was started in C# to Ruby. 1stly, it is astounding how much less code it takes to do the same stuff. That however is not the reason I chose to post this morning.

Gabe and Micah are playing nicely together today (it is nice when a 3 and 5 year old brothers can get along so well). I have been fiddling with this code on the sofa and while moving my code, I came to move a c# Equals(object) method and the counterpart GetHashCode(). ReSharper is a great tool – it had given the basis for these overrides. Simple Alt+Insert gives you the ‘generate’ menu and from there you can ask it to generate these methods for you. Essentially – you tell ReSharper the fields that must be ‘unique’ and then it can handle the Equals and GetHashCode methods for you.

Here is what I had in my c# code:

Now this is fine (not exactly) for my C# application as I see it. ReSharper kindly churned out the code I needed also – which is great. When I moved it into ruby however, it looked very un-ruby. Astute readers will also notice that the implementations of Equals and GetHashCode do not match – the Alias property was added later, included in the Equals but NOT in the GetHashCode . Generating code has its issues it would seem.

One of the areas that ruby excels at is helping you write less code. Part of that is identifying the little repeated bits in your code and automating it away with a little ruby.

So what is the pattern above? Well – equals checks for null, checks for direct object reference comparison, then checks a number of fields. It also does a type check. Then it compares a number of fields. If any of these fields fails comparison – it returns false. Ruby does not really need the type check, it just says ‘if you have these props then you are fine by me’ (duck typing).

The folks @ JetBrains recognized the pattern – based on the input of what properties are unique, it generates a code snippet. In ruby, we will not generate code, but handle it like this:

Here include a module called SymbolHashEquals. In this module I define 2 methods symbol_hash and symbol_eql?. These methods take a list of attributes and then apply the same logic that resharper generated. This uses ruby’s symbols that allow you to refer to elements by the ‘name of the code’ or … symbol.

In stead of having our class generate methods based on a heuristic or 2, we simply make a module that holds that abstraction, then we include it, and have our host class use it. Essentially, since ruby lets you ‘do more with less’ we do not have to ‘generate more code’ – we simply can codify more into our solution and have less dumb, generated code. Instead of investing in software to generate more code, we do less!

Here is our module that works on the symbols and handes the standard eql?and hash.

Now – rather than generating code every time I need that same logical heuristic, I simply include that 1 module, and we are good to go. Less code, less repetition, etc.

There you have it – ruby rocks!

=Chris=

Responses are currently closed, but you can trackback from your own site.

I was speaking with a few colleagues this week about dispersion trading. I though I had a basic understanding of what a dispersion trade was, but as we talked about it – I said to myself; it seems just like stat arb for volatility.

So, this weekend, as Gabe is sitting next to me playing his Legend of Zelda; I found this article @ Risk Latte. It says essentially what i thought – and even calls dispersion trading “volatility arbitrage”. I will not re-explain what the article says infinitely better than I could, but I thought it was interesting how simply connecting a concept you know to something you vaguely understand solidifies the understanding.

It is amazing how much I know that I do not know

-Chris

Responses are currently closed, but you can trackback from your own site.

Here is a quickie primer on AISs or immune system inspired algorithms. Essentially AISs do a good job of figuring out what is ‘itself’ or ‘normal’ and what is ‘non-self’, ‘alien’ or ‘abnormal’ in a system. Antigens are components that find pathogens (antigens find patterns that are normal to them, the non-normal things then are pathogens).

Some ~2 or 3 years ago, MIT’s Journal of Evolutionary Computation had a ’special issue’ on AISs. There were several interesting publications in that particular issue, and it led me on a minor reading splurge regarding AISs. At the time, I had been heavily focused on evolutionary and other bio-inspired algorithms and their applications for automated trading systems. There are a ton of algorithms in this class, many of them have mappings to various sub-problems in automated trading.

As far as I can find, there is no work out there currently that applies AISs to finding mis-priced options, and it seems quite a good fit. Searching over a sea of options to sort out which one seem to be aberrations may be a good match. AISs are relatively efficient algorithms compared to alternatives. Interestingly – it would not even necessarily involve your own option pricing model – you would be basically letting the AIS sort out what seem to be ‘normal’ pricings and what seem to stand out as odd.

This is obviously one component of the puzzle, sorting out if the option should be bought or sold is another component. This particular technique could also be applied to any other derivative market with ample liquidity, not just options.

Just some nonsense that has been meandering around my brain for a week or so, so I figured I would write it up here.

-Chris

Responses are currently closed, but you can trackback from your own site.

I am reading an interesting and timely book on the current credit crisis; The Trillion Dollar Meltdown. I will update with my thoughts on the book when I am done with it, but I wanted to comment on 1 particular element presently…

There have been several theories on why the 1987 crash happened, but it seems that at least 2 books agree that it was due to ‘everybody using Portfolio Insurance’. The other book was Bookstabber’s Demons of our Own Design (which I quite enjoyed). Essentially, some smart folks came up with portfolio insurance. It worked well for them, they started selling it as a service to other firms. Soon enough, everybody was doing it. When the portfolios started hitting their floors, there was a fantastic circular reaction between markets that were now interconnected via portfolio insurance programs all over the street. Downward spiral ensues. Money disappears, etc.

I just thought it was noteworthy that this is the 2nd book that said outright that the basic issue was primarily portfolio insurance.

-Chris

PS – I am wondering if CPPI (zero coupon bonds usually involved) vs the futures technique referred to in the case of the ‘87 crash are the same? Is CPPI an evolution of that portfolio insurance? Always more to learn.

Responses are currently closed, but you can trackback from your own site.

Responses are currently closed, but you can trackback from your own site.