Rithmic API for Python

Isn't the new R-Protocol allow you to work with Python? We recently brought a customer who came from IB (who used python) and was able to use the new API. I am curious whether this wrapper would save others time and effort of writing their own or is that simple to do with the new API?

Haven't seen this. But I'll look into it
 
They've always had a FiX interface, which i assume is language agnostic. Is this what you're referring to ?

As far as I know, they always had C# and C++. The new protocol can work with most APIs.
 
As far as I know, they always had C# and C++. The new protocol can work with most APIs.

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.
 
@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...
 
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:
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
 
Back
Top