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.
There are a lot of alternatives, use them.
Never use floats for prices and rates.