Need some help with Automated Trading
- Thread starter bjkoehler
- Start date
You might find this link useful
http://www.ta-lib.org
Free library of a lot of TA stuff including MACD etc etc. Source code in C++ and Perl etc.
If you are using the IB demo account you might like to consider Java. Easier to program than C++. Free IDE's such as Netbeans and Eclipse and extremely well documented.
Be warned that the IB demo account is a pretty poor simulation of the real market and some of the API functions don't fully work. It is good enough though, to produce a working system (of sorts).
http://www.ta-lib.org
Free library of a lot of TA stuff including MACD etc etc. Source code in C++ and Perl etc.
If you are using the IB demo account you might like to consider Java. Easier to program than C++. Free IDE's such as Netbeans and Eclipse and extremely well documented.
Be warned that the IB demo account is a pretty poor simulation of the real market and some of the API functions don't fully work. It is good enough though, to produce a working system (of sorts).
The IB demo account is probably your best no cost option. You can test against it and run a system against it, but the results you get in terms of profitability will not be much like how the system would perform in the real market.
If the point of the exercise to develop example real time software handling times series data the IB demo account will probably suffice.
IB are running a contest for students to develop an automated trading system. Have a look on their web site. You might be able to get something better than the publicly available demo account through this avenue.
cmk,
You have one ahead on many others. You at least have an idea of where you stand right now.
Need a little kick?
work, WORK, WOOOOOOOOORK
(I'm serious)
I'm working on an application using IB's API right now, though in Java not VB. Basically I'm doing it in small steps.
My first application did not enter orders; it simply is using IB's datafeed to obtain market data. I actually insert the raw data into a Postgres database.
The next step is to have a similar application, except it keeps track of the data internally (instead of logging it to a database), and for it to use the information to make trading decisions and print those decisions ("BUY LIMIT 500.00 10:15:00") and associated exit orders to a file and hand-compare to make sure it is doing the strategy you want it to do correctly, at the right time.
The next step is to figure out how to actually place the orders, instead of print them to a file/screen, using the API. This part actually wasn't as difficult as I thought. But you do have to manage the orders (ie keep track of which orders need to be cancelled, etc) and all that. Then run it against the test system (which has bogus data btw).
If that is looking good, then you can run it live in a limited (say 1 order only, highly monitored) context. I was at this phase a few weeks ago but ran into a problem btw, I had an error in my exit orders (I forgot to set the "auxiliary" price field, I was just using the Limit price, I believe). Anyhow when I ran it live, it submitted my actual entry correctly, but since I had a minor error on my stop loss, it submitted it.. but in Pending mode which I wasn't aware of until the price went through it. The market happened to be unusually volatile just at that time, and it took me a minute or so to figure this all out and close the position manually. So I lost about 3 times my stop loss on that. Heh. But no big deal, that is why you test live with just 1 contract to iron out these issues until things are stable.
There are other things to consider too:
1) if your strategy is simple, do you want to put in some decoys to fool anyone who gains unauthorized access to your trading history who tries to reverse engineer it
2) You have to handle partial fills, etc
3) If you use limits for stops (like me), you need to do a check to make sure they actually get executed just in case news causes the bid/ask spread to widen and skip your stop limit, and then you need to cancel your stop and enter a market order to close the position. (Obviously if you use market orders for stops this isn't an issue).
4) You need systems monitoring tools as well, just for routine things like getting manually involved if a bad tick triggers one of your orders. Also for black swan events.
So basically it is a pain.
When it works it is a beautiful thing though and has a number of advantages.
-Taric
My first application did not enter orders; it simply is using IB's datafeed to obtain market data. I actually insert the raw data into a Postgres database.
The next step is to have a similar application, except it keeps track of the data internally (instead of logging it to a database), and for it to use the information to make trading decisions and print those decisions ("BUY LIMIT 500.00 10:15:00") and associated exit orders to a file and hand-compare to make sure it is doing the strategy you want it to do correctly, at the right time.
The next step is to figure out how to actually place the orders, instead of print them to a file/screen, using the API. This part actually wasn't as difficult as I thought. But you do have to manage the orders (ie keep track of which orders need to be cancelled, etc) and all that. Then run it against the test system (which has bogus data btw).
If that is looking good, then you can run it live in a limited (say 1 order only, highly monitored) context. I was at this phase a few weeks ago but ran into a problem btw, I had an error in my exit orders (I forgot to set the "auxiliary" price field, I was just using the Limit price, I believe). Anyhow when I ran it live, it submitted my actual entry correctly, but since I had a minor error on my stop loss, it submitted it.. but in Pending mode which I wasn't aware of until the price went through it. The market happened to be unusually volatile just at that time, and it took me a minute or so to figure this all out and close the position manually. So I lost about 3 times my stop loss on that. Heh. But no big deal, that is why you test live with just 1 contract to iron out these issues until things are stable.
There are other things to consider too:
1) if your strategy is simple, do you want to put in some decoys to fool anyone who gains unauthorized access to your trading history who tries to reverse engineer it
2) You have to handle partial fills, etc
3) If you use limits for stops (like me), you need to do a check to make sure they actually get executed just in case news causes the bid/ask spread to widen and skip your stop limit, and then you need to cancel your stop and enter a market order to close the position. (Obviously if you use market orders for stops this isn't an issue).
4) You need systems monitoring tools as well, just for routine things like getting manually involved if a bad tick triggers one of your orders. Also for black swan events.
So basically it is a pain.
When it works it is a beautiful thing though and has a number of advantages. -Taric
If you're a beginner, I don't think it makes sense to use anything other than Visual Studio, especially if you plan to stay in the MS environment. Also keep in mind that retail brokerages/datafeed providers are Windows-centric. Some only offer legacy class libraries, as they move toward the .NET framework.Quote from bjkoehler:
I can actually get VS Pro for free, since im an engineering student, through my school.
So you would recommend using MVC++ over using gcc/wxWidgets?
It's fine to get into the open source stuff and develop cross-platform applications and get into Linux, Python and so on, but this stuff requires a learning curve.