5 ms·
>Surprisingly, we also don’t use negative numbers (you may have encountered software ledgers that store only a single positive/negative balance). Instead, we ke
by tech_ken 3y ago
>Surprisingly, we also don’t use negative numbers (you may have encountered software ledgers that store only a single positive/negative balance). Instead, we keep two separate strictly positive integer amounts: one for debits and another for credits.
It's funny I've always thought of two-column bookkeeping as a kludge that was invented because the author was unaware of negative numbers. But here there's actually a justifiable technical reason why they're superior (in this specific context)! History is a silly thing
- Jabrov 3y agoHow are they superior though? What do they gain by doing this (other than added complexity)?
- jorangreef 3y agoHey! Joran from TigerBeetle here. (I know this only because I somehow happened to major in Accounting back in university), but when you represent a general ledger of accounts, there are always two positive columns for amounts in any given account, one for debits, the other for credits. The golden rule is that you always add to either column. You always preserve information. To see why two columns (or two integer balances) preserves more information, take this example: 1. An account A with a debit balance of $1m and a credit balance of $1m, and 2. An account B with a debit balance of $0 and a credit balance of $0. Account A contains volume information in that you can immediately see not only that account A was transacted against, but with significant amounts. Conversely, account B shows no volume. But it's also clear even that there were no transactions between A or B. Whereas, if you take the net of the two amounts, and reduce that to a single amount in storage (as opposed to only taking the net in presentation), and if you use negative numbers, you lose this information. It's a subtle thing. The other angle here, is to consider why some engineers shortcut to negative numbers in the first place. I find that it's usually because they haven't fully grokked that accounting is itself a type system. You get assets, liabilities, equity, income and expenses (as account types), and the debit/credit balances, when considering the type of an account, tell you further information. For example, did a bank account suddenly transition into overdraft? Different account types, increase on different sides. I think this is also the reason that you find accountants typically wrapping amounts in parentheses, and then specifying the DR or CR side (or type of account), rather than using a negative sign. It's a tradition of preserving information.
- munificent 3y ago> You always preserve information. Using two positive numbers preserves some information, but still destroys plenty. Just less than a single signed number would. Consider two accounts: 1. An account A with a debit balance of $1m and a credit balance of $0, and 2. An account B with a debit balance of $1m and a credit balance of $0. One of those was opened by a lottery winner last week who did a single transaction dropping in their winnings. The other was opened by a retiree 60 years ago who has been dripping small deposits in for their entire working history. Which is which? That distinction is still lost by summing debits and summit credits. To really preserve information, you'd need the full list of all transactions. But, obviously, that comes at a significant performance cost. So the way to look at storing sums for debits and credits is that it's a trade-off which gives you a little more information than just a single balance but is still a relatively small fixed-size amount of data.
- jorangreef 3y ago> You always preserve information. This is the principle. Not to suggest that the sum of debits and credits alone is sufficient to that end, but rather to explain why it's at least necessary. > To really preserve information, you'd need the full list of all transactions. Exactly. And so this is, of course, what TigerBeetle also does (with full durability). And, at the same time, TigerBeetle doesn't decompose account balances to a single integer, for the reasons given. Both of these are important. To be clear, the context for this thread is the latter: Why not decompose account balances to a single positive/negative integer?
- fragmede 3y agoAccounting for computer scientists* is a good read if you've got some interesting in accounting (and have a CS background) and are wondering why accounting is just so danged complex. * https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
- tech_ken 3y agoOh I'm familiar B) Used to use this CLI tool "ledger" to keep the books for a small nonprofit I was treasurer-ing for. Awesome tool, and (in conjunction with this read and a few others) it taught me a ton about all that good GAAP stuff
- thetwentyone 3y agoReference for the "justifiable technical reason"?
- tech_ken 3y agoI'm referring to the OP which discussed the technical justification for their choice. An employee from the firm also elaborated a little more elsewhere in the replies
- LAC-Tech 3y agoThis is also the way to do it if you want a number that multiple nodes can edit independently. When you sync back up, do a big tally at the end, and that's your final number. (This constitutes a CRDT, and is known as the Positive/Negative Counter).
- tech_ken 3y agoThe idea is similar/equivalent to a stack of git deltas yeah? Each line is a change of one of two types and then you combine them to get a net change?
- LAC-Tech 3y agoI'm actually not too familiar with git deltas, but that does sound very similar to an Observed/Removed Set, another CRDT.