I find the “no negatives” very confusing even in a double entry ledger for reasons the last sentence of that paragraph hints at:
> When you need to take the net balance, the two balances can be subtracted accordingly and the net displayed as a single positive or negative number.
This means you have to reconcile credits and debits using a different type than each of the columns is in. Not a huge deal by itself, but now that secondary type has to be a weird 129 bit integer (or larger) to ensure it can represent every intermediate sum of credits and debits.
If they just would have sacrificed 1 bit they could have used a single signed 128 bit data type for all storage and computation.
I suspect they have to enforce the “all debits and credits are positive” invariant in a number of places anyway (or risk coercing a negative signed 128 input into an unsigned 128 but ledger entry), so why not sacrifice a bit that will probably never be used otherwise anyway and have a uniform structure for numeric types?
Using a single signed 128-bit integer does not solve this. What happens when you have to add two of these together? Do you need a 129-bit signed integer? What about if you need to add 64 of these together; do you need a 134-bit signed integer? The point is that 128 bits is well large enough to hold the sum of quadrillions of transactions in Zimbabwean dollars. Nobody is switching to a 129-bit number to hold the results of sums; they are explicitly not handling the case where any account is anywhere close to 10^38 of the base unit.
> When you need to take the net balance, the two balances can be subtracted accordingly and the net displayed as a single positive or negative number.
This means you have to reconcile credits and debits using a different type than each of the columns is in. Not a huge deal by itself, but now that secondary type has to be a weird 129 bit integer (or larger) to ensure it can represent every intermediate sum of credits and debits.
If they just would have sacrificed 1 bit they could have used a single signed 128 bit data type for all storage and computation.
I suspect they have to enforce the “all debits and credits are positive” invariant in a number of places anyway (or risk coercing a negative signed 128 input into an unsigned 128 but ledger entry), so why not sacrifice a bit that will probably never be used otherwise anyway and have a uniform structure for numeric types?