2012年4月23日星期一

trading-shim.com, LLC, Columbus, OH

http://ocaml.janestreet.com/?q=node/61

Caml Trading talk at CMU

I was at CMU several weeks ago, and gave a version of my "Caml Trading" talk there. See below if you are interested in seeing the video. It's a reasonably good source if you're interested in understanding more about how and why Jane Street uses OCaml.

Caml Trading

Comments

Quoting for OCamlCore.com

Is it possible to use your different arguments (against OO and F#) on my own website ?
Thanks in advance Sylvain Le Gall
(website: www.ocamlcore.com)

Quoting

Do you mean you'd like to quote something I said? I don't have any objection to that...

Excellent talk

Hi,
Thanks for putting this talk here.
It is very interesting and I know I'll now have an excellent link to give to people with a bad opinion of OCaml !

Quoting

No direct quote, but use your idea about :
  • The three main ideas in Object Oriented programming:
    • interface: good idea,
    • polymorphism: good idea but OCaml parametric polymorphism is a better implementation
    • inheritance: wrong idea because you need to read the code inherited...
  • F# is good but its GC is not made with FP in mind, so it can't handle the allocation rate of FP and calling .NET method just raise the scary "NULL" pointer exception again
  • Paying a lot of people to read a code full of "boilerplate" is not a good idea. OCaml allow to have a very small codebase which is more easy to read than more mainstream language
  • OCaml is good for:
    • Brevity
    • Pattern matching
    • Refactoring (with pattern matching in mind)
(I am not a native english speaker and just listen to your talk 1 time, so maybe I have misunderstood some points)
So this is not about quoting like "OO is ... " as Y. Minsky from Jane Street Capital said. I just want to take your ideas, write some web pages and thank you in another web pages for giving me ideas about these points.
Do you still agree ?

Quoting

No objection. These ideas weren't really invented by me in any case, merely collected. A couple of corrections, though.
First, I think this is what you were trying to say, but to be clear, my point about subtyping is that it is the wrong default form of polymorphism, and that the right default (not implementation) is parametric polymorphism.
Second, while you've correctly pointed out some of my worries about F#, the language also has a great deal to recommend it. I don't think we'll be switching over all of our code anytime soon, but I do think it's a lovely language, and may be the way in which the Hindley-Milner type system hits the big time...

Very nice talk

Thanks for publishing it here. I got a real enjoyment from hearing many of my own thoughts in your speech :-)

Great seeing OCaml being used in such a large company

I am used to seeing OCaml in research facilities, but it was great to hear why Jane Street has chosen to go with OCaml. I used to program in VB when I worked for banks/telcos as a programmer and so have stuck with .Net for my flights site, but it would be great to rewrite it in OCaml & get all that static-typing goodness.

Monitoring software

You mentioned that it's very important for your code to be correct so it doesn't cause you to lose money fast. Why don't you create software that monitors the effectiveness of your trading algorithms and shuts things down if you seem to be losing a lot of money?

tiger, Isn't that basically

tiger, Isn't that basically equivalent to solving the halting problem? If your code on how to trade things is incorrect, isn't the code to monitor how you are trading things going to be incorrect as well?

Further Reading?

Is there any suggested reading for some of the points Yaron made about OCaml's strengths? Specifically, he mentioned that in Java it is hard to know what type you are working with given inheritance. But it seems like OCaml would have the same problem if you consider polymorphic variants and OCaml's object system. Does Jane St not use these two tools?

OCaml vs Haskell

Firstly I greatly admire your conviction for basing your business on a functional language and I can fully understand your reasons for choosing OCaml over traditional imperative languages.
As a Scheme programmer myself working on AI solutions for trading I have been looking at more performant alternatives to Scheme and have gravitated towards Haskell rather than OCaml because of its support parallel processing and marginally better performance than OCaml on the Language Shootout.
Did you evaluate OCaml against Haskell and what were your reasons for going with OCaml ?
Regards
Andrew

Credit where it's due

As a long time admirer of ocaml, stuck in a job with limited (but thankfully expanding) opportunities to code solutions in my favoured language, I want to thank you for publishing this video for the following two reasons.
  1. Being the only functional programmer in my workplace, it is hard to win over traditional OOPists ( even after providing ocaml solutions such as parsers and on-the-fly code generators ) as to the long-term benefits of using ocaml.
  2. The sheer joy of listening to someone describe a subject with an engaging combination of wit, intelligence, energy and clarity.
Very well done.

Poor example for ADTs

Hi,
I think that the example for ADTs is rather poor, since this kind of thing can be done just as well in OOP languages. For example, in Java you'd write something along the lines of

interface Instruction {
    int getId();
}
class Order implements Instruction {
    int id;
    public int getId() {
        return id;
    }
}
class Cancel implements Instruction {
    int xid;
    public int getId() {
        return xid;
    }
}
class Stuff {
    static List<Instruction> filter_by_oid(List<Instruction> l, int oid) {
        List<Instruction> new_list = new LinkedList<Instruction>();
        for (Instruction i: l)
            if (i.getId() == oid)
                new_list.add(i);
        return l;
    }
}

This is certainly uglier than the OCaml version, but it's not because Java doesn't have ADTs. It's ugly essentially because all the other FP stuff like higher order functions, closures etc. is missing. Note that I'm not disputing the superiority of functional languages, I just think that you chose a bad example to prove your point that ADTs help writing less buggy code.

examples

It's hard to convey what's going on in such a short example, but there really is something wrong with the Java version above. The issue is that you have to make a choice in getId as to what ID to return. For the cancel, should you include the identifier for the cancel message, or the identifier for the order to which the cancel is referring? There are really two valid choices, and you may need to make the choice differently in different contexts. By using a variant, you get to make the decision differently in each context. By doing this with object-style subtyping, you have to make the decision in the "Stuff" interface. For a library which is used in many different contexts, this means that you end up having to stuff all sorts of usage-specific details into the library, which is unnatural.
For a tiny example like this, it's not a big deal either way. But as you scale up to real examples, it becomes clearer what you get from using algebraic data types.
For what it's worth, this is connected to the so-called "expression problem" which Phil Wadler has written on.

User-Interfaces

What are your feelings about using web-based user-interfaces that are written in OCaml in lieu of a desktop application?

Web-based UIs

We feel pretty good about that, and that's how we solve some of our UI problems. Honestly, though, it's an area that we're not great at. Our web UIs tend to look pretty ugly. That said, it's a great way to deploy an app with a minimum of configuration nonsense.

High Throughput Computing?

Are you using OCaml with something like Condor on your clusters or did you roll your own?

a worthwhile hour

I have been tracking Jane Street ever since late 2006 - pondering an ad here in Seattle's craigslist. I liked the stripped down, almost spartan function call it created to attract great coders. Now, several years later, I see what that was all about.
I am interested to see how OCaml synergizes with the way I think. I like the balance points stated, and I really appreciated the perspective shared here.


http://stackoverflow.com/questions/1996432/what-programming-languages-is-algorithmic-trading-software-written-in


What programming language(s) is algorithmic trading software written in?

up vote 11 down vote favorite
8
Anyone know what programming language(s) is algorithmic trading software mostly written in? Also known as automated trading, algo trading, black-box trading or robo trading.
If I wanted to write the above software where would I start? Any tips/trick/advice greatly appreciated.
Thank you in advance ;-)
link|flag

68% accept rate
1
What are some examples of algorithmic trading software? – Thomas Matthews Jan 3 at 21:43
1
Probably the same language(s) used to run offshore gambling websites. – benzado Jan 3 at 21:44
4
The following IBs predominantly use C++ for client-side and prop algo trading infrastructures: Credite Suisse, Goldman Sachs, Deutsche Bank, UBS, RBS, Barclays and BNP Paribas – Beh Tou Cheh Jan 3 at 22:01
1
+1 for teaching me something new. I had never heard about algorithmic trading softwareNifle Jan 3 at 22:16
Thomas, Nifle: Try Wikipedia on Algorithmic Trading at en.wikipedia.org/wiki/Algorithmic_tradingDirk Eddelbuettel Jan 4 at 2:26

12 Answers

up vote 12 down vote accepted
I'm working on the same thing right now (FOREX), and I'm using Python.
C++ is needed only for really fast strategies (mili/microsecond level) or for huge amount of data (think arbitraging the S&P 500 index versus it's 500 component stocks, BTW, another microsecond level job)
You can use pretty much what you fancy if you won't trade less than a minute apart. It also depends on the API of the broker you use. Some offer FIX (socket programming), others Windows COM APIs, other Java APIs.
To answer your question, most use C++. Here's a job offer of the kind
link|flag
Just out of interest, which API are you working against for order execution? Forex.com? – grm Aug 18 at 13:32
The Order2Go API offered by dbfx.com – Adal Aug 18 at 14:06
up vote 14 down vote
JaneStreet uses OCaml. Here's a tech talk about why they chose a functional programming language to implement their trading software:
http://ocaml.janestreet.com/?q=node/61
link|flag
Thanks for the video link. I was aware of Yaron's paper "Caml trading - experiences with functional programming on Wall Street" at janestreetcapital.com/minsky%5Fweeks-jfp%5F18.pdf, but not this talk. – Don Wakefield Jan 4 at 0:27
up vote 7 down vote
You are not defining your terms well.
Automated trading (or black-box trading) can be written in anything, provided your trade horizon is long enough and your latency requirements are not stringent. That's where the stuff from the late-night commercials comes in and you get Windows applications with their own scripting languages etc. Some people do this in spreadsheets on daily closing prices or coarse-enough 'bars' of data, and daily trade frequency. However, at higher frequencies and/or model sophistication, the door opens for Python, Matlab, R, ... as well as compiled languages.
High-frequency trading is a different matter as trade horizons are much shorter and latency requirements can be critical. In this domain, the language of choice is C++ (as you can confirm by perusing job ads) with the odd sprinkling of Java or C#, as well as outliers as OCaml used by Jane Street.
link|flag
up vote 5 down vote
I work in a the field, so here is my knowledge about US companies:
Quite a few algorithmic hedge funds are C++ and Linux centric. Examples include Tower Research Capital, Hudson River, Knight, etc. They typically have their infrastructure done in-house, and benefit from C++ speed. C++ is generally more common in investment banks as well. Bloomberg is also C++ based though they don't do their own trading.
However, some serious players are actually in the Java world: D.E. Shaw is the most notable and probably largest. Two Sigma investments are also major players in Java, and then there are a lot of small players.
I'm less familiar with the Chicago and Austin markets (other algo powerhouses) but it still seems to be primarily C++ and Java.
I know that there is at least one firm in NYC that does only OCAML (Jane Street?), and they hire lots of Ph.Ds. who tend to come from a PL/functional background. I have heard stories of .NET shops but they're less common, likely because of licensing costs - Linux is more common in this domain because you can ramp up a lot of firepower quickly.
Finally, quite a few smaller houses buy access to APIs to do algorithms. The company I work for, for instance, provides a trading platform and a Java based API that one can use to implement specific algorithms. A lot of the complexities of programming are hidden so the quants can focus on the algo side.
I would seriously advise against writing your own trading platform. The market is saturated, and you usually have to hand optimize for years to get good performance. If you have an idea for a clever algorithm, you may be better off licensing a trading platform or joining an actual fund.
link|flag
up vote 4 down vote
Most of what I know is written in C++, less in Java, and some bits in C# and .NET ASP
link|flag
up vote 4 down vote
It depends on what API your brokerage provides. The one I use for this sort of thing is Interactive Brokers, which provides APIs in DDE for Excel, Java, C++, and ActiveX. When I first started developing my ATS, there were some eccentricities to their C++ API, so I'm using the Java interface. It looks like the C++ API has improved since, but I've already got a large body of working code. The APIs may provide different features for individuals versus institutions. FIX interfaces are an industry standard, but it may be difficult to get direct access as an individual. Depending on which broker you select, YMMV.
link|flag
3
If you're serious about latency and are fortunate enough to have direct exchange connectivity, then you probably want to use whatever 'native' protocol the exchange may have as it's likely to be faster than FIX. TSE had something called chumon before, not sure what's used today. – ehnmark Jan 3 at 22:53
up vote 3 down vote
Just adding my two cents: the company I work at uses primarily .NET (C# and--believe it or not--VB.NET). As others have pointed out, you're probably not going to find a lot of managed languages like Java or anything in .NET for high-frequency trading (e.g., tens or hundreds of trades per second), but for algorithmic trading in general, a managed language can be a smart choice for the faster development speed. We are adding and changing functionality on a constant basis and would not be able to do so nearly as rapidly working in a language like C or C++.
The biggest issue with a managed language in this context is not garbage collection per se, but specifically garbage collection that occurs at a time-critical moment such as when a high volume of trades are being executed. Since the CLR handles this by itself, the developer has little control over such situations, which is fine (even desirable) in a typical business application but terrible in a real-time trading environment.
The standard strategy that I'm aware of (and that we use) to minimize this potentially catastrophic scenario (a quote lagged by 50ms could be bad; one lagged by 1s could be devastating) is to use resource pooling and recycle the same objects over and over in favor of creating new ones. The less garbage you create, the less there is to collect.
Besides that, constant performance profiling is obviously a must. A lot of the code in our codebase looks pretty ugly because of all the performance optimizations we've made (and continue to make). That's just the way it is, unfortunately, when you're competing with other traders to get to the market a few microseconds sooner.
link|flag
up vote 2 down vote
I've come across autotrading software written in languages as diverse as VB6 and Java (hmm, maybe not that diverse). The stuff that actually talks to the exchanges to do the trades always seems to be written in C++ though.
link|flag
up vote 2 down vote
Depends, these days a 4th gen language like Java or C# for normal e-commerce (other such languages will also function -- e.g., Erlang or Python); however, there is a real-time aspect to the --hard-core -- trading side.... such systems use expensive -- non-standard -- hardware to eliminate latency and naturally software is written in C++ or C. every ms counts when you want to out-do others competing with you.
link|flag
3
The real killer is garbage collection. – ehnmark Jan 3 at 23:00
Foh shizzle; there are other things which behave in a non-deterministic way as well -- e.g., user-space green thread schedulers (Erlang), fully interpreted execution (python), or multi-pass optimized JIT (Java). – Hassan Syed Jan 3 at 23:15
Java and C# are not 4th generation languages. – P-Nuts Jan 3 at 23:55
2
It really depends on what you consider hardcore and high performance. These days the space for ultra low latency (microsecond range) is often migrated to silicon. If you're above silicon and do some intelligent things (pinned and efficient memory) you can certainly get micro and nano second processing on algo models. – Ajaxx Jan 7 at 20:44
up vote 0 down vote
Some systems, e.g. StreamBase, let you define your trading algorithms in a proprietary language (which may be a visual language or something declarative instead of a common programming language).
Engines of this type can be created using anything from Java (to run on any server) to machine language (to run on specialized hardware).
link|flag
up vote 0 down vote
To be very honest: C, C++, OCaml, Perl, and FORTRAN. Those languages tend to dominate numeric things such as financials. I'm not saying they're better languages or that newer stuff hasn't come along but many companies are loath to pay for "upgrades."
link|flag
7
COBOL? No chance. This is about algorithmic trading software (a relatively recent invention), not about some archaic accounting software. – Jason Jan 3 at 22:22
Fair enough. I'll remove the COBOL seeing as you've got 5 upvotes which indicates to me that no one here considers the stuff outside of "buy this item, sell that" counts. – wheaties Jan 4 at 0:06
up vote 0 down vote
We have run the Trading Shim project (link below) for several years, which is designed to provide the connector between a Java based, FIX translation and account management gateway, called the TWS, which connects to the upstream exchanges, account detail, and data farms of the broker: Interactive Brokers; and on the downstream toward the trader's strategy and management clients. It exposes a simple text command interface on its input, and results datastreams in several formats (syslog, logfile, standard out)
The shim is written in C++, and is released under a GPL3+ license. The testing harness (which simulates a client) is written variously in shell, Ruby, Python, and basically any language which can read from standard in, and write to standard out. So ... any language.
I collect a linkfarm to several such projects and products, note their implementation lamguage, and the licenses under which they are released here





http://www.trading-shim.org/faq/?other-voices








trading-shim Frequently Asked QuestionsCertain recurring questions tend to come up in mailing list and support contexts; the links below address or point to further resources about the most common areas of inquiry.
Show Categories








Other voices - connection to the TWS

The Jump links are: here
There are voices other than ours working on source available interfaces to connect to the TWS through the socket inteface. We collect some here.
Language (and License) Website or URL Developer
C++ (GPL) Trading shim Devels
mailing list
C++ (unk) Lightweight TWSAPI C++ library wrapper
(then go to Files -> C++ Code)
Jan Boonen
C (BSD) C language API for TWS Slavcho Nikolov
Java (BSD variant) HSQLDB
Java SQL relational database engine
Thomas Mueller, et al.
[ used in TWS ]
Java IBdemo
(Alternate location)
Vic Szmyd
Java (LGPL) IBTrader Gabor Liptak
Java (LGPL) JDOM
light weight Java API to manipulate XML
Jason Hunter, et al.
[ used in TWS ]
Java (LGPL) JFreeChart David Gilbert, et al.
[ used in TWS ]
Java (new BSD) JSystemTrader Florent Guiliani, et al.
Java (GPL)
Matlab connector
CCAPI
Patton code (BSD) and CCAPI-Matlab connector
ActiveStocks.EU, Rene Nederhand
Java (LGPL) Mondrian
Java OLAP server
Julian Hyde, et al.
[ used in TWS ]
perl
('same terms as Perl itself')
perl-Finance-InteractiveBrokers-TWS Jay Strauss
Python (BSD) IBPy - and -
ProfitPy
Troy Melhasemailing list
R (GPL) ib notes Vincent Andres
Java (LGPL) ROME
Java tools for managing RSS and Atom feeds
Alejandro Abdelnur, et al.
[ used in TWS ]
Ruby (GPL) IB-Ruby Paul Legato
N/A Yahoo forum mailing list
N/A Chuck Caplan wiki wiki

Note: We strive to get license information correct; please send a email report if you note a possible error to: herrold@trading-shim.org citing any questioned matter.







Available Source Efforts - Libraries, Visualization and Trading Platforms - Platform neutral

These platforms either explicitly support indicator computation, visualization, or trading through IB and the TWS, or appear well suited to such an effort.
C++ (BSD) TA Lib (library) Devels
C++ (BSD) QuantLib (library)
hooks to a spreadsheet
Devels
Java JQuantLib
C and others (freeware) gnuplot Contributors
C++ (GPL v2) octave Contributors
C and others (GPL) R Contributors
C and others (GPL) R-SIG-Finance Contributors
C++ (GPL) R Server Simon Urbanek
R (GPLv3) quantmod Jeffrey A. Ryan
R (GPLv3) TTR: Technical Trading Rules Josh Ulrich
N/A (Protocol) FIX Algorithmic Schema Working Group
C++ (BSD like) QuickFix Developer group
Java (BSD like) QuickFix/J Developer group
Java (GPL) Continuous Trade
(Possible fork of Merchant of Venice)
Jordi Pujol i Palomer & Xavier Diumé i Delip
Java (Eclipse Public License) Eclipse Trader Developer group
perl (GPL) Genius trader
(local)
Raphaël Hertzog & Fabien Fulhaber
C++ [Web UI] (GPL)
(uses TA Lib)
AST Michael Williamson
Java (Common Public License) Eclipse Trader Marco Maccaferri
Java (BSD) JSystemTrader anonymous webpage presently
Java, Ruby (GPL) Marketcetera
(with
C++ and Fix hooks; CLA, MySQL CLA<>)
Devels - toli, gmiller
C++ (BSD) TREE - data connector and store Structured Software Systems
at SourceForge
Devels - georgev13
Java (GPL) Merchant of Venice
Based on
Joone
Andrew Leppard, Daniel Makovec
C++ (GPL) Qtstalker S Stratos
Python (GPL) Sage many
Java (GPL) truetrade 'tyrotrade'
Java (GPLv2) ActiveQuant Devels
Apache 2.0 (BSDish) ActiveMQ Devels
GPLv3+ or LGPL Zero MQ Devels
Apache 2.0 (BSDish) Qpid Devels





Connection to the TWS - Commercial and Non-available Source Efforts - Platform neutral


Language Website Developer
Delphi Delphi / BCB / Kylix TIABSocket Ross Hemingway
Excel INDEXFUTUROS IndexFuturos Engineering (Madrid)
Java Eclipse Trader - and - (second site) Eclipse Trader is an Eclipse Rich Client Platform (RCP) application
Java JSystemTrader Eugene 'nonlinear'
Java jTWScharts - Charting
jTWSdump - Downloader
'Orionn'
Matlab Matlab trader - also tick, history, earnings anonymous



Commercial and Non-available Source Efforts - Platform limited


Language Website Developer
C# TradeBuild Richard King
Smalltalk Alchemetrics Alchemetrics Trading Research (mentioned)
unknown Trade-Commander anonymous
unknown MetaQuotes Language reference MetaQuotes
Unknown SSChart Simian Savants
seemingly C++, Java and FIX SmartQuant documentation SmartQuant - Anton Fokin, acquired by QuantHouse
Unknown Futures trader - simulator RTS Trading
Unknown TSim plus - simulator Henry Eldridge-Doyle



Tools we use


Language Website Developer
n/a SEC Info -- EDGAR filings, on a 'push' basis n/a


Jump Links:
[
connection to the TWS | Available Source Efforts - Libraries, Visualization and Trading Platforms - Platform neutral | Connection to the TWS - Commercial and Non-available Source Efforts - Platform neutral | Commercial and Non-available Source Efforts - Platform limited Tools we use ] Last modified: Tue, 30 Dec 2008 18:03:39 -0500



[ Home | Search | Interior documentation | Program documentation | FAQ | Download | PDFs | Screen shots ] [ Contact Us | Site Map | Bugzilla | Mailman | Mailing List Archives: (Main) | License | About | Press | Copyright ]
Copyright (c) 2006 ... 2009 trading-shim.com, LLC, Columbus, OH

没有评论:

发表评论