Trading bot construction (IB)

walterjennings: yes, faster is better -- in my opinion.

Anyway, here's what I do to run the out-of-the-box API:

start the TWS papertrading account
configure->api (check "Enable ActiveX and Socket Clients")
java -jar jtsclient.jar

A GUI labeled "Sample" should appear. It has three text windows and a lot of buttons on its right side.
Press the "Connect" button, then a dialog box labeled "Connect" will pop up. Press its "OK" button (the IP address doesn't need to change if you're running the API on the same box that TWS is running on). If that succeeded, you'll see some messages in the lower two text boxes of "Sample."
In the middle box, the TWS server version and next valid order id will appear. In the lowest box, some info about data farm connectivity should appear.

Next, to get some market data, hit the "Req Mkt Data" button. A form pops up and can be filled out with this info:

Symbol: ES
Security Type: FUT
Exchange: GLOBEX
Primary Exchange: GLOBEX
Local Symbol: ESH7

Leave the other fields alone. Hit "OK"
You should then see some messages in the upper text window of "Sample," showing things like "lastSize," "volume," "askPrice," etc.
If you do this during after hours when the data comes slowly, you can see that changes in an ES ticker on the TWS window appear as text messages in the "Sample" window. It is interesting that if the last volume was, say, 5852, then just one transaction, that there are two lastSize messages of 1, followed by a volume message of 5853.

I found the info to plug into the market data request form by rooting through some of my log files -- they have names log.Mon.txt. Another way to get the contract details could be to right click on a TWS ticker and select "contract details."

Now, try hitting "Disconnect."
A pop-up indicating that an exception occurred appears! Hit its "OK" button, then a "Connection Closed" pop-up appears. Hit its "OK" button, then another "Connection Closed" pop-up appears (there must have been two "connections"). Hit its "OK" button. Hit the "Close" button.

Next, I'll go through using the out-of-the-box API to enter and exit a position in ES. I'll also begin looking at the Java code to find out what pressing the "Req Mkt Data" button causes to happen. Another interesting thing to find out is where are the price and volume events being processed. It is when those events arrive that a bot has work to do.
 
A key question is: how many random trades do you need, in order to generate a "high confidence estimate" of the profitability of random trading? I suspect most people would agree that
  • One random trade is too few
  • Ten billion random trades is more than enough
The right answer is somewhere in between. But where?

Suppose you decide that a number "N" of random trades, is more than enough to generate a high confidence estimate of the profitability of random trading. I suggest that you explicitly test whether N is, or is not, enough. One simple way to do it is the following
  1. Generate N random trades
  2. Estimate the profitability of random trading from those N random trades
  3. Write down your estimate
  4. Generate another N random trades
  5. Estimate the profitability of random trading from this second set of N random trades, and write it down.
  6. repeat steps 4-5 ten times, so you have written down ten estimates of the profitability of random trading.
Now the key question: are all ten estimates, equal to each other? If not then you have proven that N random trades are insufficient to give a repeatable, high confidence estimate. Repeat using a larger value of N.
 
MGJ: Suppose the ten estimates are:

0 1 1 1 0 0 0 1 0 1

where a '0' represents N trades that were not profitable and a '1' represents N trades that were profitable. All ten estimates aren't equal: some are '0', some are '1'. Is that the right way to consider the equality of estimates?

Speaking of randomness, it isn't hard to get a machine to flip a coin in order to decide whether to buy or sell, but how could you do that at a random time? No Idea. So, I googled "random time" and eventually came across some SQL code that arranged to do something at a random time. The idea is to realize that a day has 24 hours, an hour has 60 minutes and a minute has 60 seconds, so that time runs from 00:00:00 to 23:59:59. To find a random time all that is necessary is to have a random number generator that returns values between 0 and 1, inclusive. Multiply 23 by a value returned by the generator to obtain a random hour. Do the same for 59 to obtain a random minute, then the same for a random second. Then, of course, the random time has to be constrained against exchange hours -- I'd be inclined to just repeat the process until I got a time that occurred during trading hours.
 
I think the modern computer will only give you comupterised randomness, this is because I heard that in the late 80s the Casio calculator were using a square root method to get the random number:

They would choose a number, and keep square rooting it take 2 digit from the decimal place. I am not clear how they will refresh this data, but in long term (as they refresh the number) a pattern can be observed.

For instance, some of the internet casino use algorithm that repeat itself every 3.6 million. It is okay for a retail customer, but it was know that some computer geek spotted it and make $$ out of it.

I think as random number is rule base, it will be close to impossible to generate true random number, although numbers that are “close” to random can be done I am sure.
 
The RAND function in earlier versions of Excel used a pseudo-random number generation algorithm whose performance on standard tests of randomness was not sufficient. Although this is likely to affect only those users who have to make a large number of calls to RAND, such as a million or more, and not to be a concern for almost every user, the pseudo-random number generation algorithm that is described here was first implemented for Excel 2003. It passes the same battery of standard tests.

The battery of tests is named Diehard (see note 1). The algorithm that is implemented in Excel 2003 was developed by B.A. Wichman and I.D. Hill (see note 2 and note 3). This random number generator is also used in the RAT-STATS software package that is provided by the Office of the Inspector General, U.S. Department of Health and Human Services. It has been shown by Rotz et al (see note 4) to pass the DIEHARD tests and additional tests developed by the National Institute of Standards and Technology (NIST, formerly National Bureau of Standards).
Back to the top Back to the top
Notes
• The tests were developed by Professor George Marsaglia, Department of Statistics, Florida State University and are available at the following Web site:
http://www.csis.hku.hk/~diehard (http://www.csis.hku.hk/~diehard)
• Wichman, B.A. and I.D. Hill, Algorithm AS 183: An Efficient and Portable Pseudo-Random Number Generator, Applied Statistics, 31, 188-190, 1982.
• Wichman, B.A. and I.D. Hill, Building a Random-Number Generator, BYTE, pp. 127-128, March 1987.
• Rotz, W. and E. Falk, D. Wood, and J. Mulrow, A Comparison of Random Number Generators Used in Business, presented at Joint Statistical Meetings, Atlanta, GA, 2001.
 
Dazuni and kiwi_trader: those are good points about random number generators. Some of them generate the same sequence of numbers, over and over.
It is something that will have to be considered.
 
Random entries and an equal points of profit-taking, stop-losses....
Sorry, I don't see the "point" ?
Isn't this like flipping a coin ?
 
syswizard: what I hope for is a trading record for a random bot that I can compare the record of a smart bot, or even my manual trading, against. I wonder whether my trading is no better than random trading with a little luck.
 
Quote from doli:

Suppose the ten estimates are:

0 1 1 1 0 0 0 1 0 1

where a '0' represents N trades that were not profitable and a '1' represents N trades that were profitable. All ten estimates aren't equal: some are '0', some are '1'. Is that the right way to consider the equality of estimates?
More...
No, the right way to do it is to calculate ten floating point numbers which represent the average (reward/risk) ratios of the ten random trading experiments. Now compare the magnitudes of these floating point numbers.

A crude but effective rule of thumb is that the error tolerance of a Monte Carlo experiment such as this one, is ROUGHLY (10 / sqrt(N)). If you use 10,000 random trades, the result will have an error tolerance of ROUGHLY 0.1 (ten percent). If you want to have an error tolerance of ROUGHLY 1% (0.01) you'll need N = 1 million.

But don't take my word for it; run the experiment and look at the data.

If you're looking for software random number generators that have passed all the tests known to man, try these search terms
  • L'Ecuyer AND portable
  • Mersenne AND twister
  • Park AND Miller AND "minimal standard"
  • ran1 AND "Numerical Recipes" AND "source code"
 
Basically the OP has a good idea regarding the random trades. I never quite saw the value of that in all the time I've been system testing but to use those results to calibrate a system... kudos.

Why anybody wants to develope their own trading bot however is beyond me. I can have a random entry system to test exits up and running with Tradestation trading my IB simulated account in 15 minutes. There are half a dozen other charting packages that will do the same thing as well.
 
You must log in or register to reply here.
Back
Top