recovery

hendrik at topoi.pooq.com hendrik at topoi.pooq.com
Wed Oct 31 17:19:17 EDT 2007


On Wed, Oct 31, 2007 at 04:35:44PM -0400, Derek Atkins wrote:
> Quoting Mike or Penny Novack <stepbystepfarm at mtdata.com>:
> 
> >
> >>Long ago, gnucash stored its data in binary, with its amounts of money
> >>recorded in binary floating-point.  I pointed out that this was not
> >>adequate for financial data, wiere pennies matter on amounts line a
> >>billion dollars, and the roundoff errors involved in binary/decimal
> >>conversion are ultimately unacceptable.
> >>
> >>This started a revolution in which money would be represented in exact
> >>form; as it happens they chose character strings that represented
> >>amounts as an intergal number of tiny units of currency.  For my
> >>accounts, this unit turned out to be a penny.  I gather it's different
> >>for stock-trading accounts.
> >>
> >>
> >>
> >Suggestion (from somebody who used to do "financial" software for a living)
> >
> >That solution would be unnecessarily slow (repeated data conversion back
> >and forth). The database and all calculations can be integer and only
> >when the figures are to be displayed are they edited (decimal point
> >inserted at the appropriate place). AKA "scaled decimal" representation.

And is the usual 32-bit number adequate?  4 billion peenies seems a mite 
paltry.  Well, not palrty for *my* accounts, but they'd have to go to 
the next step up, 64-bit numbers.  I'm not sure just what they do 
internally, but I'd suspect arbitrary precision.  Anybody waht to 
test it with a 20 quintillion transaction?

> >Fairly easy to write "edit mask" functions if not directly supported by
> >language/hardware (precisely because of this usage COBOL and the IBM
> >mainframes used in "financial" work provide for "edit mask" as a
> >primitive ---- in other words, you can define a "mask" specifying fairly
> >complex number editing and that determines how that number DISPLAYS)
> 
> Historically this doesn't work.   How do you represent 1/3 in decimal?

In the XML, they set the unit for the account to 1/3.  Then they just 
represent it as 1.
Or set the unit to 1/6.  Then represent it as 2.

At least, scaling the account this way is what they said they would do, 
and maybe they do it that way internally (I haven't read the code).  But 
reading the XML I see fractions like 12504/100 for $125.04, and all the 
entries in one account have teh same denominator.

One good thing about XML is that it's kind of future-proof.  It'll 
always be possible to add new entities as needed.  No fixed-width binary 
formats to constrain one.

-- hendrik



More information about the gnucash-user mailing list