On Wed, 05 Jul 2000, Bill Gribble wrote:
> At the top level, I think the first thing to nail down is a numeric
> representation rather than a monetary-value representation. There
> needs to be a layer that enforces restrictions such as "can't add
> dollars to pounds", but I believe that we must first solve the
> lower-level problem; it *is* possible to add a number denominated in
> hundredths to a number denominated in thousandths.
No it is not. That is adding "apples" and "oranges".
If you wish, you may convert one into the other, or both into some third
common "currency" and add the results. However, you never add unlike things.
> The lowest level of arithmetic operations should be agnostic about
> currencies, and so (I think) the data structure representing numeric
> values should have no information about currency in it.
I disagree. I think that you are confusing things like prices and amounts.
In common usage, they are both mapped onto the rational numbers.
I have seen irrational pricing, but never irrational prices :-)
A fundamental characteristic of anything we are handling are the "units".
Mathematicians talk about numbers, but accountants and engineers only use
those numbers to quantify a measurement. "One" is a mathematical term.
"One" plus "One" equals "Two". But is that "One dollar", "One penny", "One
day", or "One furlong/fortnight"? "One dollar" plus "One furlong/fortnight"
is meaningless.
There is no reason that we should treat ALL measurements as numbers.
You certainly want to treat things that are physically counted, like
"Dollars" or "Shares" as a common meta-type because all of the operations on
them don't care which units they are. It only matters that they are the same.
> Jon has suggested using a small number of bits of the "big integer" as
> an index into a table of the (finite) possible values for the
> denominator. This lets us use just one 64-bit int as the number. I
> don't think I like this (why restrict values, and is the C compiler
> smart enough to enforce type safety?) but it's a possibility.
IMHO, nothing outside the "money handlers" should care HOW the "money" is
represented. "Money is Money" and we need to define the FUNCTIONAL interface
rather than the implementation. Once we have defined this functional
interface, we can discuss that details of the storage. However, it should not
be anything significant if we suddenly change the implementation details.
We might even have multiple representations at the same time. By that, I mean
that I might compile a version of gnucash that uses BCD arithmetic and you
might use gint64. All of the gnucash code should remain the same except for
the small section that actually does the arithmetic.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
