Minor disaster with the probability of becoming something worse, you never know where these values will end up being used/stored and it's likely that somewhere else in your code some weird form of equality will start appearing at some point (value1-value2<1E-04, lol).
> Using doubles for crypto prices instead of fixed point seems like a disaster waiting to happen?
TDLR; nope.
That depends what you use the incoming data for. Bookkeeping, yeah. And that's about it.
This doesn't look like it was meant for that. Some sort of trading where you track a bunch of indicators over a day (not HFT at their timings at the moment but along those lines): you absolutely want to avoid fixed point because of the speed penalty. See also [1].
Indeed. Although I don't know what precisions are required in crypto products, in traditional trading an 8 byte double is quite enough - the price submitted will have to be rounded to the instrument's precision anyway (e.g. most spot FX products are rounded to 5 decimal places).
With a caveat here, after a very quick look at the code: The price here is defined as long double, which can be different among platforms... My Mac/clang says that long double is still 8 bytes, Linux on that same arm64 machine says it's 16 bytes (and I'm not sure what that's mapped to these days - 80bit FPU instructions, or some Float128 representation)
The orderbook class uses original strings received from the exchange as keys. However, in some places, numbers are compared with a precision of 1e-12 as long doubles. I plan to modify this to use the symbols' price step from exchangeInfo.
How can you say that so confidently?
Floating point is terrible for decimals, as any number not consisting of only 0's and 5's after the decimal point does not have a precise representation.
What if you're counting ratios or differences? Those values are no longer precise. What if you're comparing those ratios or differences? That comparison cannot be trusted.
What if you have a NaN? Now all your comparisons return false and any values you calculate from the NaN will also be NaN.
There is no way you can confidently claim these issues won't show up in a production system without doing fuzzing and formal verification. Just use big integers, 64 bit integers can represent 18 quintillion (short scale) values, which if you're trading in fractions of cents should be enough of a range for the foreseeable future. 128 bit integers will always be enough.
You are correct. When I referred to 'real-time', I meant it in the sense that it is as efficient as consuming data directly from the exchange's WebSocket because, during the consumption stage, data is directly consumed from the exchange, not an intermediate server.
Since Binance only provides 100ms diffs, there isn’t 'real-time' in the sense of receiving each atomic orderbook change.
Thank you for your feedback, I changed the description.
There aren't any. The fastest access you can get to Binance is in apne1 (az depends on which products you are trading). There are also a lot of systematic strategies worth automating that aren't really latency sensitive.
The crypto/cloud equivalent is letting market makers connect directly to the exchange front end servers via AWS VPC peer or equivalent rather than going via the public load balancers.
No such thing as colo for most crypto exchanges, at least not officially. But your general point still stands. This is a cute project that's likely useless for anything serious. People go to great lengths to shave a bunch of ms off these feeds.
lots of programmatic strategies are not latency sensitive, most even
and the crypto market, despite its volatility, does not move that fast, it just has 24 hour trading, in comparison of 6-8 for equities, in a single day
so the 3x greater trading sessions create the eternity
It's cmake based, you can download cmake and the other dependencies and just compile it.
Edit: actually no, the networking bits have some platform specific #ifdefs. The code looks not too difficult to rewrite into a WinHTTP based client, though.
