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

[John Ralls]

> On Mar 13, 2015, at 8:11 AM, Edward Doolittle <edward.doolittle at gmail.com> wrote:
> 
> I suspect the problem is that most (all?) libraries for decimal numbers don't do rational arithmetic exactly. If you pay $7 for 6 Euros (or is that $6 for 7 Euros? :-) neither conversion factor 6/7 nor 7/6 is an exact decimal ... Infinite precision decimal arithmetic, not arbitrary precision, is needed for exact results. GnuCash now does a lovely job handling such conversion rates as rational numbers; I presume (and am interested to know for sure) that internally GnuCash uses rational numbers as much as possible, leaving decimal approximations to the last moment.
> 
> Decimals can of course be used as approximations, which may be adequate depending on the exact requirements, but I can appreciate how hard it would be to find a decimal library that works given GnuCash's requirements for internationalization and other exacting requirements. (I would be disconcerted if my balance sheet didn't balance due to rounding errors, for example.)
> 
> I know next to nothing about databases, but I imagine it may be possible to store rational numbers using two big integer fields (or maybe three for mixed numbers like 5 1/2 which help to keep the size of the numerators down). Multiplying and dividing such number representations would be easy. Adding and subtracting are more involved but are by no means difficult. It is also beneficial to calculate greatest common factors when working with rational numbers. Overflow in the denominators might be an issue.
> 
> If routines could be written on the database side, I would be willing to give it a try. I need to learn more about databases anyway. :-)


GnuCash uses rational numbers for almost all calculations (there are a few instances where floats are used because implementors didn't know what they were doing. Those are bugs which will be fixed when the code gets rewritten in C++).

GnuCash does store rationals as two int64s. That makes queries involving calculation difficult and I'm sure that's the reason Jan and maybe Simon are unhappy about it.

Regards,
John Ralls