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

351–360 of 372 posts

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

#351

Post by kazinator »

Dylan16807 wrote: post #309
Merad wrote: post #298

Earlier quoted context omitted.

> Why was it listed separately at all? Because the bill included a detailed breakdown of all the fees by type and transaction. Typically our clients were charged a fixed monthly fee, a fixed authorization fee charged every time a payment was attempted (even if it was declined), and a fee applied to successful payments that was a percentage of the payment amount. There were other fees for things like processing charge…

I wasn't talking about rounding up. I meant exactly the same thing you're saying about month 4. > Because the bill included a detailed breakdown of all the fees by type and transaction. Was it all rounded [down] to the nearest penny? That type of bill can already fail to add up to the total very easily, like x.xx4 + x.xx4 + x.xx4. So I'm still not sure why there was a need to have a line item to explain this single p…

Canada abolished the penny some years ago. If some retail item in a store costs $2.03 and you insist on paying with cash, you will have to use a nickel and pay $2.05.

Yet, life goes on; nobody goes to jail.

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

#352

Post by Aardwolf »

ilyt wrote: post #221
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…

Well you did turn your hypothetical ignorance into practical one, I got calculator using it... actual physical object.

Must be a SwissMicros!

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

#353

Post by jorangreef »

munificent wrote: post #328
jorangreef wrote: post #209

Earlier quoted context omitted.

Hey! Joran from TigerBeetle here. (I know this only because I somehow happened to major in Accounting back in university), but when you represent a general ledger of accounts, there are always two positive columns for amounts in any given account, one for debits, the other for credits. The golden rule is that you always add to either column. You always preserve information. To see why two columns (or two integer bala…

> You always preserve information. Using two positive numbers preserves some information, but still destroys plenty. Just less than a single signed number would. Consider two accounts: 1. An account A with a debit balance of $1m and a credit balance of $0, and 2. An account B with a debit balance of $1m and a credit balance of $0. One of those was opened by a lottery winner last week who did a single transaction drop…

> You always preserve information.

This is the principle.

Not to suggest that the sum of debits and credits alone is sufficient to that end, but rather to explain why it's at least necessary.

> To really preserve information, you'd need the full list of all transactions.

Exactly. And so this is, of course, what TigerBeetle also does (with full durability).

And, at the same time, TigerBeetle doesn't decompose account balances to a single integer, for the reasons given.

Both of these are important.

To be clear, the context for this thread is the latter: Why not decompose account balances to a single positive/negative integer?

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

#354

Post by jorangreef »

walnutclosefarm wrote: post #336
jorangreef wrote: post #280

Earlier quoted context omitted.

To be fair, I used to think like this too, but chatting with multiple large exchanges/brokerages made us realize this was a thing. > less than 10^15 cents There are systems that don't work in terms of cents (cf. the examples of issues in many of the comments here), or even in thousandths of a cent, but with significantly more precision. Literally, in other words: Where you run into problems then, with 10 ^ n integer…

I'm not sure I understand what you're saying. Are you saying that these exchanges are trading at prices to a precision of 10 ^ -10 dollars (or other currency)? I saw private exchanges pricing to hundredths of a cent (a long time ago - it's been a decade and half since I worked on Wall Street or in the City) or yen, but never any finer than that. Even then, all transactions were recorded in whole cents. I'm sure you'v…

Yes, exactly. And we were surprised by this too. But it can be typical for prices that are fractionally traded. See https://news.ycombinator.com/item?id=37574440

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

#356

Post by david422 »

brewdad wrote: post #278
david422 wrote: post #162

Earlier quoted context omitted.

Whenever I input my tax data on forms, it always rounded to the nearest dollar. It was strange that accuracy didn't seem to be a big priority.

I imagine over millions of returns it probably evens out. Also, for the majority of taxpayers in the US, the tax table does things like: AGI is 40,001 to 40,025 then your tax is X dollars. Being accurate to the penny isn't worth the trouble.

Yes, practically I can see why. But when my W2 contains cents, and my tax forms make me sign for accuracy under penalty of whatever blah blah, seems pretty odd that they don't accept my cents and then do their own internal rounding. Maybe it was just the tax software I was using.

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

#357

Post by munificent »

lxgr wrote: post #337
munificent wrote: post #325

Earlier quoted context omitted.

Ths problem isn't rounding the final result. The problem is that the source data itself can't be accurately represented. There is no floating point value equal to 0.3.

That’s not a problem by itself. You can represent 0.3 as 0.300000…0004, which rounds to 0.3 again in the end. But you need to reason about the number and nature of intermediate operations, which is tricky, since errors usually accumulate and don’t always cancel out.

> That’s not a problem by itself.

No, it really is the original sin here.

> since errors usually accumulate and don’t always cancel out.

The problem is that from the system's perspective, these aren't "errors". 0.3000000....4 is a perfectly valid value. It's just not the value that you want. But the computer doesn't know what you want.

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

#358

Post by hot_gril »

filoeleven wrote: post #346
hot_gril wrote: post #292

Earlier quoted context omitted.

But nothing can do that exactly, for example 1/3 has an infinitely long decimal or binary representation. So why round to 10^-10 as opposed to something like 10^-3?

Some languages do have proper support for ratios, so if you define x = 22/14, the value stored is 11/7. Multiply later by 7 and you get 11. You can maintain exact calculations through an entire data pipeline this way, as long as your base numbers are all integers and ratios, and optionally have one rounding step at the end if you want a decimal value. Most math languages and lisps do this. There must be libraries for…

Yeah, I thought about that. Wonder how efficiently a database can be tweaked to support this, cause that might matter even more than language support.

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

#359

Post by Merad »

kazinator wrote: post #349
Merad wrote: post #248

Earlier quoted context omitted.

A shocking number of people who work with software that handles money are just winging it. I worked on a project once that handled payment processing functionality for other products at the company (it was a B2B SaaS where clients could take payments through our software). We also handled payments related billing, since the clients would owe fees to us and to our payments gateway for their transactions. The payments…

> Anyway, that 1 cent charge just infuriated clients for some reason, and every month or two we'd get bug reports about it or requests to explain why it kept showing up. There is an obvious alternative here, which is to just absorb that fraction of cent, so the customer doesn't see it. Handling bug reports and infuriated clients costs more. You could even just round up to the penny and ding the customer; if there is…

> Oh, the business teams found the approach puzzling---but what do they know, right? If they were smart, they would be software engineers.

Well in this case the business teams selected the 3rd party payments gateway that the company would work with, negotiated the contracts with them, and worked with the 3rd party to set up how the customers would be charged. They and/or the product team determined that we'd use the 3rd party system to handle the billing because building it in house wouldn't generate any new revenue. They weren't stupid, but they choose an approach to payments processing that was pretty low level (because it generated more revenue, of course), without anyone at the company having a good understanding of low level payment processing details. The engineers learned because we kind of had to, but three years into the project (when I left) business/product would still routinely struggle with the details.

So anyway, WRT to billing, the task handed to engineering was: pull the billing detail from the 3rd party's API and assemble it into a statement that can be handed to a client. We had zero control over how the charges were generated or applying any rounding to the total.

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

#360

Post by kazinator »

Merad wrote: post #359
kazinator wrote: post #349

Earlier quoted context omitted.

> Anyway, that 1 cent charge just infuriated clients for some reason, and every month or two we'd get bug reports about it or requests to explain why it kept showing up. There is an obvious alternative here, which is to just absorb that fraction of cent, so the customer doesn't see it. Handling bug reports and infuriated clients costs more. You could even just round up to the penny and ding the customer; if there is…

> Oh, the business teams found the approach puzzling---but what do they know, right? If they were smart, they would be software engineers. Well in this case the business teams selected the 3rd party payments gateway that the company would work with, negotiated the contracts with them, and worked with the 3rd party to set up how the customers would be charged. They and/or the product team determined that we'd use the…

If someone had a gun to my head saying, don't hide the sub-penny slices from the billing, I would just do the billing in thousandths of a cent, rather than make "leap cents" appear every couple of bills:

  Amount owing: $123.45678

  Please pay one of: $123.46 (a credit  of $0.00322 will be applied)
                     $123.45 (a balance of $0.00678 will carry forward)
On the next statement, if they paid $123.46:

  Previous balance: (  $0.00322) [credit]

  New charges:        123.45678  { here we have a detailed breakdown }

  Amount owing:       123.45356

  Please pay one of: $123.46 (a credit  of $0.00644 will be applied)
                     $123.45 (a balance of $0.00356 will carry forward)
etc.

That's literally "put the billing detail from the 3rd party API and assemble it into a statement". Since the billing detail from the 3rd party API is in thousandths of a cent, then that implies the statement must have thousandths of a cent.

If the two payment options were determined to be too confusing, one of the two could be dropped.

Post reply on HN