4 ms·

Negative numbers are a hack in the sense that they can be confusing, and it's easy to make mistakes with them. For example, I would interpret "-100 L/min outflo

by jltsiren 10mo ago

Negative numbers are a hack in the sense that they can be confusing, and it's easy to make mistakes with them. For example, I would interpret "-100 L/min outflow" as an indirect equivalent of "100 L/min inflow". To avoid confusion, you could drop terms "inflow" and "outflow" completely and talk about "-100 L/min (net) flow". Or you could separate the type and the magnitude of the flow.

dagss 10mo ago
There's a difference between UI and code. In code, it is more complicated to do if (change.direction == OUT) { total -= change.value } else { total += change.value } than to simply use negative numbers and do total += change The same in accounting, it can in my experience often be convenient that your Entry database tables look like account amount --- --- income/sales -100 receivables +100 rather than account debit credit --- --- --- income/sales 100 receivables 100 The first one is just simpler, and you also get the nice graph properties (cuts, zero-sums, etc) discussed in the OP. Simpler database model, simpler code, less cases to test, easier to do ad hoc analysis queries, etc. Of course in the UI one can simply flip signs on credit-normal accounts to avoid displaying negative numbers if one wishes.
- jltsiren 10mo ago
  Negative numbers are probably convenient, if your background is in a field, where numerical calculations are the norm. Traditional accounting is better justified from a mathematical perspective, as mathematics is more about definitions than calculations. There are usually multiple levels of abstraction in code. When choosing the one to use for a particular task, it's a good idea to prioritize both simplicity and conceptual clarity. Bad things often happen, when the two priorities disagree. And you should try to use the same terminology and same concepts as the user as much as reasonably possible. Otherwise it's easy to make wrong choices by thinking about the problem from a wrong perspective.

dagss 10mo ago

There's a difference between UI and code. In code, it is more complicated to do if (change.direction == OUT) { total -= change.value } else { total += change.value } than to simply use negative numbers and do total += change The same in accounting, it can in my experience often be convenient that your Entry database tables look like account amount --- --- income/sales -100 receivables +100 rather than account debit credit --- --- --- income/sales 100 receivables 100 The first one is just simpler, and you also get the nice graph properties (cuts, zero-sums, etc) discussed in the OP. Simpler database model, simpler code, less cases to test, easier to do ad hoc analysis queries, etc. Of course in the UI one can simply flip signs on credit-normal accounts to avoid displaying negative numbers if one wishes.

jltsiren 10mo ago
Negative numbers are probably convenient, if your background is in a field, where numerical calculations are the norm. Traditional accounting is better justified from a mathematical perspective, as mathematics is more about definitions than calculations. There are usually multiple levels of abstraction in code. When choosing the one to use for a particular task, it's a good idea to prioritize both simplicity and conceptual clarity. Bad things often happen, when the two priorities disagree. And you should try to use the same terminology and same concepts as the user as much as reasonably possible. Otherwise it's easy to make wrong choices by thinking about the problem from a wrong perspective.