(I had this stupid post 75% typed, and my IE crashed… Microsoft, Vista and friends have been GETTING ON MY NERVES!) 

So… I had a recent post about variance swaps. I have been thinking a fair bit about the ideas of volatility – it is after all what options are all about. It is just interesting to me how darn versitile options are. It is possible to put together really novel views of risk depending on your options strategy. Strategies focused on volatility are what I am currently working through mentally. 

How to profit from volatility
Here is a good post on volatility strategies using vanilla options. Essentially – you can put together combinations of options that allow you to “focus in on” and profit based on the volatility characteristics/ changes. They mention the concept of volatility of volatility which reminds me of some work I did in the past with a guy named Lester Ingber – really, really bright guy. 

Volatility of Volatility
Lester’s article on Volatility of Volatility. This is interesting inasmuch as it is another layer of derivation on top of volatility. The idea that volatility itself has volatility is just another example of the complex mechanics that make up the financial world we are part of. We did work in this space looking at ways to achieve “adaptation” of trading system parameters based on volatility – and on volatility of volatility. Lester’s work is excellent – I also suggest reading his CMI work here and his work on Adaptive Simulated Annealing (the work I originally found him for) is also excellent. 

Dispersion Trading 
I have also been working over dispersion trading ideas – here is a good article from IVolatility.com (Good site, I used to get IV info from these guys for implementing an ETF trading strategy based on options and opening range breakout). 

Volatility Arbitrage
Daily options report has a good set of posts on volatility arb’ing. The most recent post is pointing to potential arb opportunities between the VIX and VXN – or the S&P market and NASDAQ market. The article mentions “mean reversion of volatility” – which brings me back to a few years ago… 

Toby Crabel and Mean Reversion
Toby Crabel is a relatively famous trader that popularized (to the best of my understanding) a particular trade patter for stocks and futures based on HV ratios. Essentially - you take a short range return/ longer range return and you get a ratio. This basically says things to you like; “today the volatility is relatively low” or “yesterday the volatility was relatively high”. The idea is based on the concept that “volatility is mean reverting“. This means that when volatility is relatively high, it is more likely it will be relatively low next. Often volatility arbing strategies depend on this concept. I worked through most of the “crabel-isms” a few years back while working on automated trading strategies based on some of Crabel’s ideas. 

All of this volatility stuff does bring me back to past experiences. The difference is that in the past we were looking at this information for different reasons. Currently, I am trying to understand all the more the detailed bits and pieces that would allow you to make trades that allow you to trade a view on volatility… interesting stuff!!! 

-Chris 

 

You can leave a response, or trackback from your own site.

I have been reading the prag progammers Programming Erlang – Software for a Concurrent World. I have been looking casually @ Erlang for a few months. The thing that initially interested me about Erlang was the “concurrency thing”. Erlang is beyond concurrency friendly – it is built into the language core. Erlang is all about concurrent programming on 1-N CPUs/ machines.

I have been a casual to semi-serious ruby lover for some time. I have not been able to use it 9-5 (except for the odd task I need to script – like aggregating unit test statistics across an enterprise, etc.). I have more recently gotten to giving python (yeah – the iron variety) a go. These languages are great – they are also inherently “object oriented”.

Erlang is not object oriented. This both repulsed and attracts me at once to it. It repulses me because I have baked in the OO-isms to my core.

Erlang is a general-purpose concurrent programming language and runtime system. The sequential subset of Erlang is a functional language, with strict evaluation, single assignment, and dynamic typing.

(wikipedia)

The fact that you have no classes, variables are declared in upper case and you deal primarily in functions is amazing and radically different than OO. Variables are “single assignment” (once you set X – you cannot change it). Again – I say – there are no classes!! I am really interested in working from a totally different perspective. The functional sequential portion of erlang is very interesting. I will have to post another time about pattern matching and how method lookup works – it is interesting.

Erlang is all about concurrency.

Erlang’s main strength is support for concurrency. It has a small but powerful set of primitives to create processes and communicate between them. Processes are the primary means to structure an Erlang application. Erlang processes are neither OS processes nor OS threads, but lightweight threads somewhat similar to Java’s “green threads“. Their estimated minimal overhead for each is 300 bytes, so many of them can be created without degrading performance.  (a benchmark with 20 million processes was tried)

(wikipedia – again)

I wll have to make another post about how you send/ receive/ spawn in erlang to communicate between processes – but it is very interesting.

In short – erlang is really a cool language that is pushing my brain to consider real – different alternatives to “the way I have been working for years more or less”.

Consider this post - Ralph Johnson thinks Erlang could even be “the next java” (something that apparently everyone is looking for – many in ruby, some in erlang, haskel, etc).

Keep watch – there is interesting stuff out there!

-Chris

You can leave a response, or trackback from your own site.

Appdomain isolated WPF Plugins!!

Having been working on plugin based winforms based apps – and desiring appdomain plugin isolation for some time… just the possibility makes me shed a tear of joy!

 

You can leave a response, or trackback from your own site.

Some pictures here. (Picasa has a cool “export album and upload to ftp” feature - useful.)

You can get a good idea of where we were based on google maps here. The map is subtley wrong if you zoom in. Basically we were on the inside of a mini-harbor - maybe 150 meters in from the atlantic – lovely as can be. Excerpts . . .

You can leave a response, or trackback from your own site.

Continuing thoughts from yesterdays Thoughts from Maine – user experience, ruby, python and more . . .

Another bit from Coopers writing is that idioms are more powerful than metaphors when it comes to user experience. Metaphors usually go too far – and wind up being too much a stretch. They are also inflexible inasmuch as you can never add something totally novel to that metaphor in software if the real thing does not behave that way.

A big part of rails, and I would even say the rubyist community feel is the idiom theme – (ala rails convention over configuration). Just look at what Google has to say on Ruby Idioms.

My insight here is simply that ruby is good user experience for programmers. Based on several “Cooper-isms” – idioms over metaphors, little excise to get in your way, things like metaprogramming seem to be goal oriented inasmuch as they are about doing what a programmer needs to do – and taking away the grunt work…

But what about my real projects!!!

I will say that I do not seem to be the primary persona they developed ruby for… I LOVE the language and think it is empowering. I am aslo a tester – I believe in and practice TDD – so the dynamic language thing works for me. That being said – there is literally no way for me to build trader desktop applications with ruby, real time messaging, true multi-threading, GUI polish – high speed grid views etc… Perhaps someday…

JRuby 

I am thinking about a few JRuby things I could do that would be valueable – replacing spring configs with ruby – it will be shorter. Replacing other XML based stuff with ruby seems the easiest win and place to start. When people see that programming in ruby is better than XML – it will be easy to convert them…

Dependency Injection in Ruby (and other dynamic languages)

… This is totally not related – except inasmuch as I care about ruby and DI….

There is an interesting meme going around the web… Jim Weirich issued a challenge to describe dependency injection in once sentence. Here are some good ones:

How about: “Dependency Injection” seemed an amazing insight to people who had finally learned what constructor arguments were for.  JimWeirich  

Dependency Injection enables a vitally important but nevertheless weak, limited, syntactically confounding, and dauntingly complex form of one of the kinds of meta-programming that should exist in the language. (from here)

Dependency injection is a palliative for environments that unnecessarily couple creation, lookup, and interaction between collaborators. (from here)

[DI isn't needed] primarily because the entire Ruby object space is one big DI container, and you inject dependencies by taking advantage of it. from here