Support more arithmetic in amount entry

[davidheijkamp]

As far as I'm aware it is only possible to calculate the amount of a posting based on the sum of multiple numbers. I'd like to suggest an enhancement: it would be superuseful for me - and I guess others as well - to be able to quickly calculate the amount of a posting by multiplying.

My usecase is this: some of the invoices I need to book only provide a subtotal amount for specific invoice items excluding VAT. I'm not working for an organization that has a VAT-status so I need to book these items including VAT. If I would be able to add these by simply entering 50*1.21 (Dutch VAT is 21%), that would speed up data entry considerably.

If this is already possible, I'd like to know how of course. (I'm running hledger-iadd version 1.3.5 and hledger version 1.10). Thanks for considering.

[hpdeifel]

Sure, good idea. It shouldn't be too hard to add the rest of basic arithmetic.

[hpdeifel]

It shouldn't be too hard

Yeah well... we currently let hledger parse the amounts and with the way the parser works and the existence of default commodities it's really hard to distinguish amounts from plain numbers.

Multiplying amounts by amounts doesn't make sense either (or else you'd get €²), but that's what I implemented now in the hope that nobody will notice.

Could you please try the features/amount-arith branch to see if it works for you?

[simonmichael]

A possibly related WIP hledger PR: simonmichael/hledger#871 (comment)

[davidheijkamp]

Sorry for the delayed reply, I missed the Github notification. I've just built the feature branch and tested multiplication.

Works exactly as expected:

• Multiplying without commodity: 2 * 1.21 = 2.42
• Multiplying with commodity at the start: € 2 * 1.21 = € 2.42
• Multiplying with commodity before first and second amount: € 2 * € 1.21 = € 2.42
• Multiplying different commidities: € 2 * $ 1.21: Cannot multiply two amounts with different commodity

So, I can't reproduce the behavior you mentioned above, but that's a good thing I would say :)

Let me know if I you need more testing. For now: thanks a lot, you've made me a even happier bookkeeper!

[simonmichael]

Nice!

We might get similar functionality into hledger core at some point. Use cases, like the one you gave, are helpful. Here's some syntax sugar for percentages I was thinking about:

• In a multiplication or division, 21% is equivalent to 0.21
• +21% is equivalent to LEFTSIDE * 1.21 (and similar for minus)

[hpdeifel]

* Multiplying with commodity before first and second amount: `€ 2 * € 1.21 = € 2.42`

Yes, that's what I meant. This should be a syntax error, but that's hard to do in the presence of default commodities.

Let me know if I you need more testing. For now: thanks a lot, you've made me a even happier bookkeeper!

Great to hear that it works for you!

I'm still not sure whether I should merge this. On the one hand it solves a real problem now, on the other hand, it's implemented as a hack and I would rather wait for proper multiplication support in hledger-lib.

[hpdeifel]

* `+21%` is equivalent to LEFTSIDE * 1.21 (and similar for minus)

How would associativity and commutativity work in this case? E.g what would 5 + 5 + 50%, 5 + 25%*2 or 2*5 + 50% be?

[simonmichael]

How would associativity and commutativity work in this case? E.g what would 5 + 5 + 50%, 5 + 25%*2 or 2*5 + 50% be?

I was thinking it would operate on "the left operand, following usual precedence rules" HAND WAVE. Probably it isn't worth the trouble.

[gour]

Good idea to provide basic arithmetic!!

When I'm buying things in some shop I do divide total amount in few categories - e.g. food, cosmetic, gifts, misc etc. and then after summing some category I substract the rest from total amount as well as multiplying items in the same category...

[allgreed]

@hpdeifel Hi, absolutely love the idea - my use case is sharing expenses with other people, so amount / n where n is the number of people and 2 is most common, so I could reasonably do amount * 0.5 for now. Is there anything I could do to help to get it merged?

IMO 2 COM * 3 COM = 6 COM where COM is some commodity is acceptable in the domain of finance, especially given that default commodity kerfuffle. I just don't see how someone might accidentally directly input 2 COM * 3 COM and have a problem that:

• the result computes
• result isn't 6 COM^2 I mean... euro squared? cow squared? even if someone has a long metal slab and uses parts of it (like 5 inches) as a means of exchange - then inch squared wouldn't make much sense either (as opposed to directly inputted square inch to denote a piece of something that is actually divided by an area)

[Harliff]

Please add "+" operator too.
Sometimes it is useful to sum multiple expenses in single category.

[hpdeifel]

Please add "+" operator too. Sometimes it is useful to sum multiple expenses in single category.

Addition already works.