2017-01-16 GnuCash IRC logs

00:31:31 *** O01eg has quit IRC
00:38:09 *** Mechtilde has joined #gnucash
01:06:53 *** Mechtilde has quit IRC
01:09:07 *** Mechtilde has joined #gnucash
01:16:30 *** Mechtilde has quit IRC
01:22:06 *** fabior has joined #gnucash
01:25:39 *** fabior has quit IRC
01:39:45 *** iliv has joined #gnucash
01:40:39 *** fabior has joined #gnucash
01:40:59 *** fell_ has joined #gnucash
01:42:53 *** fell has quit IRC
01:52:08 *** iliv has quit IRC
01:53:45 *** storyjesse has joined #gnucash
02:12:00 *** gnutun has quit IRC
02:25:13 *** iliv has joined #gnucash
02:28:55 *** Mechtilde has joined #gnucash
03:04:40 *** cartsoftware has quit IRC
03:05:08 *** mrklintscher has quit IRC
03:09:05 *** Mechtilde has quit IRC
03:11:27 *** Mechtilde has joined #gnucash
03:23:14 *** mrklintscher has joined #gnucash
03:31:52 *** cartsoftware has joined #gnucash
03:35:19 *** fekepp has joined #gnucash
04:01:10 *** gjanssens has joined #gnucash
04:01:10 *** ChanServ sets mode: +o gjanssens
04:03:17 *** mrklintscher2 has joined #gnucash
04:03:22 *** mrklintscher has quit IRC
04:08:25 *** Mechtilde has quit IRC
04:51:19 *** iliv has quit IRC
05:16:49 *** iliv has joined #gnucash
05:28:08 *** iliv has quit IRC
05:39:03 *** fabior has quit IRC
05:52:44 *** fabior has joined #gnucash
06:01:07 *** yuriks has joined #gnucash
06:02:34 <yuriks> Hey. Is there some magic sauce to get GnuCash online features to work with Vanguard? I managed to download the account list, but getting balance or transactions gives me a 400 Bad Request every time. I've tried tweaking settings but nothing worked, and I can't find any recent info on the web about it. I'm on 2.6.15 on Windows
06:08:37 *** iliv has joined #gnucash
06:17:27 *** fell_ has quit IRC
06:20:40 *** rubdos has joined #gnucash
06:26:44 *** User_ has joined #gnucash
06:27:30 *** To7 has quit IRC
06:45:02 *** To7 has joined #gnucash
06:46:49 *** Jimraehl1 has joined #gnucash
07:05:39 *** iliv has quit IRC
07:26:14 *** User has joined #gnucash
07:43:19 *** fabior has quit IRC
07:52:17 *** Mechtilde has joined #gnucash
07:56:19 *** gjanssens has quit IRC
08:00:41 *** Mechtilde has quit IRC
08:05:47 *** iliv has joined #gnucash
08:26:45 *** fell has joined #gnucash
08:46:03 *** rickoehn has joined #gnucash
08:48:41 <warlord> yuriks: you might want to try asking on the gnucash-user mailing list?
09:18:26 *** fabior has joined #gnucash
09:22:29 *** fabior has quit IRC
09:26:21 *** mlncn has joined #gnucash
09:37:32 *** fabior has joined #gnucash
09:54:10 *** gjanssens has joined #gnucash
09:54:10 *** ChanServ sets mode: +o gjanssens
10:22:25 *** mlncn has quit IRC
10:36:56 *** mlncn has joined #gnucash
10:37:24 *** mrklintscher2 has quit IRC
10:42:39 *** Mechtilde has joined #gnucash
10:46:39 *** mlncn has quit IRC
10:52:39 *** O01eg has joined #gnucash
11:01:04 *** storyjesse has quit IRC
11:07:03 *** kael has joined #gnucash
11:13:59 *** kael has quit IRC
11:19:33 *** mlncn has joined #gnucash
11:21:07 *** KaiForce has joined #gnucash
11:25:18 *** iliv has quit IRC
11:45:35 *** iliv has joined #gnucash
11:50:26 *** Mechtilde has quit IRC
11:51:08 *** User has quit IRC
12:06:26 *** fekepp has quit IRC
12:18:10 *** O01eg has quit IRC
12:18:20 <jralls> gjanssens: Got a few minutes to discuss numerics?
12:21:13 *** O01eg has joined #gnucash
12:29:13 *** User has joined #gnucash
12:34:29 *** User has quit IRC
12:44:59 *** kael has joined #gnucash
12:45:36 *** fekepp has joined #gnucash
12:53:03 *** cartsoftware has quit IRC
13:15:15 *** Mechtilde has joined #gnucash
13:15:55 <gjanssens> jralls: just got home now and we'll have dinner first. Afterwards I'm available
13:17:37 <jralls> gjanssens: OK. Enjoy your meal!
13:25:59 *** kael has quit IRC
13:27:24 *** kael has joined #gnucash
13:42:47 *** kael has quit IRC
13:52:44 *** Nytram has joined #gnucash
14:08:28 *** fekepp has quit IRC
14:08:36 *** fekepp has joined #gnucash
14:09:04 *** Mechtilde has quit IRC
14:18:57 *** Nytram has quit IRC
14:22:00 *** fabior has quit IRC
14:23:44 <gjanssens> jralls: I'm back
14:24:11 <gjanssens> My 'review' could have come earlier indeed :)
14:24:36 <jralls> Did you see my post here yesterday about GncRational being too big and not wanting to store int128s in the the dB?
14:24:37 <gjanssens> However when you started the GncRational work I didn't have any experience with modern c++ yet
14:24:56 <gjanssens> I didn't see it yet
14:25:02 <gjanssens> Let me check the logs
14:25:06 *** User has joined #gnucash
14:25:50 <jralls> GncRational is all traditional code. No templates, I don't think I even used auto.
14:26:12 <gjanssens> Yes, I figured that out eventually
14:26:22 <gjanssens> At the time it was all too challenging for me
14:26:54 <gjanssens> Having played with c++ again on the csv importer was good to refresh my memory
14:27:01 <jralls> Yes, you'd said that you'd been away from C++ for a while. Anyway, that's not particularly important.
14:27:44 *** iliv has quit IRC
14:28:55 <jralls> So I've decided to extract GncNumeric as a proper class and just use GncRational for computation and always reduce it but never round it. All the rounding would happen in converting it back to GncNumeric.
14:30:22 <jralls> So some questions: We have 7 ways to round plus "never". Do we really need that?
14:30:56 *** mlncn has quit IRC
14:31:10 <jralls> There are also 5 different ways to compute the denominator after a calculation. Do we really need that?
14:32:12 <warlord> I think there are different rounding methods.
14:32:16 <jralls> If we're going to have more than one of each, what should be the default for opertators?
14:32:39 <warlord> GNC_RND_NONE?
14:32:44 <jralls> warlord: ? There are 7...
14:33:08 * gjanssens caught up with yesterday's irc logs...
14:33:24 <jralls> warlord: GNC_RND_NONE isn't one of them. Perhaps you mean GNC_RND_NEVER?
14:34:23 *** mlncn has joined #gnucash
14:34:52 <jralls> Oops, 6 denom methods, I'd lost AUTO.
14:37:37 <jralls> We have a pair of functions gnc_numeric_(add|sub)_fixed(), which use GNC_HOW_RND_NEVER with either GNC_HOW_DENOM_AUTO or ...FIXED. It requires the two operand denoms to be equal or for one of the operands to be 0.
14:42:16 <jralls> Is that a reasonable default? It is used in 110 places.
14:43:32 <gjanssens> I assume our goal is not to lose precision ?
14:44:00 <gjanssens> And make calculations as fast as possible ?
14:44:30 <gjanssens> So what's the impact of each denominator calculation variant ?
14:44:51 <jralls> That was the goal of introducing GncRational for computation. It's accomplished. The goal now is to design a C++ arithmetic interface.
14:46:47 <jralls> None on precision and probably not significant on performance with the possible exception of LCD. Calculating lcds is a bit expensive.
14:48:00 <jralls> The different denominator variants all affect how the number is represented after the calculation.
14:50:39 <gjanssens> Hmm, from the documentation, denom can be an integer value to specify an explicit denominator or GNC_DENOM_AUTO to use one of the calculation types...
14:50:49 <jralls> It's the rounding that impacts precision, and may be invoked by some of the denominator choices. For example if you set denom to FIXED 33 and the calculation ends up with a value that isn't exactly representable as x/33 then that forces a round.
14:51:52 <jralls> Likewise if you get a result that's not exactly representable as int64/int64 then that also forces a round.
14:52:39 <gjanssens> Fixed appears to mean all input parameters are required to have the same denom and that same denom is to be used in the output value as well.
14:52:49 <gjanssens> I'm not sure that would make a sensible default.
14:52:57 *** User has quit IRC
14:53:17 <gjanssens> I'd rather take GNC_HOW_DENOM_EXACT
14:53:42 <gjanssens> That seems to be the lightest on calculation and won't lose precision
14:54:41 <gjanssens> As for rounding GNC_HOW_RND_NEVER makes sense to me given our prerequisite of losing a minimum on detail throughout the complete calculation
14:54:52 <jralls> But it will error out on overflows. Which leads to my next question: Should GncNumeric continue to use an error value (a zero denominator) or throw?
14:56:21 <jralls> The ulitmate way to preserve precision is to do all calculations with GncRationals, with them modified to reduce at each step, and then stuff
14:56:27 <gjanssens> Perhaps we could internally start with a fallback to GNC_HOW_DENOM_REDUCE to try and avoid an overflow if GNC_HOW_DENOM_EXACT would result in one
14:56:32 <jralls> the result back into a GncNumeric.
14:57:03 <gjanssens> Or as you say do reduce as soon as possible each time. I don't know how badly that would affect performance.
14:57:19 *** User has joined #gnucash
14:58:08 <jralls> It might be a significant performance hit. Maybe should do it only on overflow.
14:58:32 <gjanssens> As for handling overflow via an error message or exception, I'd check what more standard libraries do, like std and boost.
14:58:52 <gjanssens> It seems to be they throw in case of overflows. And that makes sense to me as well.
14:59:24 <gjanssens> We should test after each calculation anyway in principle before using the calculation result. Using an exception is simply more c++.
14:59:59 <gjanssens> Of course it should be caught for all c api surface code
15:00:55 <gjanssens> s/error message/error value/
15:02:28 <gjanssens> Finally regarding the rounding methods, I don't know how much each is used.
15:03:04 <gjanssens> Neither in the code as is now nor how various accounting laws across the world expect rounding to happen.
15:03:35 <jralls> They all are at least once. Why each one was selected at the time is generally not commented.
15:04:13 <gjanssens> If it's not too difficult I'd keep them for now, though it may require some consideration when rewriting calculations in the future.
15:04:24 <gjanssens> If that's at all possible to decide properly.
15:04:42 <jralls> There's one other point about rounding: When the result gets stored it should be rounded to the account/commodity SCU.
15:04:59 <gjanssens> Hah, indeed...
15:06:07 <gjanssens> At least when we're storing currencies or commodities
15:06:46 <gjanssens> How are other amounts rounded (like number of shares, number of line items in invoices/bills) ?
15:07:10 <gjanssens> We obviously do less calculations on those except for the built-in cell calculators.
15:07:16 <jralls> Number of shares is a commodity. It has an SCU which one sets in the security editor.
15:08:55 <gjanssens> Ok, so the only exception so far is the items on an invoice/bill. But that won't affect the defaults we're looking for here IMO.
15:09:12 <gjanssens> the *number of* items
15:10:28 <jralls> Well, if the SCU of the commodity is 1. But what if the unit of the commodity is kilos instead of eaches?
15:10:52 <jralls> Or hours for labor? etc...
15:13:33 <jralls> But aside from amounts of a commodity, where you'd use a GncNumeric even if the denom is always 1 becuase otherwise you'd need separate code for it, for anything else that you'd count (like line items on an invoice) you'd use an int.
15:14:42 <jralls> Oh, we'd better make sure that we mean the same thing by 'line item'. If an invoice is for selling various quantities of three separate commodities, then I'd say the invoice has 3 line items.
15:15:36 <gjanssens> Yes, I was using the term line item confusingly here
15:15:42 <gjanssens> Sorry about that
15:16:23 <gjanssens> I was really thinking of buying 1.5kg of sugar or 0.45ct of diamonds
15:16:38 <gjanssens> Obviously they also need to be stored as a GncNumeric
15:17:18 <gjanssens> When I said it doesn't matter for the defaults we're looking for I meant it apears this is currently hardcoded to a denom of 100.
15:17:24 <jralls> Well, diamonds is probably not a good example. But sugar would be a commoditiy and might have an SCU of 1000.
15:17:38 <gjanssens> warlord may remember what he did there
15:18:12 <gjanssens> Well, in principle yes, but it's not coded as such
15:18:22 <jralls> It had better not be hard-coded to 100. That won't even work for all currencies (e.g. JPY has an SCU of 1).
15:18:31 <gjanssens> There's no way to define a commodity for that in the business features.
15:19:15 <gjanssens> Note that aside from an amount you specify a unit price as well and that will eventually give you a commodity/currency to use in the rest of gnucash
15:19:17 <jralls> Why not? How is sugar any different from a mutual fund, most of which also have an SCU of 1000?
15:19:53 <gjanssens> What's written on the the invoice will never end up directly in the account registers
15:20:10 <gjanssens> Only amount*unit price is.
15:20:20 <gjanssens> As to why not - as warlord ;)
15:20:26 <gjanssens> He coded this originally.
15:20:49 <jralls> Um, the amount should go in the split's amount field and amount * price should go in the value field.
15:21:49 <gjanssens> Perhaps. Doing so would require a big change.
15:22:16 <gjanssens> What one currently specifies on a bill is an expense account, an amount and a unit price.
15:22:19 <jralls> Right, that would add the inventory module users keep asking for. ;-)
15:22:26 <gjanssens> Exactly
15:23:28 <gjanssens> I'll keep that in mind for when I don't know what to do next in gnucash :D
15:24:10 <jralls> So for the purposes of A/P and A/R, which are currency accounts, the commodity of interest is the currency of the invoice and any material one sells is expected to be accounted for in currency, not quantity.
15:24:26 <gjanssens> So to get back to the numerics, as things stand now, the way invoices are implemented don't influence what we should decide as defaults.
15:24:40 <gjanssens> Indeed
15:25:29 <jralls> That limitation doesn't exist in the underlying account/commodity/transaction structure.
15:26:05 <gjanssens> No
15:26:49 <gjanssens> (or: "Correct" - to avoid confusion)
15:26:55 <jralls> ;-)
15:27:16 <jralls> So back to precision and rounding and such.
15:28:28 <jralls> The highest precision right now is to use GncRational (128-bit num and denom) for everything and then squash the result into a GncNumeric at the end to pass to the object for storage.
15:29:25 <gjanssens> Ok
15:30:26 <jralls> The GncNumeric should be forced to have the commodity SCU. That means the denominators can be added to get a total, which lets us do that in SQL queries.
15:30:31 <warlord> ISTR I used the default input of 6, didn't I? (it's been over 15 years since I wrote that code)
15:30:50 <jralls> Oops s/denominators/numerators/.
15:31:12 *** fabior has joined #gnucash
15:31:22 <jralls> warlord: You mean for sigfigs on invoices?
15:31:26 <warlord> yes
15:32:52 <gjanssens> warlord: when I open an invoice, the amounts always show as x,yz
15:33:00 <jralls> 2001... did we even have SCUs then?
15:33:04 <gjanssens> I haven't dug into the code for now
15:33:22 <warlord> oh yes. SCU has been around forever.
15:33:25 *** KaiForce has quit IRC
15:33:37 <warlord> gjanssens: I think it's rounded based on the invoice currency.
15:33:54 <warlord> at least for some values. I think qty can go deeper.
15:33:55 <gjanssens> warlord: that would have been my next guess :)
15:34:25 <warlord> I'd have to look at the code, honestly.
15:37:00 <jralls> If rounding is deferred to the end of a calculation or a 128-bit overflow (which should be pretty darn infrequent in real life, and anyway rounding
15:37:45 <warlord> That would be best.. there have been some corner-case uses-cases where people want "special rounding"
15:37:50 <gjanssens> jralls: when you state with a forced commodity SCU we can use sql queries to calculate sums, that presumes of course we only sum things of the same commodity SCU
15:38:14 <gjanssens> So splits in one register to get an account total yes
15:38:33 <gjanssens> But account hierarchy summaries in reports not always
15:39:10 <gjanssens> Or any calculation involving more than one account more broadly speaking
15:39:57 <jralls> Right, but a sum that combines euros and kilos of sugar isn't going to be meaningful.
15:42:04 <jralls> So a cross-account SQL query would need to make sure that the commodities for the accounts are the same, or it will have to do subqueries and then apply prices to the results to get a common commodity, and then sum the resulting values.
15:42:37 <jralls> Just like the CoA code does now.
15:43:33 <gjanssens> Indeed. So no problem there
15:43:57 <gjanssens> jralls: your previous sentence ended on which should be pretty darn infrequent in real life, and anyway rounding...
15:44:06 <gjanssens> Did I miss a part ?
15:44:55 <jralls> Yes, I hit return too soon and then processed an interrupt... and that train of thought went off the rails.
15:45:45 <gjanssens> crash...
15:46:29 <jralls> ... anyway rounding to a 128-bit denom will still be far more precise than any useful SCU. That's true even for a 646-bit denom.
15:46:47 <jralls> sigh, s/646-bit/64-bit/
15:49:11 <gjanssens> Ok. Actually the precise moment to round is also law dependent IMO.
15:49:20 <gjanssens> I'm again thinking about invoices
15:49:56 <gjanssens> Should the total of each line be rounded before all line totals are summed to an invoice total or not ?
15:50:09 <jralls> The law is going to be about rounding to 1/100, not 1/2^64.
15:50:14 <gjanssens> ISTR I had discussions about this with fell a couple of years back
15:50:27 <gjanssens> Yes of course.
15:51:04 <gjanssens> But I thought I understood you just said we wanted to force rounding to SCU at the end of each calculation.
15:51:57 <jralls> At the end of each calculation or when confronted with overflow.
15:52:34 <jralls> The round to n bits was about the latter.
15:52:50 <gjanssens> Ok. That's more clear now.
15:53:45 <gjanssens> So yes, in case of overflow we can safely try to round without losing significant precision for real life amounts.
15:54:01 <jralls> Rounding to SCU when returning the number to the object (as in xaccSplitSetAmount()) seems to me to be the right time.
15:54:44 <jralls> If there's an accounting practice (i.e. IAS or GAAP) or legal requirement it might be that it would be for an additional rounding before that.
15:55:36 *** cartsoftware has joined #gnucash
15:55:48 <gjanssens> So that suggests the user of the gnc arithmetic code we're designing now can decide to do calculations in GncRational and only convert to GncNumeric when needed ?
15:56:06 <jralls> Maybe we should ask about that on the user list and then hope one of those that actually knows will answer.
15:56:09 <gjanssens> Or in GncNumeric all the time, which will not round unless absolutely necessary
15:57:33 <gjanssens> to prevent overflow
15:58:01 <gjanssens> And code that needs a GncNumeric in the context of a commodity can do the rounding when it receives the GncNumeric ?
15:58:15 <gjanssens> Like your xaccSplitSetAmount example
15:58:19 <jralls> If you want a string of caclulations to be in GncRational until the end you'd have to create GncRationals to do your calculating with and then explicity round at when you're ready.
15:59:28 <jralls> Oooh, I like the idea of the object's setter being responsible for rounding to the SCU.
15:59:55 *** rubdos has quit IRC
16:00:00 <jralls> We could overload it so that there's a GncRational and a GncNumeric version.
16:00:14 <gjanssens> Me too. That makes most sense as the object should know this better than our generic arithmetic code.
16:02:02 *** Epakai has joined #gnucash
16:03:05 <jralls> Well, the arithmetic code is just going to provide the rounding function. But if the object is going to do the rounding then we can just pick the most efficient rounding method to deal with overflows and only the round() member function would need the rounding type arguments.
16:04:11 <gjanssens> Agreed.
16:04:54 <jralls> That will let us clean up a lot of very ugly code.
16:05:30 <fell> And which type of rounding? Bankers to even or schools to zero, ...
16:06:05 <gjanssens> Ok, time for bed here.
16:06:13 <gjanssens> It was an interesting discussion :)
16:06:25 <gjanssens> I'll read up on the rest in the logs tomorrow.
16:06:27 <gjanssens> Bye all
16:06:52 <warlord> see you later, gjanssens
16:06:58 *** gjanssens has quit IRC
16:07:02 <jralls> Goodnight, and thanks.
16:07:22 <Epakai> is there a quick way to delete all empty splits for one account?
16:09:03 <warlord> Epakai: what do you mean "empty splits for one account"? (and why would there be empty splits?)
16:10:39 <Epakai> because each time I entered a new item it reused the split setup and there was always a split for Imbalance-USD that never had any charge far about 6 years
16:11:49 <warlord> Epakai: Unfortunately, no, there's no way to do that. Best bet would be to open your Imbalance-USD account, turn it into Split-Register mode (so it auto-expands the transaction), and then go through each one, manually, and remove the Imbalance line.
16:12:50 *** fekepp has quit IRC
16:13:53 *** fekepp has joined #gnucash
16:14:32 *** kael has joined #gnucash
16:17:49 <fell> <DEL><TAB>... is the quickest way
16:24:34 *** To7 has quit IRC
17:01:51 *** fabior has quit IRC
17:16:39 *** fabior has joined #gnucash
17:48:56 *** User_ has quit IRC
18:01:26 *** rickoehn has quit IRC
18:24:44 *** fabior has quit IRC
18:47:15 *** kael has quit IRC
19:11:57 *** fekepp has quit IRC
19:33:14 *** User_ has joined #gnucash
19:36:30 *** User_ has quit IRC
21:34:05 *** User has quit IRC
22:08:54 *** kael has joined #gnucash
22:17:57 *** cira has quit IRC
22:18:09 *** cyphase_ has joined #gnucash
22:19:03 *** cyphase__ has joined #gnucash
22:20:16 *** cyphase has quit IRC
23:02:39 *** jethrogb has quit IRC
23:04:20 *** jethrogb has joined #gnucash
23:12:57 *** kael has quit IRC
23:50:08 *** O01eg has quit IRC
23:54:29 *** O01eg has joined #gnucash