An argument over fractional pennies costs full dollars of peoples' time.
- Anonymous
64-bit bank balances ‘ought to be enough for anybody’?
91–100 of 372 posts
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#92Earlier quoted context omitted.
Wouldn't we just re-base the currency at that point?
That “just” is doing some very heavy lifting. That could potentially involve having to update almost every financial system worldwide given the US dollar’s position as a global reserve currency.
I love how you're bringing the US dollar's reserve currency status into a hypothetical where the US Treasury is issuing million dollar denominations. We can assume that some other parts of the world's financial system will have required fixing first.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#93Earlier 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…
> I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still. Your setup made it sound like something crazy and inane, like "the PDF printer used on those machines changed floating point rounding modes" or what have you.
In olden times we would "print to PDF" as in have a little piece of code to format the document that would be sent to a printer which could be a PDF document.
In this particular case we had two separate pieces of code, one running on the client (for on screen presentation) and one on the backend (to create the PDF on a shared location and produce a download URL).
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#94Earlier quoted context omitted.
Oh, sure, because when you are a small company you don't care that people get correct invoices. I can certainly sympathise with this stance. There is about a billion things you can do better but you have limited time to do anything so you have to prioritise. And if one invoice in ten thousand is incorrect by one cent, and only one client in ten thousand who received the wrong invoice will actually find it out, then i…
For simple accounting I've always used integers and done all operations in cents, only converting on the frontend. what's my downside here? I guess it wouldn't support unit prices less than a penny
Also many types of operations could give you the wrong result from incorrect rounding. E.g. let's say you're calculating 10% of $1.01 ten times and adding the result together. The correct result is $1.01, but with your method you will get $1.00.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#95ETH uses 256-bit integers for accounting.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#96I 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?
Decimal float has a larger range and a more natural representation when debugging than fixed point. Either way works well though.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#97Earlier quoted context omitted.
> Floating point is inherently an approximation - your bank balance should not be an approximation. I think this is a perfect example of bad floating point teaching. Floating point is not an approximation in any sense. If the numerical result of your calculation is representable in floating point you will get an exact answer always. And for results that aren't representable you decide exactly what should be done abou…
In programming, an `int` perfectly represents the integers between INT_MIN and INT_MAX. A `float` on the other hand, approximates the real numbers. It can perfectly represent exactly 0% of them. Having control over the rounding behavior is meaningless - floats cannot correctly represent any non-contrived calculation. Exact representation is important in financial systems.
TBF, be careful here. The IEEE floats can represent a subset of integers in their range exactly. For example, 64 bit floats can represent the range of 32 bit ints accurately (and more).
That said, it is bizarre to claim that if the result can be represented you get the exact result, when the core problem is that the result cannot be represented because the representation is an approximation.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#98Earlier 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).
I think what OP's talking about aren't sw bugs, but rather hw errors like a bit flip caused by an external interference.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#99Specialising 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,…
Rounding monetary values is a complex, opinionated and business-defined operation. Sometimes it's even orthogonal to the datatype used.
Things get out of hand when you need to round multiple different things that have to sum up at the end.
For example:
- Items in an invoice are rounded and summed. (eg. $1.1234 * 5.678kg)
- Payments of an invoice can be paid in multiple installments, with interests that are also rounded (eg. 1.77% per month).
- The value paid of interest *per item* must match the total value paid of interest in all installments of all invoices in the same period.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#100Specialising 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,…
Serialization as a byte string ought be good enough if the storage layer doesn't support arbitrary precision natively.