Proposal for modifying gnucash to use exact quantities

[Steven Murdoch]

Bill Gribble wrote:
> 
> 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.
You are right. I made a mistake.
 
> > 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.
Absolutely, even though I call the new type 'integer', it really should
be called 'fixed denominator rational'. I have never suggested that your
API is insufficient, but if the denominator can be assumed based on the
commodity type then why store it and use it in calculations?
My 'integer' type is a special case of your API (just as integers ae a
special case of rationals), but still is valid in enough cases to be
useful, that is why it is an addition to rather than a replacement for
your API.

> > 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.
It's not so much harder, but it is significantly harder (by that I mean
less efficient) and if there is nothing to gain then why do it.

> > 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.
Maybe, but a small speed increase is better than none. But there are
other advantages, mainly I think that it gives a clearer representation
and simpler operations, and others in my previous couple of mails.

 
> 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.
I'm not too bothered about time, if there was a slightly slower solution
that was clearer to use and less error prone then I'd go for it. But
IMHO 'integer' representation is better in the cases where it can be
applied, and also faster.
 
>   - 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.
Sounds cool, what would be even cooler would be to what Gnumeric did and
have an XML format (then gziped in later versions) - maybe one thing for
the future.

Thanks,

-- 
Steven Murdoch.
email: sjmurdoch@linuxfan.com
web: http://www.bigfoot.com/~murdomania/
PGP Keys: http://www.bigfoot.com/~murdomania/contact.htm
Geek Code: http://www.bigfoot.com/~murdomania/geek.htm