On Fri, Jul 07, 2000 at 05:12:17PM -0500, Richard Wackerbarth wrote:
>
> But "computing with four decimal places" MAY be harder than doing it more
> accurately. The banks are probably doing the calculations in BCD. Although we
> can, I don't think that is the likely implementation.
>
> Remember, if we design things properly, we can change the internal
> representation without having any real effect on the bulk of the system.
>
In bookkeeping practice representation and mensuration are
intertwined. Historically, business computing has dealt with this
problem by the simple expedient of using BCD, which also has the
advantage of being understood by bookkeepers who program in COBOL.
In principle this can also be dealt with by sub-classing the rational
numbers, however, subclasses proliferate. At the very least one is
likely to end up with with a fixed-precision decimal subclass that
looks very much like BCD--Java's BigDecimal or SQL's NUMBER, in other
words. It's going to take considerable effort to make rounding and
overflow work in the way that bookkeepers and customers expect, and I
believe that meeting those expectations is important--if nothing else
it makes for more accurate and simpler export and import of data.
> And gold chain even closer.
:) To the gram, I believe. Or even the tenth thereof.
>
> So what? Each item has its own "smallest unit of measure" and there is some
> approximation made when the larger inventory is partitioned into the portion
> that you purchased and that which you did not.
>
> [...]
>
> Just because we display "1 1/3 yards" doesn't mean that we cannot store the
> transaction as "48 inches"
>
Sure. As long as the merchant sees that they are measuring and
rounding.
>
> See above. Input and Output do not have to be in the same units as storage.
> If I were building a cash register for the dry goods store, I would certainly
> include keys for 1/2, 1/3, 3/4, etc. Or at least have some input convention
> that allowed it.
>
unh-hunh. I found out that those numbers were once considered
important enough to have a special name; they are called aliquot
parts, which I think is a really cool-sounding, and otherwise
obsolete, word. :)
>
> Remember that the requirement is only that I be able to handle the amounts.
>
Um, don't you mean the program be able to handle the amounts?
> Most banking applications are defined in terms of the character fields of the
> I/O record. They rarely use binary because the I/O conversion dominates the
> math.
Isn't this more of a historical consideration? Since the S/370
family, at least, conversion has been relatively cheap. However, the
accounting/bookkeeping expectation of decimal arithmetic remains.
--
Randolph Fritz
Eugene, Oregon, USA
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
