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

211–220 of 372 posts

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

#211

Post by fragmede »

tech_ken wrote: post #172

>Surprisingly, we also don’t use negative numbers (you may have encountered software ledgers that store only a single positive/negative balance). Instead, we keep two separate strictly positive integer amounts: one for debits and another for credits. It's funny I've always thought of two-column bookkeeping as a kludge that was invented because the author was unaware of negative numbers. But here there's actually a ju…

Accounting for computer scientists* is a good read if you've got some interesting in accounting (and have a CS background) and are wondering why accounting is just so danged complex.

* https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

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

#212

Post by vidarh »

itsoktocry wrote: post #205
vidarh wrote: post #184

Earlier quoted context omitted.

A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us roun…

> A shocking number of people are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. What is your jurisdiction? In Canada, I can't for the life of me imagine the CRA would remotely care about decimal-point accuracy. In fact, most of their online forms explicitly remove the decimals.

UK. The rules may have changed now, it's a long time since I implemented the rounding rules here, but the last time I did it required 5 decimals accuracy. The rules also used to specify how you needed to account for line items vs. sub-totals in your invoices to ensure you didn't find any "workarounds" to shave off some pennies of tax (In fact, the last time was while the tax authority was still called the Inland Revenue, which it hasn't for years.)

For aggregate totals of your VAT liability across your total set of invoices, you'd be fine with rounding up to the nearest pound, to the Inland Revenue's benefit. For individual invoices however, you were required to stick to very specific rounding rules.

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

#213

Post by dspillett »

helpfulmountain wrote: post #189
vidarh wrote: post #184

Earlier quoted context omitted.

A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us roun…

Why would it be wrong to use floats? That would have been my default assumption

Surprisingly common values like 0.1 don't have a precise representation in binary for most formats, including standard floating point number formats. See https://0.30000000000000004.com/ for more detail than you can shake a stick at.

Also if the local tax code states using 5 decimal places for intermediate values when you will introduce “errors” using formats that give greater precision as well as those that give less precision. Having worked on mortgage and pension calculations I can state that the (very) small errors seen at individual steps because of this can balloon significantly through repeated calculations.

Furthermore, the name floating point gives away the other issue. Floating point numbers are accurate to a given number of significant figures not decimal places. For large numbers any decimal places you have in the result are at best an estimate, and as above any rounding errors at each stage can compound into a much larger error by the end of a calculation.

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

#214

Post by feoren »

schmichael wrote: post #176

I find the “no negatives” very confusing even in a double entry ledger for reasons the last sentence of that paragraph hints at: > When you need to take the net balance, the two balances can be subtracted accordingly and the net displayed as a single positive or negative number. This means you have to reconcile credits and debits using a different type than each of the columns is in. Not a huge deal by itself, but no…

Using a single signed 128-bit integer does not solve this. What happens when you have to add two of these together? Do you need a 129-bit signed integer? What about if you need to add 64 of these together; do you need a 134-bit signed integer? The point is that 128 bits is well large enough to hold the sum of quadrillions of transactions in Zimbabwean dollars. Nobody is switching to a 129-bit number to hold the results of sums; they are explicitly not handling the case where any account is anywhere close to 10^38 of the base unit.

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

#215

Post by lxgr »

itsoktocry wrote: post #205
vidarh wrote: post #184

Earlier quoted context omitted.

A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us roun…

> A shocking number of people are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. What is your jurisdiction? In Canada, I can't for the life of me imagine the CRA would remotely care about decimal-point accuracy. In fact, most of their online forms explicitly remove the decimals.

That's for final amounts though, right?

I bet they care about you not throwing away decimals in intermediate calculations for VAT or sales tax.

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

#216

Post by bewaretheirs »

helpfulmountain wrote: post #189
vidarh wrote: post #184

Earlier quoted context omitted.

A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us roun…

Why would it be wrong to use floats? That would have been my default assumption

IEEE standard floating point uses a binary mantissa.

And binary has trouble representing fractions that are common in prices:

  $ bc
  obase=2
  scale=20
  1/5
1/5 in binary is a repeating binary fraction: 0.0011001100110011...

Just as you can't express 1/3 or 1/7 precisely as a non-repeating decimal fraction, you can't express 1/5 and 1/10 as a non-repeating binary fraction. As a result, most prices involving cents in currency cannot be expressed precisely as binary floating point numbers.

edit: fixed formatting

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

#217

Post by vidarh »

robertlagrant wrote: post #194
vidarh wrote: post #184

Earlier quoted context omitted.

A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us roun…

> A shocking number of people are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. I would imagine almost no-one knows this (-: What's a shocking number?

> What's a shocking number?

Almost every developer I've worked with who haven't implemented invoicing or billing at least once and had their finance team yell at them for producing wrong numbers...

(and I'll edit this to add the limitation "who implement billing related software" - it's still true, and closer to my intended point)

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

#218

Post by eesmith »

magicalhippo wrote: post #148
eesmith wrote: post #102

Earlier quoted context omitted.

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 l…

Sure, you'll need to handle special cases yourself. But perhaps you don't have to handle all the cases yourself?

As I understand it, one of the new things in IEEE 754 is the idea of a "context", which stores this information. This can be global, but does not need to be. With Python's decimal module it is a thread-local variable.

If you are concerned about, say, mixing thread-local and async, you can also use context methods directly, like:

  >>> import decimal
  >>> x = decimal.Decimal("54.1234")
  >>> y = decimal.Decimal("987.340")
  >>> x+y
  Decimal('1041.4634')
  >>> decimal.getcontext()
  Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-999999, Emax=999999,
  capitals=1, clamp=0, flags=[], traps=[InvalidOperation, DivisionByZero,
  Overflow])
  >>>
  >>> c1 = decimal.Context(prec=4)
  >>> c1.add(x, y)
  Decimal('1041')
  >>> c2 = decimal.Context(prec=5)
  >>> c2.add(x, y)
  Decimal('1041.5')
  >>> c3 = decimal.Context(prec=5, rounding=decimal.ROUND_DOWN)
  >>> c3.add(x, y)
  Decimal('1041.4')
I don't know what the C or C++ API proposals are.

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

#219

Post by lxgr »

ilyt wrote: post #207
helpfulmountain wrote: post #189

Earlier quoted context omitted.

Why would it be wrong to use floats? That would have been my default assumption

> 0.3-0.2-0.1 -2.7755575615628914e-17 And now you overdrafted

Floating point calculations without some final rounding step before presentation/export/storage are almost always wrong, since you're implying much more precision than is justified by your source data.

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

#220

Post by jjgreen »

ilyt wrote: post #207
helpfulmountain wrote: post #189

Earlier quoted context omitted.

Why would it be wrong to use floats? That would have been my default assumption

> 0.3-0.2-0.1 -2.7755575615628914e-17 And now you overdrafted

Do it a million trillion times and we're talking cents overdrafted (almost)
Post reply on HN