| *** mlncn has quit IRC | 00:03 | |
| *** bkuhn is now known as bkuhnIdle | 01:28 | |
| *** bkuhnIdle is now known as bkuhn | 02:16 | |
| *** tgnit has quit IRC | 03:17 | |
| *** mlncn has joined #npoacct | 03:30 | |
| *** tgnitidle has quit IRC | 03:30 | |
| *** mlncn has quit IRC | 03:40 | |
| *** mlncn has joined #npoacct | 03:50 | |
| *** tgnit has joined #npoacct | 03:50 | |
| *** mlncn has quit IRC | 04:11 | |
| *** paroneayea has quit IRC | 07:25 | |
| *** garrison has quit IRC | 08:05 | |
| *** tbm has quit IRC | 10:16 | |
| *** ChanServ has quit IRC | 10:16 | |
| *** scott_gonzalez has quit IRC | 10:17 | |
| *** tgnit has quit IRC | 10:17 | |
| *** mlinksva has quit IRC | 10:17 | |
| *** joar has quit IRC | 10:17 | |
| *** tgnit has joined #npoacct | 10:21 | |
| *** tbm has joined #npoacct | 10:21 | |
| *** mlinksva has joined #npoacct | 10:21 | |
| *** joar has joined #npoacct | 10:21 | |
| *** ChanServ has joined #npoacct | 10:21 | |
| *** scott_gonzalez has joined #npoacct | 10:21 | |
| *** dickson.freenode.net sets mode: +oo joar ChanServ | 10:21 | |
| *** nesciens has joined #npoacct | 12:49 | |
| *** mlncn has joined #npoacct | 13:39 | |
| *** mlncn has quit IRC | 13:56 | |
| *** mlncn has joined #npoacct | 14:24 | |
| *** bkuhn has joined #npoacct | 14:45 | |
| *** tgnitt has joined #npoacct | 15:31 | |
| tgnitt | yesterday we discussed earlier abount rounding problems in accounting, | 15:33 |
|---|---|---|
| tgnitt | many of which does not occur in ledger | 15:33 |
| tgnitt | But there are some desirable improvements that can be made, as described in the post on ledger-cli group by Martin https://groups.google.com/forum/#!topic/ledger-cli/EYhx03B4XqY/discussion | 15:34 |
| tgnitt | If an accountant truncates the totals of individual accounts and produces a different result.the ledger here will be off by few cents practically but as the statement grows, the difference will grow too. ledger produces correct result but it is not the desired result. The transactions were truncated before calculations whereas ledger rounds only the displayed results. Also the rounding method usually adopted is the bankers roundin | 15:34 |
| tgnitt | There are two things that are needed. a. Control over reporting precision via command line or directive and b. Setting rounding mode or truncation mode for the amounts which are above the required display precision. | 15:35 |
| bkuhn | That sounds interesting to me. | 15:35 |
| tgnitt | This is important because sometimes people adopt different practices to make financial statements and truncation is an important operation. | 15:35 |
| bkuhn | tbm: does this fit with what we were talking about yesterday? | 15:35 |
| tgnitt | As I have already mentioned that ledger does not have many of the rounding problems, truncation knowingly introduce to truncation error to match other financial statements. Ledger is a multi-purpose accounting program so it probably does not focus financial accounting needs alone. | 15:35 |
| tgnitt | first step should be to take control of display precision. The displayed amounts must be increased or decreased to desired precision irrespective of how the amounts were written in journals. By providing a command line option we will ensure that default behavior of ledger does not change. When this option is used it should use correct rounding to adjust the amount like it does now. | 15:36 |
| tgnitt | Currently provided directive to format reporting of a commodity does not overrule display amount and the higher precision of the two is adopted. A new directive can be added here to. | 15:37 |
| tgnitt | With this switch we can provide a rounding mode switch but this is a difficult one. It may require significant changes but a lighter option is to add a filter to truncate or use a custom rounding mode. This filter will be applied prior to calculations uniformly to the posts. But this may violates the principle of balancing the transaction and corner cases need to be discussed. | 15:37 |
| bkuhn | This makes sense to me, but I'm curious tbm's view too. :) | 15:37 |
| tgnitt | bkuhn: me too . | 15:37 |
| bkuhn | He may not be online yet. | 15:37 |
| bkuhn | I expect he'll be here soon. | 15:37 |
| tbm | I'm not sure why D should reduce the precision you see. Is there a use case for this? | 15:38 |
| bkuhn | and he's here (!) | 15:38 |
| bkuhn | :) | 15:38 |
| tbm | I can see an argument for D increasing the precision (as it does now), but I'm not sure about reducing it | 15:38 |
| tgnitt | I had seen it earlier , suppose you have amounts reporting upto 8 decimal places but as a standard you want to calculate to two decimal places. | 15:39 |
| bkuhn | tbm: I think I'm ok with it, but it may introduce regressions for some people. We should discuss it on the ledger-cli mailing list before proposing an actual change. | 15:40 |
| tgnitt | report the results with two decimal places. | 15:40 |
| bkuhn | The documentation for D says nothing about rounding, FWIW. | 15:40 |
| tbm | D is just about _display_ precision. It's not about rounding | 15:40 |
| bkuhn | Right. | 15:40 |
| bkuhn | But, tbm, the problem is that display precision is "the precision" for most purposes. That's what the reports use | 15:41 |
| tbm | I think in this example, they should specify rounding to 2 decimals | 15:41 |
| tgnitt | I know current ly rounding is not controlled by any option. | 15:41 |
| bkuhn | But I may be biased by my personal use cases: I never end up showing our auditors the raw ledger data: just the reports | 15:41 |
| tbm | why not start with the thing that everyone seems to agree on: some directive for the "commodity directive" | 15:41 |
| tbm | so you can say something like | 15:41 |
| tbm | commodity USD | 15:41 |
| tbm | precision 2 | 15:42 |
| tbm | or whatever | 15:42 |
| tbm | let's try to solve the problem in https://groups.google.com/forum/#!topic/ledger-cli/EYhx03B4XqY/discussion | 15:43 |
| tbm | since that's an easy one | 15:43 |
| tbm | 2012-01-01 * | 15:43 |
| tbm | A 1 AAA @@ 10.00 EUR | 15:43 |
| tbm | A 1 BBB @@ 20.00 EUR | 15:43 |
| tbm | C | 15:43 |
| tbm | P 2012-07-01 AAA 10.123 EUR | 15:43 |
| tbm | P 2012-07-01 BBB 20.123 EUR | 15:43 |
| tbm | so ledger will do: 10.123 + 20.123 = 30.246 | 15:44 |
| tbm | and since D is 1000.00 EUR, it will show 30.25 | 15:44 |
| tbm | whereas I want 30.24 | 15:44 |
| tbm | if we had something like | 15:44 |
| tbm | commodity EUR | 15:44 |
| tbm | precision 2 | 15:44 |
| tbm | ledger should do: | 15:45 |
| tbm | 1 AAA is 10.123 EUR == 10.12 EUR | 15:45 |
| tbm | 1 BBB is 20.123 EUR == 20.12 EUR | 15:45 |
| tbm | and the result is 30.24 EUR | 15:45 |
| tbm | the commodity directive can be added in textual.cc: see instance_t::commodity_directive | 15:45 |
| tbm | and johnw mentioned some filter tgnitt could implement. Do you know how? | 15:46 |
| tgnitt | tbm: should not this directive try to solve the current problem. According to documentation , ledger observes certain things such as amounts to set display precisioin. Results are rounded according to this precision. D directive also increases this precision and there is no command line option to do this. | 15:46 |
| tgnitt | tbm: let us consider display precision and rounding problem separately for a minute. | 15:47 |
| tbm | tgnitt: what I'm talking about is rounding, right? | 15:47 |
| *** paroneayea has joined #npoacct | 15:48 | |
| tgnitt | supppose we add a directive which forcefully set this display precision. Then after this default thing what ledger do is correct rounding. | 15:48 |
| tbm | by default, ledger keeps all precision, and I don't want that. I want it to round to 2 digits all the time. | 15:48 |
| tgnitt | tbm: this is what the second part of the function. | 15:49 |
| tgnitt | tbm: johnw said the without changing the overall structure of ledger for this, a filter should be added so that it truncates or round according to the set precision before calculations. | 15:50 |
| tgnitt | If you want ledger should not store this, it will mean it should not use the rational number representation | 15:51 |
| tgnitt | which is a strong point of ledger. | 15:51 |
| bkuhn | tbm: why do you think we *need* ledger to round/truncate after each calculation? | 15:53 |
| tgnitt | Now what if we add a filter? if we knowingly round or truncate each amount it will add some truncation or rounding error which I want to find out, | 15:53 |
| bkuhn | tgnitt: I am not sure I understood that last point. | 15:53 |
| bkuhn | (the part about "if we knowingly round .. want to find out" | 15:53 |
| bkuhn | ) | 15:53 |
| tgnitt | I am looking for an example to know whether it can affect balancing of transaction if we round or truncate before calculations. | 15:55 |
| bkuhn | ah, I see. | 15:55 |
| bkuhn | tbm: you and I were talking about the balancing issue yesterday. | 15:55 |
| tbm | bkuhn: well, because this is how it's done in real world | 15:55 |
| tbm | bkuhn: when do you get half a cent? it's always rounded | 15:55 |
| bkuhn | tbm: well, banks do that. | 15:56 |
| bkuhn | I agree. | 15:56 |
| * bkuhn starts wondering if we need different rounding rules for the type of account. :) | 15:56 | |
| tbm | bkuhn: that's what johnw suggested. A directive based on commodity, but also for accounts | 15:56 |
| tbm | I'm not sure we need the latter but maybe there's a use case | 15:57 |
| tgnitt | tbm: does broker or accountants truncate before calculations ? | 15:57 |
| bkuhn | I suspect we don't actually KNOW the answer to that. | 15:57 |
| bkuhn | In fact, I suspect accountants just don't worry about it. | 15:57 |
| bkuhn | My discussions with them is that they just don't care about rounding because it's "immaterial" | 15:57 |
| tbm | well, let's take my example above | 15:57 |
| tbm | you have 1 AAA and: | 15:57 |
| tbm | P 2012-07-01 AAA 10.123 EUR | 15:57 |
| tbm | I doubt anyone would say this is worth 10.123 EUR | 15:58 |
| tbm | I'm prety sure most people would say it's worth 10.12 EUR | 15:58 |
| tbm | so I'd like ledger to truncate/round to 2 digits | 15:58 |
| tbm | internally | 15:58 |
| bkuhn | Ok, so I'm not grokking this. | 15:58 |
| bkuhn | Are you saying that when you buy a bunch of AAA in succession | 15:59 |
| bkuhn | you want each one worth 10.12, not 10.123? | 15:59 |
| tbm | re tgnitt: "If you want ledger should not store this, it will mean it should not use the rational number representation" | 15:59 |
| tbm | no, the way ledger stores things internally is fine | 15:59 |
| bkuhn | So, then I'm missing something you're trying to say. :) | 15:59 |
| tbm | but when it sees P 2012-07-01 AAA 10.123 EUR and I specify rounding 2, it should round/truncate before storing | 15:59 |
| bkuhn | I apologize if I'm being dense. | 15:59 |
| tbm | bkuhn: no | 16:00 |
| bkuhn | oh, hm, I think I'm starting to understand what you're saying, tbm. | 16:00 |
| * bkuhn considers whether this is a good idea. | 16:00 | |
| tbm | you have to differentiate between the exchange rate specified with P | 16:00 |
| tbm | that should have whatever precision it has | 16:00 |
| tbm | if I have 1 AAA and the pricedb says that 1 AAA == 10.123 EUR | 16:00 |
| tgnitt | tbm: I want to know what if you 1000 AAA @ 10.123 EUR ? do you calculate it @10.12 EUR or round after it? | 16:01 |
| tbm | then how much is it worth? | 16:01 |
| tbm | well, it's only worth 10.12 EUR because I cannot have 0.003 EUR | 16:01 |
| tbm | so at this point ledger should round/truncate | 16:01 |
| tbm | but of course, if I have 2 AAA at 10.123 EUR, then it should be 20.25 and not 20.24 | 16:01 |
| tbm | 2 * 10.123 = 20.246 | 16:01 |
| tbm | rounded 2 precisions => 20.25 | 16:01 |
| bkuhn | tbm: Actually, I think the root of your point is regarding mixing extra precision between commodity. | 16:02 |
| tbm | 1000 AAA you'd have 10123.00 | 16:02 |
| bkuhn | That's why it bothers you. | 16:02 |
| tbm | bkuhn: no | 16:02 |
| bkuhn | are you sure. | 16:02 |
| tbm | bkuhn: shares can have lots of precision | 16:02 |
| tgnitt | tbm: what you are saying is achievable by adding a filter , the point is that we should add a command line option as well as directive for this. | 16:02 |
| tbm | but in real life, when you buy/sell something, it's rounded to 2 digits | 16:02 |
| tbm | same with your currency rates, btw | 16:02 |
| bkuhn | oh, ok. | 16:02 |
| bkuhn | I'm starting to get what you are saying. | 16:03 |
| tbm | bkuhn: let me take an example | 16:03 |
| bkuhn | (but keep going, I'm slowly getting there) | 16:03 |
| tbm | from conservancy ledger: | 16:03 |
| tbm | Accrued:Accounts Receivable:Conservancy €23.43 {=$1.3639} | 16:03 |
| tbm | so the eur to $ exchange rate is 1.3639 | 16:03 |
| tbm | but what does that mean in practice? | 16:03 |
| tbm | when you have 1 EUR, how many $ will you get? | 16:03 |
| tbm | you won't get $1.3639 | 16:03 |
| tbm | you'll get $1.36 | 16:04 |
| bkuhn | tgnitt: I probably agree with you, *but* we also have to able to explain WHY we're adding this filter -- which is why I'm digging deep here to understand tbm. | 16:04 |
| tbm | however, if you have 1000 EUR, the precision of the exchange rte matters: 1000 * 1.3639 = 1363.90 | 16:04 |
| bkuhn | tbm: Ok, you've convinced me. | 16:04 |
| tbm | so there's a good argumnt for pricedb entries to be very precise | 16:04 |
| tbm | but once we convert some value to another value, we have to round | 16:04 |
| tbm | so, back to the example: | 16:05 |
| tbm | if I have 1 EUR and the exchange rate is 1.3639, I do NOT want ledger to store 1.3639 internally - it should just round/truncate and store 1.36 | 16:05 |
| bkuhn | Yeah, this goes back to my thinking of types of accounts. | 16:05 |
| bkuhn | so | 16:05 |
| tbm | do even if I set display_precision D $1000.0000, I still want to see $1.36000 | 16:06 |
| bkuhn | tbm: If I just accrued a bunch of stuff... | 16:06 |
| tbm | and not $1.3639 | 16:06 |
| tgnitt | tbm: so you want this post calculations , right ? | 16:06 |
| bkuhn | .... I want to accruals to propagate the precision. | 16:06 |
| tbm | tgnitt: yes | 16:06 |
| tgnitt | bkuhn: me too trying to get his point . | 16:06 |
| bkuhn | tbm: but, you mean post calculations per transaction. | 16:06 |
| bkuhn | because once you balance the transaction, you want rounding propagated forward. | 16:06 |
| tbm | bkuhn: no, you don't want to propagate the precision. | 16:06 |
| tbm | if I understand correctly | 16:07 |
| bkuhn | er, rather let me state that better | 16:07 |
| bkuhn | In a given transaction, we finish calculations with all appropriate precision . | 16:07 |
| bkuhn | Then, do rounding on both sides at the end when we're sure it balances. | 16:07 |
| bkuhn | tbm: is that what you're suggesting? | 16:07 |
| bkuhn | If so, my worry about that is this: | 16:08 |
| bkuhn | For bank accounts, sure. | 16:08 |
| bkuhn | I expect the rounding, that's what the bank will do and I want the transaction to match the statement number | 16:08 |
| tgnitt | tbm: lets say after calculations , you first convert to floating point in accordance with the displayed amount. Round it and convert it back to rational . To do per calculation? | 16:08 |
| bkuhn | But, if I am accruing a bunch of money in EUR for someone. | 16:08 |
| bkuhn | I actually want the precision propagated across their transactions. | 16:08 |
| bkuhn | tbm: because, to use my example from Conservancy's ledger: | 16:09 |
| tgnitt | tbm: and the price remains same without rounding , only the amounts are changed. | 16:09 |
| bkuhn | Someone goes on a trip to Europe from the USA | 16:09 |
| bkuhn | they spend a bunch of EUR at different USD rates | 16:09 |
| bkuhn | I want to know how much it really cost us over the group of transactions in currency conversion costs | 16:09 |
| bkuhn | I don't want it rounded each time | 16:09 |
| tbm | bkuhn: yeah, I think this is something I disagree with but go on | 16:09 |
| bkuhn | but when I get to the point where I pay them back, I would want what you suggest, because the final amount is done. | 16:10 |
| bkuhn | ... and it's on the bank statement | 16:10 |
| bkuhn | so I want the transaction to balance properly AND match the bank statement | 16:10 |
| bkuhn | So it's almost like I want to group transactions into a "super transactions" | 16:10 |
| bkuhn | "super transaction" rather | 16:10 |
| bkuhn | that gets rounded at the end of that group | 16:10 |
| bkuhn | I don't know if I actually need this. | 16:11 |
| bkuhn | But I think I would work with your feature OFF if it were a "blunt instrument" and rounded after each transaction. | 16:11 |
| bkuhn | tbm: did I miss something? | 16:11 |
| bkuhn | (I don't have an example handy, but it should be possible to construct one where we "miss" the true cost of all the currency conversions over many transactions because we rounded too early) | 16:11 |
| bkuhn | Am I making any sense? | 16:12 |
| tbm | yes. Just thinking about it | 16:12 |
| bkuhn | Anyway , as a meta-issue: | 16:13 |
| bkuhn | I think we need to build that list we discussed of the rounding features we want. | 16:13 |
| bkuhn | and propose them to the mailing list ultimately (but maybe email them around between the three of us first) | 16:14 |
| bkuhn | We're discussing in detail on particular rounding feature here. | 16:14 |
| bkuhn | but there might be others. | 16:14 |
| tbm | yeah | 16:14 |
| tbm | yeah we need more use cases to think through this stuff | 16:14 |
| bkuhn | tbm: are you still able to write that up for me and tgnitt to review? | 16:14 |
| tbm | in the meantime, I think tgnitt should look into adding a commodity directive to specify rounding and look into implementing that filter | 16:14 |
| tbm | yeah | 16:14 |
| bkuhn | tgnitt: I agree with tbm: It's clear you'll need to know how to add that filter. | 16:15 |
| tbm | so bkuhn I have an example now | 16:15 |
| bkuhn | So you might as well make a branch and start working with that, but don't send a merge request to ledger-cli upstream until we've finished the conversationa bout it. | 16:15 |
| bkuhn | tgnitt: ^^ | 16:15 |
| tbm | D $100.00 | 16:15 |
| tbm | 2014-06-15 Test 1 | 16:15 |
| tbm | Liabilities:Payable €-19.86 {=$1.3869} @ $1.3869 | 16:15 |
| tbm | Expenses | 16:15 |
| tbm | 2014-06-16 Test 2 | 16:15 |
| bkuhn | s/merge request/pull request/ :) -- sorry, mixing my github and gitorious terminology. ledger-cli is github. :) | 16:15 |
| tbm | Liabilities:Payable €-19.86 {=$1.3869} @ $1.3869 | 16:15 |
| tbm | Expenses | 16:16 |
| tgnitt | bkuhn: I will work on it, but what I know works pre calculations, need to know how the system work on per calculation basis. | 16:16 |
| tbm | bkuhn: so you're saying you want to keep precision | 16:16 |
| bkuhn | tgnitt: and this is a coding task, so it should be easier you to roll through than writing stuff. ;) | 16:16 |
| tbm | if I ask you on 2014-06-15 how much you spent, you'll say $27.54 | 16:16 |
| tgnitt | bkuhn :) | 16:16 |
| bkuhn | tbm: let me play with it on ledger for a minute | 16:17 |
| tbm | and if I ask you how much you spent on 2014-06-16, you'll again say $27.54 | 16:17 |
| tbm | so you spent $27.54 twice | 16:17 |
| tbm | and 2 * $27.54 = $55.08 | 16:17 |
| tbm | ok | 16:17 |
| tbm | so we all agree | 16:17 |
| tbm | but now I ask you: how much do you OWE | 16:17 |
| tbm | and now you're going to say: I owe $55.09 | 16:18 |
| tbm | so you spent $55.08, but you owe $55.09 | 16:18 |
| tbm | so where does this extra penny come from? | 16:18 |
| tbm | it was never an expensive | 16:18 |
| bkuhn | OH! | 16:18 |
| bkuhn | I see | 16:18 |
| bkuhn | this is broken. | 16:18 |
| tbm | and then you say "oh, this is rounding, because I really spent $27.544" | 16:18 |
| bkuhn | You've convinced me. :) | 16:18 |
| bkuhn | examples help. :) | 16:18 |
| tbm | right | 16:18 |
| tbm | good | 16:18 |
| bkuhn | this alone makes it confusing: | 16:19 |
| bkuhn | birch:~$ ledger -V -f ~/tmp/y.ledger -e 2014/06/17 reg | 16:19 |
| bkuhn | 2014-06-15 Test 1 Liabilities:Payable $-27.54 $-27.54 | 16:19 |
| bkuhn | Expenses $27.54 0 | 16:19 |
| bkuhn | 2014-06-16 Test 2 Liabilities:Payable $-27.54 $-27.54 | 16:19 |
| bkuhn | Expenses $27.54 0 | 16:19 |
| bkuhn | birch:~$ ledger -V -f ~/tmp/y.ledger -e 2014/06/17 bal | 16:19 |
| bkuhn | $55.09 Expenses | 16:19 |
| bkuhn | $-55.09 Liabilities:Payable | 16:19 |
| bkuhn | -------------------- | 16:19 |
| bkuhn | 0 | 16:19 |
| bkuhn | 16:19 | |
| bkuhn | the reg and bal report have DIFFERENT results (!) | 16:19 |
| bkuhn | that shouldn't happen. | 16:19 |
| bkuhn | tgnitt: does that convince you? | 16:19 |
| bkuhn | tbm: I suspect we have to leave the default behavior as is. | 16:20 |
| tgnitt | bkuhn: I got his point , This is rounding per calculation with each amount. | 16:20 |
| tgnitt | right? | 16:20 |
| tbm | ok, I should do some real work, but I'll work on some use cases soon | 16:20 |
| tbm | bkuhn: yes, leave the default but add an option | 16:20 |
| bkuhn | tgnitt: right, I got that early. But I didn't understand why it mattered at first. | 16:20 |
| bkuhn | This is why it matters: | 16:20 |
| bkuhn | because two reports don't line up. | 16:20 |
| bkuhn | because ledger is propagating the precision in one report (bal) but not in another (reg) | 16:21 |
| bkuhn | tbm: I thought the reg report was doing an <Adjustment> entry in such cases... do you know when it does an Adjustment entry? | 16:21 |
| tgnitt | bkuhn: My argument is that you will never be off by more than a dollar in current situation if it isn't material . | 16:21 |
| bkuhn | tgnitt: well, I could easily see us being off a lot more than that in this situation: Imagine 1,000 of these transactions. | 16:22 |
| tgnitt | bkuhn: but since we knowingly introduce rounding error, after lots of transactions it will | 16:22 |
| tbm | bkuhn: no, maybe this is a bug. Because it's done with -X '$' | 16:22 |
| tbm | zsh: exit 25 ledger -f f reg ex -X '$' | 16:22 |
| tbm | 66523:tbm@jirafa: ~] ledger -f f2 reg ex -X '$' | 16:22 |
| tbm | 2014-06-15 Test 1 Expenses $27.54 $27.54 | 16:22 |
| tbm | 2014-06-16 Test 2 <Adjustment> $0.01 $27.55 | 16:22 |
| bkuhn | tbm: maybe. | 16:23 |
| bkuhn | tbm: maybe open a bug about this? | 16:23 |
| tgnitt | bkuhn: how this is a bug? it is not the expected behavior of ledger right ? | 16:24 |
| bkuhn | tbm: I'm using an older ledger, I don't get the adjustment at all. | 16:24 |
| tbm | bkuhn: I'll add it to my todo list | 16:24 |
| bkuhn | tgnitt: I see why you're saying that. | 16:24 |
| bkuhn | and you're right, it sort of is expected. | 16:25 |
| bkuhn | The problem is that it's a consequence of using the integer rationals and rounding at different times for different reports. | 16:25 |
| bkuhn | tgnitt: Ultimately, the reg report is rounding for each transaction, while the 'bal' report isn't. | 16:26 |
| bkuhn | So, in some sense, the reg report is doing what tbm is suggesting. | 16:26 |
| tgnitt | bkuhn: it does round before displaying remainder amount. also balances according to it, I think. | 16:27 |
| bkuhn | Yeah, I think the behavior of ledger is ok. | 16:28 |
| tbm | bkuhn: it's always rounding to the display precision. But in case of reg, it rounds down (24.544) whereas int he otehr case it rounds up (49.088) | 16:28 |
| tbm | you can set D $100.000 to see what the real values are | 16:28 |
| bkuhn | tbm: right, that's the point that convinced me you're right we need this feature. | 16:28 |
| bkuhn | tgnitt: yeah, there may be no bug in ledger per se here... the behavior is just odd if one doesn't know what's going on in ledger's internals. | 16:29 |
| bkuhn | Everything looks right to me, because you and johnw have explained to me ledger's internals. | 16:29 |
| bkuhn | But to the average user, they don't understand what is happening. | 16:29 |
| bkuhn | and the behavior might be wrong for their use case. | 16:29 |
| bkuhn | so I'm convinced that tbm's idea for the feature is one we should have. :) | 16:29 |
| tbm | so I want proper rounding, so it doesn't even store 24.544 - it should store 24.54 | 16:29 |
| tbm | and when I do D $100.000 I want to see $24.540 | 16:30 |
| tbm | and not $24.544 | 16:30 |
| bkuhn | tbm: Yup, I'm convinced this is a optional feature we need. :) | 16:30 |
| bkuhn | And I think tgnitt's right that there is no bug here. | 16:30 |
| tbm | yes, no bug | 16:30 |
| bkuhn | just a missing feature. | 16:30 |
| bkuhn | tbm: so you're going to add this to the list of other rounding features and email it around to me and tgnitt? | 16:30 |
| bkuhn | and tgnitt, you can start looking into how to implement this one on your own branch on github? | 16:31 |
| tbm | bkuhn: what would you call the feture in the commodity directive? precision? what do you call it when you only want 2 digits of precision | 16:31 |
| tgnitt | tbm: any explanation, why it does so with -X '$' ? | 16:31 |
| tbm | tgnitt: you mean generate the adjustment? I don't know why it's generated with -X $ but not without | 16:31 |
| bkuhn | (I've got -X '$' and -V doing the same thing in the example) | 16:32 |
| tbm | significant figure? | 16:32 |
| bkuhn | oh, I see. | 16:32 |
| bkuhn | you're right | 16:32 |
| bkuhn | that part is a bug | 16:32 |
| bkuhn | $ ledger -f ~/tmp/y.ledger -e 2014/06/17 reg exp | 16:32 |
| bkuhn | 2014-06-15 Test 1 Expenses $27.54 $27.54 | 16:32 |
| bkuhn | 2014-06-16 Test 2 Expenses $27.54 $55.09 | 16:32 |
| bkuhn | 16:32 | |
| bkuhn | the adjustment should be printed | 16:32 |
| tgnitt | tbm: I think rather than asking number of decimal places, we should keep it like D option , parse it from there . | 16:32 |
| bkuhn | I mean, the feature we're talking about is probably best called "round per transaction" | 16:33 |
| bkuhn | or something like that | 16:33 |
| bkuhn | how we encode it with the 'C' directive is an interesting question, and I have no suggestions. | 16:33 |
| tbm | tgnitt: good point but I'm not sure. D is about the display format, really | 16:34 |
| tbm | so | 16:34 |
| tbm | D $10,100.00 | 16:34 |
| tbm | and | 16:34 |
| tbm | D $10100.00 | 16:34 |
| tgnitt | bkuhn: whatever we name this directive, but if we keep it to accept input in the way 'D' option works. it will be more familiar to the user. I also think we can reuse the parsing logic. | 16:34 |
| tbm | will give different formats | 16:34 |
| tbm | whereas we only care about how many digits after the comma | 16:35 |
| tbm | so I think something like "foo 2" makes more sense | 16:35 |
| tgnitt | tbm: we will just focus on the precision. I think in both cases it is the same. | 16:35 |
| tbm | just an integer specifying the precision | 16:35 |
| tgnitt | tbm: at the same time accepting the input in the format of 'D' | 16:35 |
| tgnitt | tbm: what should foo '0' means ? | 16:36 |
| bkuhn | Ok, this is an UI detail, I'm going to defer to tbm. I'm bad at UI. :) | 16:36 |
| tbm | tgnitt: actually, we need 0 | 16:36 |
| tbm | tgnitt: 0 means no rounding (the default behaviour) | 16:37 |
| bkuhn | meanwhile, I'll open the bug regarding -X/_V and 'D' Adjustment thing | 16:37 |
| tbm | well, maybe not "need" but it's useful | 16:37 |
| bkuhn | tbm: you had the bug in current master, right? | 16:38 |
| bkuhn | I'm behind on the version I'm using. | 16:38 |
| tbm | yeah | 16:38 |
| bkuhn | I'll file it against 3.0.3 | 16:38 |
| tgnitt | tbm: got it. | 16:39 |
| tgnitt | tbm: can you tell me the difference between pre and post handlers? | 16:42 |
| tgnitt | filter we were talking about was a pre post handler. | 16:43 |
| tbm | tgnitt: I don't know, sorry | 16:44 |
| bkuhn | I submitted the bug http://bugs.ledger-cli.org/show_bug.cgi?id=1054 | 16:48 |
| bkuhn | meanwhile, tgnitt , best place to answer that pre/post handler question is #ledger... others there might know, even though johnw isn't around. :) | 16:48 |
| tgnitt | bkuhn : right | 16:48 |
| *** tgnit has quit IRC | 18:09 | |
| *** mlncn has quit IRC | 18:23 | |
| *** mlncn has joined #npoacct | 18:28 | |
| *** nesciens has quit IRC | 18:58 | |
| *** garrison has joined #npoacct | 19:32 | |
| *** bkuhn is now known as bkuhnIdle | 20:17 | |
| *** mlncn has quit IRC | 20:18 | |
| *** bkuhnIdle is now known as bkuhn | 21:13 | |
| *** mlncn has joined #npoacct | 21:18 | |
| *** mlncn has quit IRC | 21:22 | |
| *** bkuhn has quit IRC | 22:24 | |
| *** bkuhn has joined #npoacct | 22:36 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!