recovery

[Derek Atkins]

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.

> 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.

> -- hendrik

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available