In the last post I may have given the impression that RandomBotMgr computes the trade times, then hands them off to RandomBot for scheduling. What happens is that RandomBotMgr decides if the exchange is open and, if so, connects to TWS, creates a RandomBot, providing it with the 'open', which is "now," and 'close' times. RandomBot then computes an entry and exit time, constrained by the 'open' and 'close' times, then schedules the trades. But if RandomBotMgr were to find each pair of times to trade, and if it then ran a RandomBot thread to handle the entry order, then ran a RandomBot thread to handle the exit order, RandomBotMgr might be in a better position to manage the trades. There is a lot to be considered about the relationship between RandomBot and RandomBotMgr. by the way, RandomBot is essentially what is in randTime.java's 'Bot' class, so it is finding the entry and exit times for each random trade (round-trip).
By monday, I hope to put the new files up. It needs a lot of work, but I have found it useful. It does random-trading and does logging, so I could begin running it each trading day, but won't start doing that until the log format is settled. As is, it is very useful for finding out about bot <-> TWS interaction. If I get "lucky," I may see logged messages about disconnects/reconnects in the log. It can also trade in two modes: connected-to-tws and disconnected-from-tws; the disconnected mode is useful for checking out the random time generator without TWS. Before I put it up, I'll need to go through it and note where there is a known bug and where there may be a possible bug. I also want RandomBot to provide RandomBotMgr with more info about what happened while it was trading. I wouldn't trade a funded account with it -- during today's day session it ran long enough to generate about 100 trades and lost about $1000. If the bid/ask doesn't change between an entry and exit order, then the bot loses 0.25 points + commissions.
I mentioned that I had a problem with "static context". Here is some code that illustrates the problem. That 'main' is "static" has nothing to do with it. The compiler's error message isn't very informative. Code: class A { public void b() { } } class AA { static public void b() { } } public class X { public static void main(String args[]) { // does not compile, because // "non-static method b() cannot be referenced from a static context" /* * A.b(); // 'A.b' has not been instantiated * */ // compiles A nonStaticContext = new A(); nonStaticContext.b(); // 'nonStaticContext.b' was instantiated, // "once", when the constructor for 'A' ran // compiles AA.b(); // 'AA.b' was instantiated, "once", // when the compiler ran } }
When the bot traded yesterday, it was run from a script and traded a 5 minute session each time it ran, so it made a lot of trades over the hour or two that it ran. Today, it was started about 1/2 hour after the day session began and wasn't run from a script, so a single session ended when the market closed. It made 6 round-trips for a net gain (after commission of 4.80 per round-trip) of 183.70. The record is at the end of this post (times are GMT). I may add a feature that limits the number of trades it can make during a session. As a session wears on, the round-trip interval becomes shorter. The bot will trade once per round-trip interval. If the number of trades per session isn't limited, the bot's trading frequency increases as the session wears on (round-trip intervals (trading opportunites) occur more frequently). If the round-trip interval is short, the bot gets chopped-up -- see the last two of today's trades for an example. A small number of trades per day is fine with me, because I'd like to analyze the bot's trades and don't have enough time to analyze a lot of trades. Whether the bot makes or loses money is just a matter of timing; it isn't affected by fear/greed, impatience/impulsiveness, doubt/hesitation; it has the essential characteristics of a world-class trader, although it might be considered to have a timing problem or be considered lucky or unlucky, depending on how a particular trade turned out. But a lot might be learned, after a session, by looking at the bot's trades in the context of several charts and asking: Was it a good/bad trade? How? Could it have been a better/worse trade? How? etc. ESH7;SLD;1;1450.25;16:24:18;20070206;GLOBEX;XXXXXX;;; ESH7;BOT;1;1449.50;17:09:27;20070206;GLOBEX;XXXXXX;;; +32.70 ESH7;BOT;1;1449.25;17:25:56;20070206;GLOBEX;XXXXXX;;; ESH7;SLD;1;1451.00;18:56:34;20070206;GLOBEX;XXXXXX;;; +82.70 ESH7;BOT;1;1450.50;19:10:22;20070206;GLOBEX;XXXXXX;;; ESH7;SLD;1;1451.50;19:37:52;20070206;GLOBEX;XXXXXX;;; +70.20 ESH7;SLD;1;1452.75;20:22:52;20070206;GLOBEX;XXXXXX;;; ESH7;BOT;1;1452.25;20:46:00;20070206;GLOBEX;XXXXXX;;; +20.20 ESH7;BOT;1;1452.25;20:49:43;20070206;GLOBEX;XXXXXX;;; ESH7;SLD;1;1452.00;20:59:42;20070206;GLOBEX;XXXXXX;;; -17.30 ESH7;BOT;1;1452.25;20:59:45;20070206;GLOBEX;XXXXXX;;; ESH7;SLD;1;1452.25;20:59:58;20070206;GLOBEX;XXXXXX;;; -4.80
There may be an arithmetic mistake in that last post. The bot should generate a transaction report at the end of session, summarizing the trades. Later. Six things can go wrong while RandomBot works on a round-trip. To communicate some status back to RandomBotMgr about what happened while RandomBot was working, I've used the 'Callable' interface from java.util.concurrent.*. Instead of a 'run' method, a class that implements 'Callable' has a 'call' method, which can return an 'Object'. RandomBotMgr logs a message and quits if the RandomBot's call method returns a value that doesn't indicate success. At this time, I don't know whether any of those things are recoverable and don't know what can be done to recover if they are. An alternative might have been to have RandomBot throw an exception that would indicate to RandomBotMgr that something went wrong. Before doing that, I'd want to know more about Java exceptions and more about what exceptions might be caught other than the six that RandomBot might throw. RandomBot crudely waits for order status: Code: iterations = 0; loopCount = 200; tries = loopCount; ms = 25; while ((tries-- > 0) && Order-Status-Event-Has-Not-Occurred) { Thread.sleep(ms); iterations++; } if (tries < 0) Order-Status-Event-Did-Not-Occur; else Order-Status-Event-Did-Occur; // took iterations * 25 ms. RandomBot decides whether 'Order-Status-Event...' is true by watching one of its 'int' variables, which can be modified via a setSomething() method. I don't know enough about Java threads at this time to wait-for-an-event with timeout, if that can be done. EReader is the thread that calls RandomBots's 'setSomething' method, which modifes the variable that RandomBot (a different thread) is watching. That variable is an 'int', and I don't know whether operations on a Java 'int' are atomic; if they are not, access to that variable should be 'synchronized'. Anyway, after learning more about Java threads I may know whether EReader could generate an event that RandomBot could wait for, with a timeout. I just realized that Order-Status-Event-Did-Occur may become true only if the order was filled, so, potentially, there are two additional things that could go wrong in RandomBot: entry-order-not-filled and exit-order-not-filled. Under what circumstances could that occur? As is, the bot's 'main' could call RandomBotMgr, which could then call RandomBot, not via the 'Runnable' or 'Callable' interface but with ordinary method calls. If 'main' joins 'RandomBotMgr' and 'RandomBotMgr' joins 'RandomBot', immediately after the threads are started, 'main' and 'RandomBotMgr' aren't doing any useful work while the threads that they start are running. If it's desirable to do something while a subordinate thread is running, it might be best to have that subordinate thread "return" unusual progress information by throwing an exception, so that the invoking thread doesn't have to block in order to find out about the progress of the subordinate thread.
Yesterday, the bot traded four times. The longest was about seven minutes, another for about five minutes, another for a few seconds, then one with entry/exit at the same time, at the last second of the day session, which didn't execute until two seconds later. One trade made .25 pt., one broke even, two lost .25 pt. What was interesting was that one order confirmation took 4800 ms. It may have been due to the fact that TWS was sleeping in the toolbar all day. The bot now has a concept of "session," which has a timezone, open and close, so it has started running on Chicago (CME) time. As long as the Java runtime gets Chicago time right, the bot should work in any time zone. It also logs in Chicago time, which is useful for relating log entries to market time. My charts are set-up for market time.
Thanks again for this great thread. I did set up a SF account so that downloads and bug reports of other members can be tracked.
chameleontrader: That's good news. I think they use CVS, which lets people browse the source code, so someone could copy and paste if they have trouble using CVS. The initial code should be ready soon. I do want to put some more comments into it about known and potential problems. I am also making a few improvements, like the idea of a "session," so that someone doesn't have to modify the code to get it to run in a particular time zone. There are a lot of things that could be done to it -- even need to be done -- and having the ability to version the code will save a lot of trouble.
It pays to put a bit of thought into timezones and trading sessions. It's a bit of a nasty. For example Asian markets such as Nikkei and HK have more than one session with a break in between. On the same exchange, some futures contracts have different trading sessions. If you are handling time series, you need to make a decision very early about what timezone you are going to store them in. Probably Universal Time (GMT) is best, then apply suitable corrections for other time zones.
dcraig: Thanks for the input. Right now the bot just has one 'Session', because it only trades ES at the CME during regular trading hours. With the concept of a session, though, it could easily loop over more than one session. That would require the bot to set-up a list or an array of sessions, which could be done. Right now the bot doesn't subscribe to market data, because it does random-trading, so price and volume don't matter, but, yes, GMT might be best for the long term. Even if everything were logged in GMT, it would be easy to write a script that got interesting information out of the log and presented it in whatever time zone the user wanted. Using a session time-zone, open and close set to the exchange's time-zone, open and close, seems to let the bot run anywhere, without needing to consider daylight savings time. At least it is working this morning, in my time zone, which doesn't have daylight savings time even though Chicago probably does.