WIP: Signed costs

[tanelihuuskonen]

I have a feature request that might be somewhat idiosyncratic, so I'm prepared to do most of the work myself, mainly asking for feedback and guidance.
My brain insists that the total cost or price of a lot is really a signed quantity (positive when you buy, negative when you sell), just like Ledger does internally. I'd like to have command-line switches to expose the internal sign of a total cost, separately for input and output to let you easily transform a journal from one format to the other either way. Here's my proposal for the output switch, which seems to be more straightforward than the input one. It worked as expected when I ran a couple of simple tests. I'll be happy to write some proper automated tests, document the new feature, and do whatever else is needed, but I'd like to first know if I'm going in the right direction at all.

[tbm]

What's the point of this PR?

There are reasons ledger works the way it does and I don't see why adding this increased complexity would be useful.

Personally, I feel the solution here is for your brain to get adjusted to how ledger works.

Everything after @ is a price... a price is always positive. If I buy 1 thing for 10 EUR, it's 1 THING @ 10 EUR. If I return one thing and get a refund, the price doesn't change to -10 even though I get 10 back. The price is still positive 10. But I return it, so the quantity is -1: -1 THING @ 10 EUR.

Does that make sense?

[tanelihuuskonen]

I understand you're saying that whatever follows @ (the unit price) is always positive. I get that, and I'm not arguing otherwise. If I trade n THINGs at 10 EUR a piece, then it's n THING @ 10 EUR, regardless of how much I'm trading and whether I'm buying or selling. What I don't understand is how you get to the conclusion that whatever follows @@ (the total price) should also be positive. If 1 THING is worth 10 EUR, then 2 THINGs are worth 20 EUR, 10 THINGs are worth 100 EUR, and generally n THINGs are worth 10n EUR, regardless of n. In particular, -1 THING would be worth -10 EUR, -2 THINGs worth -20 EUR and so on. However, when n is negative, then for some reason the UI of ledger pretends that n THINGs are worth -10n EUR instead, swapping the sign of the internally stored negative post->cost on input and output. I still have no idea why.
Perhaps the following example will help you understand where I'm coming from. Imagine you're hired to make an enhanced version of ledger. Your boss gives you a list of shiny bells and whistles they want you to implement. One of the requirements concerns the internal functioning of the program: you should always store a positive number in post->cost, because "a price is always positive", and check the sign of post->amount whenever you use post->cost to know whether you should add or subtract it. I presume you'd find that kind of requirement pointless and very annoying, even though it wouldn't be a whole lot of work; I know I would. I feel pretty much the same about having to adjust to the way ledger does total prices: it's not difficult or tedious to do so, but it annoys me because I don't see the point. However, I'm happy to agree to disagree. It's actually less work to patch my own copy of ledger to do what I want without any command-line switches. Judging by the lack of comments so far, it looks like nobody's interested in my proposal anyway.

[tbm]

What I don't understand is how you get to the conclusion that whatever follows @@ (the total price) should also be positive.

It's a price. Have you ever gone into a shop and seen a negative price?

If you return an item, you get back money, but the price is still positive. You're getting a refund of a positive price.

You buy a t-shirt for $10. You spend $10. The price is $10.

You return the t-shirt, You get back $10 (expenses is -$10 in ledger). But the price is still +$10.

[tanelihuuskonen]

I'm sorry, I still don't see why the actual sign of a price should matter at all. By definition, gross income is positive, but normally all the amounts posted to an income account are negative. In the case of income, everyone seems to be happy to disregard the actual positive sign and use negative numbers because that's how the math works. I really don't see why one should treat prices any differently from income in that respect. In fact, if ledger also flipped the sign of all entries on income accounts (and perhaps something else I can't think of off the top of my head), I'd at least find its behavior consistent and understand the reasoning behind it, even though I still wouldn't agree.
Anyway, I suggest we agree to disagree. As I wrote earlier, I'll simply close this PR due to lack of interest and patch my own copy of the program to work the way I want, reapplying the patch whenever I switch to an updated version.