64-bit bank balances ‘ought to be enough for anybody’? • Hacker News Board

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

#341

Post by lr1970 » Wed, Sep 20, 2023, 1:37 AM UTC

Fundamentally, the problem of representing money as Integers is division. A set of integers is not closed over division and, as mathematicians would put it, set of Integers does not form a field. For example, 10/3 is not an integer. Making fundamental money unit small does not solve the problem, it simply limits the size of rounding error. Division followed by multiplication can amplify the rounding errors.

A clean solution would be to use rational numbers of the form y/x stored as a pair of 64-bit numbers. It takes the same 128-bits space as in TigerBeetle proposal but has advantage of exact arithmetic with no rounding errors.

EDIT: typos

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

#342

Post by MobiusHorizons » Wed, Sep 20, 2023, 2:05 AM UTC

wrs wrote: post #195

helpfulmountain wrote: post #189

Earlier quoted context omitted.

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

Laws are typically written by humans, and we use base 10, not base 2. We think $0.03 is an exact number, but floats can’t represent 0.03 exactly.

I think the historical interpretation is also relevant. The systems that did accounting before digital computers used base 10, so the first computerized systems for accounting used base 10 also. This legacy extends to the point that mainframes often had (and I believe still have) special decimal floating point math instructions. There have been several ways to accomplish this BCD (binary coded decimal) where numbers are stored in base 10 using a 4 bit encoding. I believe this can be arbitrary precision, but don’t have any experience myself. Some hardware also has decimal32 and decimal64 floating point hardware, which is part of recent versions of the ieee754 spec[1]. Databases also often have a DECIMAL type for doing calculations on money values [2]. So I think it’s not just that laws say it should be a certain way, but also that it is important to maintain consistency between systems over time.

1: https://en.wikipedia.org/wiki/Decimal64_floating-point_forma... 2: https://dev.mysql.com/doc/refman/8.0/en/precision-math-decim...

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

#343

Post by nxobject » Wed, Sep 20, 2023, 2:17 AM UTC

themagician wrote: post #188

Shrezzing wrote: post #50

The hyperinflation example is quite interesting because: 1) If it happens, it happens rapidly, and you don't want to implement this in a hurry 2) If it happens, the global economy could well be melting down, and your financial institution will have other priorities to attend to 3) Retaining existing staff, and hiring new engineers, will be challenging at best You really don't want to be implementing this change in th…

By the time this is a problem the currency has collapsed and no one is using it anymore.

I can imagine some contractual obligation being litigated in those cases... on the other hand, maybe attorney's fees would far outstrip any sum being litigated for.

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

#344

Post by hot_gril » Wed, Sep 20, 2023, 2:20 AM UTC

blibble wrote: post #338

hot_gril wrote: post #333

Earlier quoted context omitted.

One annoyance with floating point binary is when it happens to not line up so well with floating point decimal, for example >>> 0.1 + 0.2 0.30000000000000004 which is still gonna round to 0.3, but ugh. Also, during aggregations, it's not nice how you get different answers depending on the order of operations when they shouldn't matter.

on CME they're not decimal though, they're binary fractions so floating point works fine as floating point is binary fractions

Oh right, I didn't make the obvious connection to 128.

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

#345

Post by SenHeng » Wed, Sep 20, 2023, 4:06 AM UTC

jkestner wrote: post #126

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…

I'm going through this pain right now in helping my kid with homework in rounding and discovering my internalized rules are different from what they're being taught now. EXACT same pain as yours, depending on the precision and rounding rules of your pain scale.

Less than four rounds down to zero, five and above rounds up to 10.

What has changed? Or how different were your internalised rules?

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

#346

Post by filoeleven » Wed, Sep 20, 2023, 5:52 AM UTC

hot_gril wrote: post #292

jorangreef wrote: post #290

Earlier quoted context omitted.

To represent prices that are traded fractionally.

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 other languages that can do it too, but it’s much nicer to work with when it’s built-in.

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

#347

Post by yyyk » Wed, Sep 20, 2023, 6:03 AM UTC

fer wrote: post #253

yyyk wrote: post #38

Earlier quoted context omitted.

Every financial system I've seen uses either decimal floating point or integers. Using normal float is just asking for trouble.

I've seen floats for money in production, not a financial system per se, but it moved amounts around external systems that often would include some financial ones. It worked surprisingly well given the amounts involved (anywhere from tens to thousands of EUR/USD), and when I asked about the off by +-0.01 errors every now I was told they were "not worth fighting by the customers".

Most customers may not care, but reports and automated processes likely will when a customer is 'in debt' thanks to small differences, and the tax authority in certain countries also care when the sum of the differences is large enough.

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

#348

Post by imtringued » Wed, Sep 20, 2023, 6:08 AM UTC

>This not only avoids the burden of dealing with negative numbers (such as the myriad of language-specific wraparound consequences of overflow… or underflow),

Is this supposed to be some kind of joke?

Unsigned underflow wraps around to the highest number. Meanwhile signed gives you a negative number, which tends to be properly handled by code that assumes positive numbers.

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

#349

Post by kazinator » Wed, Sep 20, 2023, 6:15 AM UTC

Merad wrote: post #248

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 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 a 0.3 cent fraction coming from the payments gateway, turn it into a customer-facing penny, thereby collecting an extra 0.7 cents.

That way, too, there would almost certainly be zero complaints and bug reports.

If the customer is supposed to pay $103.45395 every month, you could turn it into $103.46, pocketing an extra $0.00605, or into $103.45, where you're out $0.00395.

Think about it; when you eat at a restaurant, often the prices for a meal are round like $11.50, even though the restaurants expenses are down to the penny. Why is that? Because they arbitrarily set the price. They don't say, oh, our ground beef supplier charges to the penny penny, so lunch will have to be $11.57.

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

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

#350

Post by kazinator » Wed, Sep 20, 2023, 6:23 AM UTC

Merad wrote: post #298

Dylan16807 wrote: post #279

Earlier quoted context omitted.

Why was it listed separately at all? If the month's charges were 406.783228 and I get a bill for 406.79 then that seems perfectly good. If I get a bill that says 406.78, plus a separate 0.01, that's weird.

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

It's unlikely that it would be illegal, or violate the contract with the payments gateway, if you charged the customer 406.78, and you made up the $0.003228 discrepancy so the gateway is paid off.