On Thu, 06 Jul 2000, Bill Gribble wrote:
> Buddha Buck <[EMAIL PROTECTED]> writes:
> > So, why the argument?
>
> It's a high-priority goal of mine to make the result of this process
> be a straightforward, testable, stand-alone mathematical library for
> dealing with financial numbers that other people can use in their own
> applications. I have received private email from several people who
> want to use whatever we come up with to represent numbers in their own
> accounting and financial programs. We are not the only ones who need
> to exactly represent financial quantities.
> I don't think the library has to be large or terribly sophisticated,
> but it does need to be flexible and bring in as few assumptions as
> possible about how it will be used. "Mechanism, not policy" is a
> significant design goal for such a library as far as I am concerned.
> I realize that this isn't completely congruent with the stated goal of
> fixing the problems with gnucash, but I think that they are
> compatible.
I think that you have misrepresented the differences.
> - BG : looking for a data type to represent exact non-integer
> values including monetary quantities.
But this is only part of the requirement. You have proposed what is
effectively a "rational" expression of all numbers. This can certainly be
used to make the necessary representations. However it still has the same
problem as "floating point" because it does not perform the "rounding" which
is inherent in commerce.
For example, if the sales tax rate is 8 3/4 % (0.0875) we can represent that
as 37/400 or as 875/10000. When we apply that to a purchase of $1 (100/100)
we get an answer of 37/400 and not 9/100 which is what is actually collected.
> - CB : looking for a data type to represent exact monetary
> quantities.
> - RW : looking for modifications to gnucash to allow it to
> represent monetary quantities using integers.
The moment that you "fix" the denominator in a representation, Your
representation is just as much "integer" (and the same integers) as mine.
The difference is in the storage.
You propose to store
(numerator, denominator==f(currency), currency)
for each entry
and hope that someone enforces the == relation.
I, on the other hand would store only
(numerator, currency)
for each entry
and store
(currency, denominator==f(currency))
only once in a different table.
> I'm more interested in solving the generic problem in a way that could
> be useful for other people as well as gnucash. The first requirement
> is that the solution not be so entangled with gnucash's guts that it
> can't be factored out. The second requirement is that that it not be
> so focused on the data types and operations that gnucash does that it
> prevents use in a different context.
>
> This may mean that if my work is to be useful it needs another layer
> of API between it and gnucash.
As I point out above, I think that it does.
> As far as I can tell, Chris Browne's
> approach could be easily implemented using my data type as its
> representation of values. RW's could not.
???
I can certainly use your representation to implement the API. It is
"sufficient", but not "necessary". However, you have yet to show how it is of
any significant assistance. I, and others, have pointed out some ways that it
hinders.
As I have stated before, you need to look at the functionality of the API
first. Define the mathematical functions that you need.
I contend that there are only three operations that yield a monetary result.
1) Summation
(V1, CurrencyX) + (V2, CurrencyX) ==> (Vtotal, CurrencyX)
2) Exchange
(V1, Currency1) * (ExchangeRate, Currency1, Currency2) ==> (Vresult,
Currency2)
3) Apportionment
(Q1, Commodity1) / (Qtotal, Commodity1) * (Vtotal, Currency2) ==>
(Vresult, Currency2)
In none of these cases do I have any use for the "denominator" of the
Currency.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
