[nostrademons]

It's been interesting to observe this impedance mismatch in practice. My first job was writing software for a startup that sold to quant hedge funds. I did a bunch of research on my own, and one of the best practices I ran across was do not use floating point to represent money. Represent everything in terms of integer units of the most basic currency unit (usually cents), to avoid round-off errors. Then I took this information to my CEO, who shot me down on the basis that all their customers used floating point for their internal models, and so I'd be needlessly introducing friction.

And now I'm doing cryptocurrency analytics. The basic unit of Bitcoin is the satoshi, and in the protocol, all transactions are denominated in satoshis. (Similarly, in ethereum, the base unit is the wei and all transactions are denominated as 256-bit words of wei.) And yet basically all exchanges are still using floats. Sometimes they quote them as strings to avoid round-off, sometimes it's double-precision, but internally, it's all just floating point math. So once again I find myself doing everything in terms of floats, even though the underlying financial instrument uses integer units of a very small denomination.

Now that there's a huge proliferation of cryptocurrencies, I wonder if we'll eventually see one that gives up on this point and defines money as IEEE 754 double-precision floating point numbers.

[gshdg]

Seems like someone familiar with inflection points in floating point representation could pull an Office Space-style skimming scheme against a floating point based system by perfectly legal means simply by making a lot of transactions of carefully selected sizes.

[nostrademons]

Interesting idea. Most of the inflection points I've observed have actually been at transaction/analytics boundaries. Transactions are in integer units, analytics are in floating point. It's done this way because many algorithms (including most linear algebra, statistical, and machine-learning algorithms) operate on floats for efficiency, while transactions operate on ints for accuracy.

This isn't directly attackable, but you could potentially trick a trading algorithm into performing stupid trades by feeding it subtly inaccurate data. If you know the particular algorithm used, though, there are probably easier ways to construct adversarial inputs and trade against them. This is why virtually all trading shops keep their algorithms secret, and also slice up & mix their outgoing orders randomly so you can't observe the output of the algorithm.

[pmart123]

Floating-point precision can work depending on the financial application. If you are back-testing on exchange data, your simulation code only buys or sells at the bid or ask prices, so even if the signal has floating point imprecision, it doesn't really affect the result. On valuation work, getting the inputs into a DCF/reverse DCF right is much more important than exact precision. I realize this is vastly different than writing an accounting application, but for most hedge funds, it probably won't make a difference to use floats vs. decimals.

[flukus]

> Then I took this information to my CEO, who shot me down on the basis that all their customers used floating point for their internal models, and so I'd be needlessly introducing friction.

Sounds like all there customers had already worked around the bugs and they didn't want to backtrack. Floating point can be horrible because not only do both sides have to use it but they have to process their calculations in the exact same way with the same order, with decimal types you will get consistent results.

Throw in some other complexities like different clients using different value precisions, different currencies having different fractional values (japan has no decimal places, a Kuwait cent is a thousandth of a dollar) combinations of those two and more, then using decimals/money types are just easier.