Proposal for modifying gnucash to use exact quantities

Bill Gribble grib@billgribble.com
Tue, 1 Aug 2000 11:13:27 -0500


On Tue, Aug 01, 2000 at 04:36:56PM +0100, Steven Murdoch wrote:
> For example the task of comparing two integers is trivial O(1)
> complexity, but comparing two rationals is far from it and I think has
> O(sqr_root(n)) complexity, so if this is done several times the
> performance difference will be noticeable

Actually, that's not true.  Comparison of two rationals requires two
multiplies of they have different denominators, but it's still a
constant-time operation O(1).  With like denominators the comparison
is the same as an integer comparison and requires no multiplies.

> In general the integer representation would be better for quantities
> that have the property that between two distinct values there is a
> finite number of other values. Examples would be number of shares (pure
> integer), amount of currency (integer SCU's), bank balance (integer
> SCU's) etc...

Assuming that a commodity has a particular denomination, rational
representations have this property.  

> The last two functions are quite similar to Bills, so you may ask the
> question what's the point of adding a new type to gnc_numeric. One
> possible answer is efficiency; integer functions are far faster than
> rational ones and the majority of calculations are within type and only
> very rare cases currency_convert or transaction_total will be used. 

I'm curious why you think rational math is so much harder than integer
math.  If you try to reduce every value to a relatively prime
fraction, sure, but if you are doing operations that have fixed
denomination, all you are doing is the same integer math operation you
would do with a strictly integer representation.  

> Most book keeping is done within a currency and this will be
> dramatically faster. Also the storage required is about half the
> size, so decreasing memory usage, disk space and more importantly
> disk transfer time

All this is reasonable to take into account.  However, I doubt that
there will be any significant effect... consider that the
'description' and 'memo' stored with an average gnucash
split/transaction is in the neighborhood of tens of bytes.  That, plus
in-memory pointers to accounts and other structures, are the bulk of
the memory requirements for a split or transaction structure.

If you are concerned about gnucash startup time, consider two things: 

  - a patch recently submitted made a minor optimization that improved
    gnucash start time dramatically.  The author (forgot his name,
    sorry) is working to make that even better.  Yes, there are 
    bottlenecks, but they are with (1) the engine-stuffing code 
    and (2) the GNOME canvas, rather than the file-io time. 

  - Rob Browning is this close --> <--  to being finished with a 
    text-only file format that is dramatically SMALLER than the 
    current binary format.  How?  Well, consider that a binary 
    format requires 8 bytes to store the 64-bit int '0', while a 
    text format requires only 2...  even with the overhead of 
    string parsing, the format promises to be both faster and 
    smaller than the binary format.  In any case, we could store the 
    num/denom pair representing $1234.56 as "123456 100", which is 
    10 bytes, and a binary 64-bit float or int would take 8.  

b.g.