Developing "Spartan"

Well, it hasn't been exactly six months but I figured I should post an update: things are going _really_ well. I am super happy with the process and software I've developed.

I haven't fully automated it, but just this week, I had a breakthrough which will give me the confidence to automate everything.

Ironically, or maybe not, I generally only have "one big trade" per day and I am done by 11-12. The reason I say this is ironic was in my initial journal on this site, I had the idea that I should be able to achieve my goals with one trade.

I guess you get out of the market exactly what you want.

So now I want 8 figures. Will figure it out.
 
Where the fuck you been dude? Yep, get rich quicker my friend, before your nuts sag to the floor. You can do quite well running one trade per day on a liquid market, if you have a good handle on the ATR.
 
digitalnomad said:
Where the fuck you been dude? Yep, get rich quicker my friend, before your nuts sag to the floor.
More...

Honestly, I got pissed at one of the admins on this site and decided I didn't need his drama. But I missed you guys.

digitalnomad said:
You can do quite well running one trade per day on a liquid market, if you have a good handle on the ATR.
More...

Indeed. I didn't feel as if I really had a "handle" on things.

The only bump in my planning so far has been that I overpaid uncle sam by 5x this year. So that keeps him off my back for a while at least. I love my new accountant.
 
The red actually signifies profitable day, just the way the code works.

upload_2019-10-31_19-15-58.png
 
Software design

I just re-read the thread and it was really fun to see the things I thought were important vs the things that ended up being important.

Of course, as most people said: the software is not the most important thing. Except, it kind of did end up being absolutely essential. The software chooses the instrument, price, sizing, entry, I just click a button. Even that being true, it is extremely important not to over-engineer.

The patterns that worked really well:

  1. The data model should be the database. Constraints, relationships, views. Everything should be here as much as possible.
  2. Avoiding a monolith - lots of little "apps". I've got one to delete tweets, one to test query performance, one to post trades to twitter automatically. Posted below, see how the design compounds to make it easier: standardized config, single entrypoint, etc.
  3. upload_2019-10-31_22-25-29.png
  4. Compare to the "app" for recording ticks
  5. upload_2019-10-31_22-28-6.png

  6. Using ipywidgets with Jupyter. A complete lifesaver. Look at this code for my trading checklist, it can't really get much easier to tie it together (this is all stored in a database, see if you can even figure out where, it's all done transparently):
  7. upload_2019-10-31_22-10-43.png
The patterns that did not work well at all:

Nothing so far. There is no part of my system that I dread touching which is really how I tell if I did something wrong. I guess all that experience worked out
​
Well, actually that's not entirely true. I use plotly to plot a chart for the instrument I'm looking at. I hate plotly. But it is the best charting available in jupyter for live streaming.

Trading system

When I started this journal, I was into forex, trend following. After a few months of paper trading it, I realized it was way too much hard work for a measly 15% return. I went back to the basics, did a ton of research and ended up finding a system that works for me. When I say a ton, I mean a ton. Day-in, day-out.

The "edge" is that I don't need machine learning and so the search is done on demand. After calibration, the same system can be applied to any instrument. This is what I was looking for. Not just forex, not just stocks, not just futures. Also: no indicators, no moving averages. My favorite part. Pure price action.

Next steps

Full automation.
 
Last edited:
IAS_LLC said:
Good luck, sir. 1 recommendation....don't tie yourself to QT. I made that mistake on my first iteration of a trading platform. I really like Qt, but I strongly recommend you use something browser based (bokeh) if you have any desire to host your software in a data center and monitor it remotely.
More...

I've tied myself to Qt for the most part, I believe a Pandas/Qt backtester is the best approach in Python. It's best to run live trading separately and GUI monitoring isn't really something most need, backtesting on the other hand is something I find difficult without a graphical interface.

I've recently learned that when using anything Qt, it's best to use the native components as they're a lot faster than 3rd party modules. Of course for financial data, Qt doesn't offer anything so Pandas is the obvious choice. It's very time-consuming however as most don't communicate well -- even something as simple as date conversion is a challenge (which I managed to solve) as anything Python relies on Datetime while Qt has it's own format.
 
d08 said:
I've tied myself to Qt for the most part, I believe a Pandas/Qt backtester is the best approach in Python. It's best to run live trading separately and GUI monitoring isn't really something most need, backtesting on the other hand is something I find difficult without a graphical interface.

I've recently learned that when using anything Qt, it's best to use the native components as they're a lot faster than 3rd party modules. Of course for financial data, Qt doesn't offer anything so Pandas is the obvious choice. It's very time-consuming however as most don't communicate well -- even something as simple as date conversion is a challenge (which I managed to solve) as anything Python relies on Datetime while Qt has it's own format.
More...

Not sure what you mean about native vs third party for Qt. Qt isn't native! Though I'm with you on Pandas for backtesting.

Although I haven't tied myself to anything, I use the exact same interface for backtesting as live trading as paper trading. Psychologically, it's helpful but also, it means I exercise the same code for everything. Obviously, for backtesting it's a little silly since it goes really fast but I throttle GUI updates.

Right now, the interface is based on Jupyter as mentioned and it isn't much at all. All of the JS is a custom table widget.

upload_2019-11-2_10-55-35.png


Excluding the GUI code:

upload_2019-11-2_10-53-16.png


Note that the actual trading notebook is literally the following code, so the vast majority of the notebook code is research. Means about 20% of the code is GUI-related which is why I can confidently say I'm not tied into anything. Most of the logic is in the trading model.

Code: 
import os
if os.path.exists("../spartan/__init__.py"):
  os.chdir("..")
else:
  assert os.path.exists("spartan/__init__.py")
  
os.environ['SPARTAN_GATEWAY_BIND_PORT'] = '9999'
# os.environ['SPARTAN_LOG_LEVEL'] = 'DEBUG'

from spartan.jupyter.trading import *

app = TradingApp.instantiateAndRun()
 
You must log in or register to reply here.
Back
Top