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

11–20 of 372 posts

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

#11

Post by dahfizz »

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?

Sounds slow as hell, what kind of financial systems have you worked with? I write trading software, and pretty much everyone uses integers with implied decimal place, similar to TFA.

How do you know you convert your internal string to a float/int correctly? You have to deal with the numeric types eventually

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

#12

Post by Waterluvian »

DamonHD wrote: post #6
Waterluvian wrote: post #2

I’m a bit surprised that these two concepts are seen together. I’d of thought that financial math and data management would always be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is. Then again, 128 bits is plenty for microcents or whatever the minimim unit is. I’m guessing back in the day when things were 32 bit or less, there were entire financial database impl…

If you actually want to do something useful and accurate and auditable and performant and space-efficient, because you have a lot of money values to bank with, you really don't want too much abstraction. My experiences in various bits of banking include where juniors ignore advice NOT to store currency in floating point values and then come whining that arithmetic is broken, and tech dudes in a lab deciding that ever…

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

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

#13

Post by DamonHD »

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.

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

#14

Post by kawhah »

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?

I have never encountered such a system. Integers used for fixed-point representation do not suffer from "bit-level issues".

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

#15

Post by dahfizz »

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

BCD is better than IEEE 754 floating point, but simple integers with an implied decimal point is much better than either of those.

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

#16

Post by alexvitkov »

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?

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

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

#17

Post by MrBuddyCasino »

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

Count yourself lucky.

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

#18

Post by 8organicbits »

iamds wrote: post #9
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

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?

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

#19

Post by dahfizz »

Waterluvian wrote: post #2

I’m a bit surprised that these two concepts are seen together. I’d of thought that financial math and data management would always be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is. Then again, 128 bits is plenty for microcents or whatever the minimim unit is. I’m guessing back in the day when things were 32 bit or less, there were entire financial database impl…

> be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is.

This still doesn't do that, its just integer math. It doesn't matter how your CPU implements it, as long as `x = a + b` gives the correct value for x.

You don't have to immediately reach for an abstraction layer when you hear the word "bits" ;)

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

#20

Post by atemerev »

iamds wrote: post #9
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

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

Division. 1/x is a common operation in finance (particularly in trading), and you'll get all sorts of trouble if you try to express everything in cents.

So, you'll need subpenny fractions (e.g. 8 decimal points), or BigDecimal, or decimal-normalized floats.

Post reply on HN