recovery

[hendrik at topoi.pooq.com]

On Thu, Nov 01, 2007 at 10:34:45AM -0400, Derek Atkins wrote:
> hendrik at topoi.pooq.com writes:
> 
> > 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?
> 
> GnuCash does use 64-bit numbers internally.  See
> lib/qof/libqof/gnc-numeric.h for the definition, but it's a 64bit/64-bit
> rational number.
> 
> >> >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.
> 
> Umm.. I understand exactly how gnucash stores it, but you miseed my
> point.  The person I was responding to was suggesting that numbers get
> stored as decimal, and I was asking THAT person how you would suggest
> that we store a decimal number that represents the number 1/3.  I know
> very well how gnucash does it -- it stores TWO integers that represent
> the rational number.  But moving that over to a SQL database might be
> more problematic.  I'm not sure if you can do something like:
> 
>   SELECT * from Split where Split.amount_num/Split.amount_denom = 1/3;
> 
> Maybe you can?  I honestly don't know.

Maybe.  But I suspect you'd have rounding errors that could give you 
equality when you should have had inequality.

> 
> > 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.
> 
> That's not necessarily true, and I certainly wouldn't suggest you
> depend on it.  Also, XML is a HORRIBLE format for a database!  XML
> is a wonderful interchange (import/export) format, or document format,
> but it SUCKS HAIRY MONKEY BALLS as a database.

Agree on a XML as a database format.  The system they-ve standardised as 
a query language for XML (xquery) lacks relational joins, too.  I don't 
know if any implementations of it recognise convoluted nested loops and 
equality tests as being such and optimise, but the implementation I've 
tried doesn't.

So I still use hand-coded C++ to read the gnucash file.

-- hendrik