Are a lot of our algorithms not using similar logic?

I had a go at making a diagram below to show what I mean :P

Adam,

Yeah, something like that is the basic idea. Just trying to think of ways to structure programming.

Grant

Thought I'd revisit this. I'm still getting up the learning curve w/ Python and defining the architecture of larger programs, but it seems that something more structured would be appropriate. I came across this:

http://python-3-patterns-idioms-test.readthedocs.org/en/latest/StateMachine.html

I'll put it on my Kindle and read it as time allows.

Anyone experienced with state machines in the context of automated trading?

Grant

http://www.amazon.com/Professional-Automated-Trading-Theory-Practice/dp/1118129857/ref=sr_1_1?s=books&ie=UTF8&qid=1391987096&sr=1-1&keywords=automated+trading

This book heavily promotes FSM and the Actor "swarms" model for automated trading. The code examples are all in LISP, and the nature of the proposed framework doesn't lend itself well to the python/quantopian infrastructure. That said, the basic structure of a FSM with a complete domain over the inputs and predicate functions to evaluate the state transitions would work.

It's pretty easy to read if you like that sort of thing!

The promise of FSM, in my mind, is that it ought to make it easier for an interrupted algorithm to pick up where it left off and rediscover its state. If there's an AWS outage and the algorithm misses a bunch of bar events, then re-awakens long a portfolio that it ought to be short, in theory, a tight FSM ought to have only one possible state that it could be in and so it can pinpoint that state and then carry on. There are other benefits, like replayability and so forth, but I am not sure how much those matter within the quantopian environment.

State Machines are the nuts and bolts of software in Embedded Code/Software: the code that runs your TV, dish washer, car, etc.
In Electrical Engineering or Computer Science this is heavily used in many pieces of software.

You can find many examples of this - you can write it yourself, or use a frame work (my recommendation).
The tricky part is that you don't miss a condition, or don't end up stuck in a state.

A framework helps you, to keep the overview. Graphical tools are only helpful with a small number of states (smaller than 8 or so).
Writing them down on paper is a very good way to design them - then it is easy to implement simply in code.

Here is some more information on finite state machines in Python. Much of it may not be portable to Quantopian, however.

https://wiki.python.org/moin/FiniteStateMachine#Finite_State_Machine_Editor

Here is my simplistic implementation of slightly modified simple algorithm using FSM.

If I were you, I'd have have the state transition predicates in the table, separate from the state transition actions. The invalid/inaccessible state transitions should still be in there, but with a null predicate (in this case, bought -> sold, sold -> bought).

I used only valid transitions for simplicity reasons. The main goal was to make code small and easy to grasp. I'm not sure I succeeded, but I'd be happy to answer questions if any.

Thanks all for your replies. I hope to get back to this at some point. I'm realizing the need for more structured code. One thing, still kinda murky in my mind, is that handle_data will be called every minute (the minutely data feed clock). And other custom functions can be called from within handle_data. So, there is a synchronous element to the code execution, in the sense that new market data will only be available every minute (via rolled up OHLCV bars from the Nanex data feed). However, there is also asynchronous code, within the synchronous code. From what I've gathered, the ordering process is asynchronous. Orders can be submitted, filled, queried, and cancelled irrespective of the data feed clock. Is anything else asynchronous (e.g. the portfolio and position objects)?

Also, it seems like some sort of comprehensive trading_state helper function would be in order here. In other words, with one call to trading_state, asynchronously, I would get a full snapshot of what's going on at Interactive Brokers.

As a side note, there is an automatic state transition, imposed at EOD, per the help page Live Trading section:

• All open orders are cancelled at end-of-day.
  
• Orders made in the last minute of the trading day will be automatically cancelled.

So, optionally, those orders could be re-submitted the next trading day.

Hello Grant,

We need clarification of the meaning of "open" - there's nothing like starting at the basics!

A Market order submitted at 16:00 is considered 'open' and is cancelled overnight.

A Stop order submitted at 14:00 is shown on the paper trading Dashboard as 'open' which means.....

Surely the Stop order went to IB a second or so after 14:00 and is on their system. But is it a Day order or is it GTC?

Or, in a possibility I haven't considered so far, is the the Stop sat on the Quantopian server waiting to be triggered? Since Quantopian use Nanex data not IB data is this possible?

Can someone with a live IB accout / real IB paper trading account tell me if Stops go immediately to IB and, if they do, whether they are Day or GTC?

P.

Hi Peter,

I'm figuring that any instructions for or already at IB to buy/sell would be cancelled at EOD, so that every day starts out fresh. Correct Quantopian folks?

Additionally, with regard to the ability to communicate with IB, there are synchronous (minutely) and asynchronous (immediate) modes. Aside from order submission/status/cancellation, I'm kinda murky if everything else occurs on the minute or not. What is the story?

Grant