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

311–320 of 372 posts

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

#311

Post by jorangreef »

hot_gril wrote: post #302
jorangreef wrote: post #297

Earlier quoted context omitted.

For sure. We didn't pick 10^10 scaling. It's just what some massive brokerages/exchanges actually use. The fact that these were not necessarily crypto made us take note. At the same time, you can understand that 10^10 scaling is at least significantly more precise. And I can imagine these things are viral too, who you trade with, also determines your minimum resolution. You can always downsample in presentation, but…

Yeah, was just curious if the brokerages explained their reasoning in detail. Even if it's just viral, someone big had to have a reason to start the trend.

Hey! Thanks for your curiosity. This was news to us too. And I think we spent about a year thinking about this before we swapped for a bigger piggy! :)

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

#312

Post by LAC-Tech »

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…

This is also the way to do it if you want a number that multiple nodes can edit independently.

When you sync back up, do a big tally at the end, and that's your final number.

(This constitutes a CRDT, and is known as the Positive/Negative Counter).

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

#313

Post by nly »

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

In my experience most financial firms just use binary floats/doubles

Fixed point decimal if you're lucky (or unlucky, since fixed point sucks)

Arbitrary precision decimal floating point essentially never used

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

#314

Post by lxgr »

manicennui wrote: post #259
lxgr wrote: post #145

Earlier quoted context omitted.

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 [...…

I agree with the parent. Almost everyone thinks floats are fine. I work in lending, and many of my coworkers, who claim to have CS degrees, do not understand floats at all.

GP isn't just saying "don't use floats", though. (And even that is only a heuristic: It's possible to get correct results using floats, but you need to be very diligent about when and how you round, so in practice it's easiest to just avoid it.)

They're saying that only arbitrary precision arithmetics are acceptable, and additionally claiming that everybody else in the world gets money arithmetics wrong.

I doubt both of these statements, and especially the assertion that there's exactly one "correct" way of doing arithmetics with money.

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

#315

Post by hedora »

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.

I think the point is that the integer arithmetic implementation your CPU provides is wrong in at least one jurisdiction, so (for example) the machine code in the article is wrong.

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

#316

Post by zie »

lxgr wrote: post #145
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 [...…

Floats are not how you do money math, if you run into anyone trying to do money math and they say they use floats, there is a 99.999999% chance they are wrong.

> Maybe you value arithmetic correctness over simplicity of procedures

Lots of places(not typically the USA) has this codified in law. For example, do a web search for: EU money rounding rules. You will find several different rounding and precision rules, depending on the context of what you are doing with the money, all from places like the Central Bank and the EU Commission.

It's mostly US developers that are clueless here, because US laws are fuzzy at best, and the general rule is, you do whatever your bank/regulatory authority does, and if they don't happen to know (and I've met several that don't), then you have to figure it out yourself.

In the USA, we use decimal.ROUND_HALF_UP, because we have seen in practice this is what our USA based banks & govt tend to do in the wild. It should be noted IEEE 754 rounding recommends using decimal.ROUND_HALF_EVEN. https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules

In other places, we do whatever their laws require, or treat them like the USA and do whatever our local bank/govt authority tends to do in practice.

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

#317

Post by tech_ken »

LAC-Tech wrote: post #312
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…

This is also the way to do it if you want a number that multiple nodes can edit independently. When you sync back up, do a big tally at the end, and that's your final number. (This constitutes a CRDT, and is known as the Positive/Negative Counter).

The idea is similar/equivalent to a stack of git deltas yeah? Each line is a change of one of two types and then you combine them to get a net change?

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

#318

Post by onetimeuse92304 »

amalcon wrote: post #170
pjc50 wrote: post #155

Earlier quoted context omitted.

I did join somewhere that could do it correctly, because they had some very long-running POS software. It could even do things like "split bill three ways" correctly allocating both the spare penny from the division and the tax calculation, such that you could add the bills back together again and get the same numbers as the split bill. Using a "money" class that stores things as integer pennies gets you a long way t…

Integer cents is fantastic for POS software and similar things that deal with at most a few thousand dollars at a time. The place where it starts to fail is when the absolute numbers get really large, not really small. Think "United States Federal Reserve" or "UBS". Then remember that some of these institutions need to deal with accounts denominated in Zimbabwean dollars.

Funny thing, I actually wrote one POS application (magstripe + EMV chip & pin + contactless).

EMV uses integers encoded as BCD for money. If I remember well, in most cases it is 6 bytes or 12 digits. That is more than 2^32 (most of POS machines were 32 bit ARM until relatively recently).

The terminal I worked on had 32 bit ARM. Rather than convert 12 digit numbers to 32 bit integers I decided to write my own arithmetic library that did operations directly on BCD strings of arbitrary length (but, in practice, EMV only allows 6 bytes for the amount anyway).

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

#319

Post by lxgr »

RamblingCTO wrote: post #238
lxgr wrote: post #150

Earlier quoted context omitted.

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.

Well, how much money can you save by efficient rounding? Surely not that much that anyone would bother. There's a thing called "Kaufmännisches Runden", which is kind of cheating as well. > 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. They don't, that's why it…

> Well, how much money can you save by efficient rounding?

You and me? Probably a few cents.

A bank or a large corporation selling things billed in sub-cent amounts? Single-digit percentages of their gross revenue, i.e. many millions.

Just as a very simple example: I'm your bank/phone provider/..., and I'm charging you a flat fee of 1.9 cents per transaction/call/... You're my customer and make a billion of such transactions per year.

Option 1: 1000000000 * 0.019 = 19000, you owe me $19000000.

Option 2: There are no fractional cents, so let's just round up each individual billing event. 1000000000 * 0.02 = 20000000, you owe me $20000000. Cool, a free extra million for the company!

This is why these things are precisely regulated when it comes to sales tax/VAT, for example.

> There's a thing called "Kaufmännisches Runden", which is kind of cheating as well.

Always depends on which side you're on. If you're getting a refund, it can work in your favor! Importantly, it's a precisely defined rule so that it's not possible to cheat in the implementation.

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

#320

Post by onetimeuse92304 »

giantg2 wrote: post #224
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…

The hero I want to be

It is easy to be a hero when the company is shitty.

My career advice is to work in a field / company / job where you can be somewhere in the top 10-20% of all employees. Just don't overdo it, if you are top 1% you are probably aiming too low and could be working for better paying, more rewarding field / company / job.

For a lot of my career I was working for financial institutions like banks. A lot of really badly managed projects with definitely not top level developers. Easy to be a top performer. I really like helping people and projects and it was working well for me especially when it was easy for me to provide valuable help.

I got hired once for a really good company with really top performers and suddenly I lost the status that I was so used to. I was keeping up with my work, sure, but I was no longer a shiny star. I got back to working for banks.

Post reply on HN