Developing "Spartan"

Discussion in 'Journals' started by nooby_mcnoob, Feb 3, 2019.

  1. 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.
     
    #191     Oct 31, 2019
  2. 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.
     
    #192     Oct 31, 2019
    nooby_mcnoob likes this.
  3. 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.

    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.
     
    #193     Oct 31, 2019
    themickey likes this.
  4. The red actually signifies profitable day, just the way the code works.

    upload_2019-10-31_19-15-58.png
     
    #194     Oct 31, 2019
  5. 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: Oct 31, 2019
    #195     Oct 31, 2019
  6. #196     Oct 31, 2019
    d08 and nooby_mcnoob like this.
  7. Overnight

    Overnight

    So you are doing the Machine-Readable-Twitter algo deal?

    Smart move, because those tweets move markets. Trade trade trade.

    And Rocket man.
     
    #197     Oct 31, 2019
    nooby_mcnoob likes this.
  8. Thanks man, going to go catch up on my favorites :)

    Not exactly!
     
    #198     Oct 31, 2019
  9. d08

    d08

    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.
     
    #199     Nov 2, 2019
  10. 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()
    
     
    #200     Nov 2, 2019