Trading bot construction (IB)

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.
 
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.
 
Quote from doli:


The bot now has a concept of "session," which has a timezone, open and close,
More...

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.
 
You must log in or register to reply here.
Back
Top