Setting up gnucash to use postgesql back end - close but no cigar ...

[Sébastien de Menten]

Thank you John for these references (i already read some of them in the
past but never got the full thread).

Some little points remain confused in my mind:
- you mention that most of the time the denominator is a power of 10 (as at
the end, financial institutions always round to some digit) and so the full
rational type is not needed an a decimal type would be enough. But are
there times where rationals are needed ? If so, would you have some
examples :  intermediate calculations ?  prices ? SX parameters ?
- you also mention rounding issues with decimals. Have you an example of
this ? is it only on rounding on numbers like 1/3 (so rationals, not
decimals) ? or even with only decimals you may have rounding issues ?
- in terms of performance, do I understand correctly that using a decimal
library to add to numbers like 1.34 + 100. is slower than adding the
equivalent fractions 9,37 / 7 + 1000 / 10 with the integer code in gnucash
? Or is it only more performance in the case where we add 1.34 + 100. on
one side and 134/100 + 10000/100 on the other side ?
- in terms of performance, do I understand also correctly that with the
"usual" books you work with, the profiling of the application runtime gives
you an important part of the time spend doing "rational" arithmetic vs the
rest (GUI, IO, ...) and so this point is really critical for "usual" cases ?

If so, in your long term vision (gnucash as a DB app), you would do your
queries in SQL but will implement the "rational arithmetic" in SQL as well
? or would do use the classic "group by denominator" and then put the
rational arithmetic logic in the C code ?

Regards,

Sebastien


On Fri, Mar 13, 2015 at 12:36 AM, John Ralls <jralls at ceridwen.us> wrote:

>
> On Mar 13, 2015, at 7:12 AM, Sébastien de Menten <sdementen at gmail.com>
> wrote:
>
>
> As for numbers, I looked into that rather extensively last summer. No
>> existing decimal library was able to handle the range of fractions
>> necessary for bitcoin to Indonesian Rupiyah while adequately controlling
>> rounding and providing adequate performance, so I decided to stay with our
>> rational numbers. It does have the disadvantage of moving most calculation
>> out of the database, so we may have to revisit it later.
>>
>> Hello John,
>
> I would be interested to have a bit more details on your findings in this
> respect. If you look at a library like libmpdec (
> http://www.bytereef.org/mpdecimal/doc/libmpdec/index.html), does it lack
> features or performance or both ? And with regard to performance, in which
> cases are the arithmetic operations the bottleneck in GnuCash ? Is it in
> some report calculation ? In the (de)serialisation ?
>
>
> Sebastien,
>
> I posted the details in a couple of threads to gnucash-devel last summer.:
>   http://lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html->
> http://lists.gnucash.org/pipermail/gnucash-devel/2014-June/037755.html
>   http://lists.gnucash.org/pipermail/gnucash-devel/2014-July/037888.html->
> http://lists.gnucash.org/pipermail/gnucash-devel/2014-August/037996.html->
> http://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038072.html
>
> The short summary is that even when I disabled dynamic allocation the
> performance was 2-4X worse than our rational class. I also had to write
> fuzzy comparison functions to get some of the existing tests to pass, and
> controlling rounding correctly proved very difficult.
>
> Since the use of rational calculation is pervasive in the engine I took
> the position that any significant slowdown in numeric performance would be
> unacceptable; note that in addition to the numeric test performance I also
> used the GncLot tests and saw some of the worst performance problems there.
> Since the specific goal of redoing numerics was to gain enough significant
> digits to allow for bitcoin's 10**-8 plus some headroom (bitcoin support is
> a frequent user request) while at the same time handling reasonably large
> amounts (10**12) Indonesian Rupiah (10**5 to the US Dollar) and I was able
> to do that by rewriting the int128 class that underlies GncNumeric without
> a performance penalty I'm comfortable with the results.
>
> Regards,
> John Ralls
>
>