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

31–40 of 372 posts

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

#31

Post by DamonHD »

8organicbits wrote: post #18
iamds wrote: post #9

Earlier quoted context omitted.

why add the complexity of bcd when you can just put in it units (e.g. cents) where there's no decimal point?

What do you do if heavy deflation causes the government to release a $0.001 coin? A cent isn't a fundamental unit. Edit: as another hypothetical, what if the $0.001 coin is released to support micropayment use cases?

Actually that would break so many things (the cent as the smallest unit in law and in custom where that is currently the case) that governments may by preference issue a whole new currency instead of stir that pot.

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

#32

Post by __s »

bowsamic wrote: post #10
throw0101c wrote: post #5

I was under the impression that BCD was generally recommended for money, often because of (IEEE?) rounding and machine precision/epsilon: * https://en.wikipedia.org/wiki/Binary-coded_decimal * https://en.wikipedia.org/wiki/Machine_epsilon

I've never seen anyone use floating point for money in their bespoke applications

I worked on some software in the past where I converted double to C#'s decimal type. Unfortunately it wasn't so easy on the shop's old php stuff, but there I was more concerned with fixing their SQL injection issues rather than their rounding errors

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

#33

Post by jl6 »

8organicbits wrote: post #18
iamds wrote: post #9

Earlier quoted context omitted.

why add the complexity of bcd when you can just put in it units (e.g. cents) where there's no decimal point?

What do you do if heavy deflation causes the government to release a $0.001 coin? A cent isn't a fundamental unit. Edit: as another hypothetical, what if the $0.001 coin is released to support micropayment use cases?

Worth noting that hyperdeflation has never happened, which is kind of interesting because it theoretically could.

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

#34

Post by rvnx »

DamonHD wrote: post #13
Etheryte wrote: post #3

Perhaps I'm the odd one out here, but most financial systems I've had the chance to work with don't actually use numeric types to store values, they use strings or other comparable types. Numeric values are passed to all outside interfaces, but the internal states are written in a way where no bit level issues peddle with the values. I'm wondering what the experience of the wider audience here is?

Not true for any of the finanical systems I've worked for the credit/derivatives/FI/etc desks of some of the largest investment banks down to the systems for the virtual card e-money issuer in the UK that I founded.

They use integers to store cents or fraction of cents, and that's it (or the equivalent of MySQL "DECIMAL" format if not using integers)

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

#35

Post by DamonHD »

rvnx wrote: post #30
alexvitkov wrote: post #16

Earlier quoted context omitted.

If by "bit-level issues" you mean bit flips (which you should be worried about), a string doesn't help much - "4" is 0x34 ASCII/UTF-8, flip lowest bit and you get "5" (0x35). I'd imagine if I have to protect against bit-level fuckery something like this would be a better representation: struct Dough { u64 amount; u64 amount_again; u64 amount_just_to_be_really_sure; } that and hardware-level protection of course

Storing the same element the same way isn't really helping against implementation bugs, if going that route, better store in multiple formats (u64, int, or string), to protect yourself from a CPU or interpreter or library bug. In practice, just store the amounts as integer, and if you are really worried, add a checksum (if total balance is not enough).

That pretty much guarantees being the victim of multiple coding bugs...

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

#37

Post by DamonHD »

fidotron wrote: post #26
Waterluvian wrote: post #12

Earlier quoted context omitted.

Floating point feels like an incredibly grokkable concept that was just not taught well for a long time. Maybe too mathematically (of course). Or maybe that was just my experience. I feel like any dev team should pick up a copy of this for on-boarding: https://jvns.ca/blog/2023/06/23/new-zine--how-integers-and-f...

Floating point being grokkable doesn’t make it any more suitable for this application. Floating point is inherently an approximation - your bank balance should not be an approximation.

More to the point binary fp absolutely is a bad approximation to, and does poor arithmetic on, common legal sub-1 decimal currency values, ie those that do not have an exact binary fp representation.

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

#38

Post by yyyk »

throw0101c wrote: post #5

I was under the impression that BCD was generally recommended for money, often because of (IEEE?) rounding and machine precision/epsilon: * https://en.wikipedia.org/wiki/Binary-coded_decimal * https://en.wikipedia.org/wiki/Machine_epsilon

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

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

#39

Post by alentred »

Etheryte wrote: post #3

Perhaps I'm the odd one out here, but most financial systems I've had the chance to work with don't actually use numeric types to store values, they use strings or other comparable types. Numeric values are passed to all outside interfaces, but the internal states are written in a way where no bit level issues peddle with the values. I'm wondering what the experience of the wider audience here is?

Oh, this does sound odd indeed. I can only assume this is very slow, and voluminous on the storage side.

In a similar vein, the only "tricky" solution I saw once was a financial system that stored rational numbers as fractions, and used fractions for all computations too. A decimal point was only used for the final results (end-user UI, APIs, etc.). I still think it was a an overkill.

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

#40

Post by dahfizz »

wyldfire wrote: post #21
Etheryte wrote: post #3

Perhaps I'm the odd one out here, but most financial systems I've had the chance to work with don't actually use numeric types to store values, they use strings or other comparable types. Numeric values are passed to all outside interfaces, but the internal states are written in a way where no bit level issues peddle with the values. I'm wondering what the experience of the wider audience here is?

> internal states are written in a way where no bit level issues peddle with the values ... "bit level issues"? you eventually are going to need to use those bits to add, multiply, subtract or divide the numbers. Using character strings to represent numbers is certainly one way to do arbitrary precision/ BigInteger (like the article describes). But you might want to postpone transcoding it to characters until you dec…

A shocking number of devs are simply afraid of bits and bytes.
Post reply on HN