Hacker News Reader

Comment by koolba | Hacker News Reader

Those that do not understand why floating point math has no place in the world of money are doomed to repeat this mistake. Over and over and over ...

The snippet of what I presume is their API response is interesting:

     {"currencyCode":"XBT","balance":100000.00000008,"available":100000.00000008,"onDeposit":0}

The amount fields are JSON numbers. That's fine for integers up to 2^52[1] but can have issues with floating point math. They'd be better off representing everything as satoshis and doing integer math on everything.

I bet their entire system is based on floating point math. Tisk tisk ...

[1]: Yes probably not an issue unless your Bill Gates and convert your networth to Zimbabwean dollars...

View on HN

As someone who is trying to get deterministic simulations relying on floats - the idea to use floats for money boggles my mind. Having a simple addition give the exact same thing on different machines - bit for bit - is already causing headaches.

That's odd. IEEE 754 requires that basic operations produce the closest possible result to the exact answer. (Those operations are simple arithmetic, square roots, remainders, rounding, and various format conversions.) As long as the rounding mode is the same on all machines, they should all give identical results for something like addition unless you're using hardware that doesn't do IEEE 754.

You will, of course, run into huge trouble if you perform more complex operations. All bets are off once you start doing things like trigonometry or logarithms, unless you implement it yourself.

Even if you only have 2 additions in a row, the following things cause problems: Rounding mode, distributivity (or rather, lack thereof), intermediate precision, compiler optimisation, denormals, real IEEE754 conformity of the platform... The list goes on.

A common cause of this is 32-bit x86 builds that use x87, which uses 80-bit precision which sounds like a good thing except that it only does it while values are in registers, which from the programmer's viewpoint means the precision might as well be fluctuating at random. Solution: don't use x87. There are a few compiler options for this, but the most obvious one is to just always build 64-bit.

* you are

Reply on news.ycombinator.com