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

151–160 of 372 posts

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

#151

Post by runeks »

halosghost wrote: post #137

A reminder that this still isn't the correct way of handling money. The correct way is to put it in the type-system [1]. All the best, -HG [1] https://web.archive.org/web/20211014094900/https://ren.zone/...

This only puts currency codes in the type system; and uses rational numbers for amounts.

This is definitely useful because you can have the type system tell you if you've implemented e.g. exchange rate conversion incorrectly. But it's also a hassle because you need to reify currency values discovered at runtime as types, which isn't pretty [1].

[1] https://github.com/runeksvendsen/order-graph/blob/eef0006cba...

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

#152

Post by RandomLensman »

cornstalks wrote: post #147
seanhunter wrote: post #125

Earlier quoted context omitted.

That is absolutely not how it works. Rounding is exactly specified in the underlying contract always and you need to implement the correct rounding. For example, here is the rounding table for compounding calculations in the ISDA definitions (these are very standard for a wide range of contracts, but this particular table is for various overnight swap rates used in interest rate derivatives)[1]. [1] https://globalmar…

And how do they round ties? Does 0.00005% round to 0.0001%? Is tie breaking usually included in such contracts?

For these benchmarks, yes, that is defined.

Where issues could come in is when these things are multiplied with a bunch of other numbers (each number with defined rounding but not after each operation) and then have some defined rounding at the end. There different computer numerics could in give slightly different results, but those can easily be resolved on settlement (for small stuff that stays well within the back offices - at least that is how I remember it).

Also, not totally unusual for one or both participants to forget about some rounding they might have agreed bilaterally if it was some one off etc.

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

#153

Post by lxgr »

GTP wrote: post #57
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,…

What would be the problem with TigerBeetle's approach to use a smaller and configurable unit of measure so that you only have to deal with integers?

The article and the comment you're responding to aren't even talking about the same thing, so it's futile to discuss the pros and cons.

The article is talking about serialized representations, i.e. how you store amounts in a database. The comment is talking about how to arrive at amounts as part of arithmetic calculations, e.g. determining interest, percentage fees etc.

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

#154

Post by [deleted] »

RamblingCTO wrote: post #118
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,…

Not sure about that. In Germany, especially SMEs, no one cares about cents. Your tax reports are done in rounded Euros anyway. People, companies, and the taxation and financial state dept. are well aware of rounding issues, different ways to round that no one really cares about cents. Besides that, using BigDecimal with two decimal places is sufficient in the java world imho. Depends on your use case. I'm entirely sc…

[deleted]

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

#155

Post by pjc50 »

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

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 there. "Division" and its close friend "multiply by noninteger number" are the only real problems, so you need to be careful not to provide a generic method and instead methods like divideWithLocaleTaxRounding(). You also need to check whether you're supposed to apply tax per-item or you can do it to the whole bill.

I think we had a "apply tax to whole bill but then re-distribute it to line items" method, which guaranteed that the total would be correct.

There are reasonable arguments for "integer decimal fraction of penny" as the correct unit. Digikey price some parts in 0.1 of a penny or cent, for example.

Attempting to convert things between binary "fractions" (floating point) and decimal fractions will result in misery.

I think we also had a "rational number" class for storing things like "1/3".

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

#156

Post by pix128 »

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?

Different currencies already have different rules. Any good accounting software isn't going to assume US cents. Update your currency table to include a version of USD in increments of $0.001. Update the amounts on a need-be basis. ( Multiply by 10 and change the currency type)

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

#157

Post by prometheus76 »

seanhunter wrote: post #125
rvnx wrote: post #53

Earlier quoted context omitted.

I had such case too, the solution is simple: round in favor of the bank / financial institution you are working for

That is absolutely not how it works. Rounding is exactly specified in the underlying contract always and you need to implement the correct rounding. For example, here is the rounding table for compounding calculations in the ISDA definitions (these are very standard for a wide range of contracts, but this particular table is for various overnight swap rates used in interest rate derivatives)[1]. [1] https://globalmar…

Interesting side note:ASME also has a standard for rounding on engineering drawings. A few years back I had to build a custom function in Excel to match the standard, because our calcs weren't matching the customer's calcs.

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

#158

Post by amadvance »

kawhah wrote: post #14
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".

Is fixed-point the right term ?

As far as I know fixed point numbers have a fixed fractional part in bits, but this is different from using integers with a multiplicative factor, like 100, to represent correctly a fractional part as 1/100.

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

#159

Post by lxgr »

SoftTalker wrote: post #131
throwaway894345 wrote: post #52

Earlier quoted context omitted.

What are the specific challenges to writing financial software? What are common mistakes you see? What are common data structures for representing money (both the common incorrect implementations but also the correct implementations)? Also, provided you have a data structure that can represent money, you should presumably be able to serialize that data structure and store or send it just like any other data, right? W…

If your database has a MONEY or CURRENCY data type, use that. Just as you should use proper DATE or DATETIME data types for time and not roll your own with strings, integers, seconds-from-epoch, or any other schemes at least if you want to keep your sanity.

> If your database has a MONEY or CURRENCY data type, use that.

But hopefully only after understanding how it treats these, and whether that's compatible with your requirements.

> Just as you should use proper DATE or DATETIME data types for time and not roll your own

I'm always happy to use the database's date/time format – if it's actually implemented in a sane way and is compatible with my data.

For example, I work with data provided by external partners that specifies dates:

Sometimes they're only specifying the year as a single-digit integer (and you have to guess which one they mean, based on the current date and the hope that the files they send you are not older than 5-10 years). Sometimes there is no year at all. Sometimes the timestamps have an implied timezone, sometimes they're UTC, and sometimes they're supposed to be UTC, but really are in some unspecified local timezone.

In these cases, it can indeed be better to store these as strings and deferring interpretation until you actually process them.

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

#160

Post by marcosdumay »

rvnx wrote: post #75
onetimeuse92304 wrote: post #60

Earlier quoted context omitted.

No, it does not work this way. Any good accountant will see a different in values, even smallest one, as a sign of an incorrect calculation. Does not matter which way it goes, they will feel compelled to figure out who is wrong. At least a good accountant will.

There is no accounting error; let's say customer has purchased / used a service for 1.433 USD. You issue an invoice for 1.44 USD (aka, amount due), then the 1.44 USD is used as a basis for accounting and is all consistent. Then, if you are a nice company and the situation applies in your case, you may issue a credit in favor of the customer for 1.44 USD - 1.433 USD that will be used as a discount on a future invoice…

You added 10 of those items as inventory with a total value of 14.33, then you sold each individually as a total value of 14.40. After that transaction, your inventory account has -0.07 on it, but there aren't any items at all there.
Post reply on HN