Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

64-bit bank balances ‘ought to be enough for anybody’?

tigerbeetle.com

Post reply on HN
Print view View original

141–150 of 372 posts

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#141

Post by pjc50 »

formerly_proven wrote: post #87
onetimeuse92304 wrote: post #59

Earlier quoted context omitted.

On my first day in a new company, not even senior dev yet, I met with the head accountant. I asked about her top problems, she said her top problem was that the application would produce different invoice on screen, different invoice when printed as PDF and a different invoice in the accounting software. About 1% of all invoices were affected but due to amount of billing they were doing (telecommunications and advert…

> I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still. Your setup made it sound like something crazy and inane, like "the PDF printer used on those machines changed floating point rounding modes" or what have you.

There was the famous "Xerox photocopier changes digits sometimes" bug, but that's not what's happening here.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#142

Post by dahfizz »

Spivak wrote: post #104
dahfizz wrote: post #88

Earlier quoted context omitted.

In programming, an `int` perfectly represents the integers between INT_MIN and INT_MAX. A `float` on the other hand, approximates the real numbers. It can perfectly represent exactly 0% of them. Having control over the rounding behavior is meaningless - floats cannot correctly represent any non-contrived calculation. Exact representation is important in financial systems.

> floats cannot correctly represent any non-contrived calculation Like adjusting all your financial calculations to use microcents and partitoning instead of division to keep the result representable by integers? Neither can represent 1/3 even shifted. When you want to do exact calculations with floats, and you can, you just have to set yourself up so that the result is exactly representable, it's not as intractable…

> they represent subsets of the reals

Sure. My point is that this subset is useless. Because trying to add, subtract, multiply, or divide members of this set will result in a number outside the set.

> When you want to do exact calculations with floats, and you can, you just have to set yourself up so that the result is exactly representable, it's not as intractable as you make it seem.

In the general case, you absolutely cannot. Lets look at some examples.

In forex trading, you need 9 digits after the decimal place in the price. So right off the bat, a valid price like 1000000.000000001 cannot be represented by a float. If the exchange sends your system that price, your system is guaranteed to be wrong.

Lets say you start at a representable price, like 1000000.0 and want to tick it up or down by the tick size, say 0.025 . The result of that addition / subtraction is not representable, so you cannot calculate and round prices correctly.

If you don't have control of your inputs, and you need precision, floats will never work.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#143

Post by lxgr »

toomuchtodo wrote: post #140
im3w1l wrote: post #113

Earlier quoted context omitted.

> I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correct This observation should tell you that's it actually quite viable to be off as long as the errors are small enough.

The world runs on "good enough."

True, but the world also runs on standards (whether explicitly defined or customary), and doing things differently from everybody else makes it painful to work together.

Sometimes there's also value in doing something objectively poorly, but in a predictable and well-understood way.

Unilaterally starting to "do numbers better" sounds like a recipe for, let's say, interesting times in the finance/accounting world.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#144

Post by t0mas88 »

RamblingCTO wrote: post #118
onetimeuse92304 wrote: post #24

Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is,…

Not sure about that. In Germany, especially SMEs, no one cares about cents. Your tax reports are done in rounded Euros anyway. People, companies, and the taxation and financial state dept. are well aware of rounding issues, different ways to round that no one really cares about cents. Besides that, using BigDecimal with two decimal places is sufficient in the java world imho. Depends on your use case. I'm entirely sc…

Same in the Netherlands. There is an official rule that you don't have to do mathematical rounding to get to whole euro's, you can do it in whichever direction is more favourable to you. That rule is probably there just to save the tax services some extra work and IT costs.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#145

Post by lxgr »

onetimeuse92304 wrote: post #24

Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is,…

The article is about data types for storage, not for intermediary values used as part of calculations, though. Are you proposing that everybody is storing monetary values "wrong", too?

And as a meta-point:

> I have been fighting over this with countless people, teams and companies. [...] I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly [...]

Are you absolutely sure that you are the only person that understands how to do accounting arithmetics on computers correctly?

My guess would be that the status quo is a combination of a lot of legacy code and procedures, but more importantly of differing priorities.

Maybe you value arithmetic correctness over simplicity of procedures (sometimes these need to be published in regulatory texts or even laws) or compatibility with other entities and their procedures much more than the industry average?

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#146

Post by dahfizz »

fidotron wrote: post #97
dahfizz wrote: post #88

Earlier quoted context omitted.

In programming, an `int` perfectly represents the integers between INT_MIN and INT_MAX. A `float` on the other hand, approximates the real numbers. It can perfectly represent exactly 0% of them. Having control over the rounding behavior is meaningless - floats cannot correctly represent any non-contrived calculation. Exact representation is important in financial systems.

TBF, be careful here. The IEEE floats can represent a subset of integers in their range exactly. For example, 64 bit floats can represent the range of 32 bit ints accurately (and more). That said, it is bizarre to claim that if the result can be represented you get the exact result, when the core problem is that the result cannot be represented because the representation is an approximation.

> The IEEE floats can represent a subset of integers in their range exactly. For example, 64 bit floats can represent the range of 32 bit ints accurately (and more).

I know, I am being a little facetious. A double has a 52 bit mantissa, so it can exactly represent integers that need 52 or less bits.

Still, as a percent, a float can represent 0% of the reals. There are an infinite amount of numbers it cannot represent, even if we give it lower and upper bounds. Whereas an int can represent 100% of the integers within a lower and upper bound.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#147

Post by cornstalks »

seanhunter wrote: post #125
rvnx wrote: post #53

Earlier quoted context omitted.

I had such case too, the solution is simple: round in favor of the bank / financial institution you are working for

That is absolutely not how it works. Rounding is exactly specified in the underlying contract always and you need to implement the correct rounding. For example, here is the rounding table for compounding calculations in the ISDA definitions (these are very standard for a wide range of contracts, but this particular table is for various overnight swap rates used in interest rate derivatives)[1]. [1] https://globalmar…

And how do they round ties? Does 0.00005% round to 0.0001%? Is tie breaking usually included in such contracts?

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#148

Post by magicalhippo »

eesmith wrote: post #102
onetimeuse92304 wrote: post #48

Earlier quoted context omitted.

Hypothetical solutions that do not exist are none of my concern. Did you know different countries and different currencies have different rounding rules, for example for tax-related calculations? Does "IEEE decimal128" support this? Unless you can get all countries on our planet to agree on a single standard, any solution that does not allow specifying rounding rules is pretty much useless (unless you want to impleme…

This is not hypothetical. Yes, of course IEEE decimal supports setting the rounding mode. The authors of the spec aren't ignorant of what's needed for financial and tax computations. Use fe_dec_setround from ISO/IEC TR 24732, "Extension for the programming language C to support decimal floating-point arithmetic". The modes listed at https://www.ibm.com/docs/en/zos/2.5.0?topic=functions-fe-dec... are: FE_DEC_DOWNWARD…

For goods items, Danish customs require specifying 3 decimals for weights under 1kg, otherwise no decimals. Off the top of my head I don't recall exactly how they expect rounding to be done, I'd guess towards infinity.

Many duties are calculated based on net weight, and often the net weight per goods line is the result of a calculation, for example you're importing N items with a per-item weight of X. If you have a large number of goods items above 1kg but less than 10kg that has weight-based duties, the rounding mode can matter a lot.

None of the rounding modes mentioned captures this below/above 1kg split, so you have to do this in code anyway. Might as well do the rounding there too, to be sure some injected code doesn't mess up the expected rounding mode or similar[1].

[1]: https://irrlicht.sourceforge.io/forum/viewtopic.php?t=8773

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#149

Post by TN1ck »

out_of_protocol wrote: post #76
throwaway894345 wrote: post #52

Earlier quoted context omitted.

What are the specific challenges to writing financial software? What are common mistakes you see? What are common data structures for representing money (both the common incorrect implementations but also the correct implementations)? Also, provided you have a data structure that can represent money, you should presumably be able to serialize that data structure and store or send it just like any other data, right? W…

String (json), decimal/numeric (db) is enough to passively store amounts. Calculations and rounding going to be funny though. E.g. split $10 bill in 3 exactly the same parts, store, sum up to $10 again

Are there actually some systematic approaches to handle these cases? Or are there some libraries making this easier? We have so many places where we keep track of the offset and spread it over the items afterwards to mitigate this. It’s annoying as it’s most often a two step process and e.g. becomes even more complex when you have constrains on the numbers like applying discounts.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#150

Post by lxgr »

RamblingCTO wrote: post #118
onetimeuse92304 wrote: post #24

Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is,…

Not sure about that. In Germany, especially SMEs, no one cares about cents. Your tax reports are done in rounded Euros anyway. People, companies, and the taxation and financial state dept. are well aware of rounding issues, different ways to round that no one really cares about cents. Besides that, using BigDecimal with two decimal places is sufficient in the java world imho. Depends on your use case. I'm entirely sc…

Only final values are rounded to full Euros (down, if I remember correctly).

If a large taxpayer starts rounding down as part of intermediate calculations of their tax liability, I think they'd get some questions.

But yes, rounding does happen a lot – what's important is that everybody uses the same, transparent rules for that, or it becomes impossible to double-check somebody's books, tax declaration, invoice etc.

Post reply on HN