Rithmic API for Python

Discussion in 'Automated Trading' started by IAS_LLC, Jul 28, 2019.

  1. IAS_LLC

    IAS_LLC

    Haven't seen this. But I'll look into it
     
    #11     Jul 28, 2019
  2. IAS_LLC

    IAS_LLC

    They've always had a FiX interface, which i assume is language agnostic. Is this what you're referring to ?
     
    #12     Jul 28, 2019
  3. MattZ

    MattZ Sponsor

    As far as I know, they always had C# and C++. The new protocol can work with most APIs.
     
    #13     Jul 28, 2019
  4. Nilats

    Nilats

    Does your wrapper support async?
     
    #14     Jul 28, 2019
  5. IAS_LLC

    IAS_LLC

    Haven't tried it, but I see no reason it wouldn't. I've used the threading module with success, but I prefer to manage the threading on the c++ side.
     
    #15     Jul 28, 2019
  6. IAS_LLC

    IAS_LLC

    What do you mean "most APIs"? Most languages? If its simply some sort of socket protocol, that would make sense. If that is the case, I wonder if it supports all of the features. Pushing full depth of market over a websocket sounds expensive. Probably good enough for 99% of people though.
     
    #16     Jul 29, 2019
  7. MattZ

    MattZ Sponsor

    Yes, most languages.
     
    #17     Jul 29, 2019
  8. rohan2008

    rohan2008

    @IAS_LLC curious about what you are seeing?

    What kind of latency are you seeing with python analytics engine? I am running a python analytic engine in parallel to my c++ trading system (Rapi based) to generate trading decisions. Everytime my C++ app observes certain conditions, it issues a http request to the python analytics app, which in turn does predictions and responds if its an "enter trade" or "ignore".

    I am seeing a latency of about a few ms per every call. I am trying to figure out whats the best to reduce the latency. Its easy to setup a ML workflow in python/pandas/juypter and train models, but I find it extremely error prone to even migrate the data prep part to C++ once I finalize my ML model in python. Any suggestions on how you are mitigating this latency issue...
     
    #18     Aug 2, 2019
  9. IAS_LLC

    IAS_LLC

    I can only measure so well, using my system clock. Ask anyone in TRUE HFT, and they will tell you timing is a challenging science. The way I"m measuring things is far from scientific...so take this for what its worth:

    Using std::chrono::system_clock my c++ to Python back to c++ time is less than 1 microsecond, which is the resolution of the clock I'm using. Obviously, this will increase if something expensive is done on the python side.

    My c++ and python application are running in the same process space, which is why I'm running so much faster than you. Inter-process/in-memory communication will ALWAYS be significantly faster than any tcp based scheme (like http).

    I'm no tcp expert, but I suspect http is relatively slow compared to other forms of tcp. That may be a place to start.

    Also...If your doing something where a few ms of latency makes or breaks your success, you need to be really careful with how you're using python.
     
    Last edited: Aug 2, 2019
    #19     Aug 2, 2019
  10. rohan2008

    rohan2008

    aah embedded python... how did I miss that. Thanks for the pointer.

    If I may ask, do you use boost or pybind11 for this? I am assuming that one should be able to import sklearn modules and pass numpy or csv arrays to fire off the inferencing engines?

    >> Using std::chrono::system_clock my c++ to Python back to c++ time is less than 1 microsecond,
    I use Poco library (https://pocoproject.org/). They have a bunch of time related APIs that are relatively reliable for this type of work: https://pocoproject.org/docs/Poco.Stopwatch.html
     
    #20     Aug 3, 2019