Proposal for modifying gnucash to use exact quantities

[Gary Bickford]

> My question is would it be *easier* to implement the modifications
> needed to Gnucash if another type and it's associated funcions were
> added to the API that could only represent integers (say stored as a
> 64bit integer)?
>

Using 64 bit integers is a very powerful approach.  I posted a note a
couple of days ago, but it never appeared (along with several other mails
to other places) so I suppose it went into the transfinite hyperspace link
to Orion instead of to the list...

Some (wacky?) economists have discussed the concept of the 'erg standard' -
denominating all currencies in terms of units of energy.  Historically the
availability and cost of energy sources has remained roughly the same after
inflation and other factors, and this approach rationalizes all sorts of
economic models.

Ergs are really tiny - there are 3.6e+13 ergs in a kilowatt hour.  I pay
$0.046 per KWH for my electricity.  Ergs are actually too tiny, so we
adjust the range a bit.  A giga-erg is worth approximately
US $0.0000016559999867 according to 'bc' and 'units' and my electric bill -
about 2 millionths of a dollar.  This will give a maximum value of about
$1.65 trillion - oops, need a sign bit - about +/- $825 billion (if I did
the math right.)

Thus, if the basis for all values in gnucash were in terms of  giga-ergs, a
64 bit integer would have the correct range for almost all economic
computations, and would also have enough precision to perform all the
ratios and interest computations for any purpose.  If you need to go to
$825 trillion, then use 1000 giga-ergs and lose 3 digits of precision.

It would also be easily translatable into the economic forms of any future
extraterrestrial visitors. :O)  If folks get to trading planets and solar
systems some day, increasing to 128 bits will take care of any overrange
issues.

Note that it isn't necessary to actually figure out the erg exchange rate -
just use for now as an approximate scale setting.  You will have no scale
issues ever again.  You can do all the arithmetic in integer form (fast),
and if done properly (to avoid successive-rounding buildup of
error) I think you'll never have rounding issues.

:O) Gary BIckford