On Fri, Jun 16, 2000 at 10:56:29PM -0400, Buddha Buck wrote:
> Can someone tell me if I am missing anything here?
>
> Needs of a currency class for GnuCash:
> ==========================
>
> Assumption: Unless otherwise specified, all currencies are the same
> denomination (all dollars, all lira, all pounds sterling, etc)
>
> We must be able to add two monetary values with commutivity/associativit
> y
> We must be able to subtract two monetary values
> We must be able to multiply a monetary value with an arbitrary real.
>
> We do not need to be able to multiply two monetary values (i.e., square
> dollars are meaningless).
You need to provide casts to double, long double, or g_int64, at least,
because there do exists cases where you want to *divide* currencies with each
other, particularly in managerial accounting where you want to find figures
like return on equity, return on investment, asset turnover, etc. Either
that or you need to be able to divide currencies with each other.
> Please note: As long as we don't do any multiplication, this will
> allow us to properly handle dollar values as large as
> $92,233,720,368,547,758.07 without loss of precision. Assuming I have
> the mantissa right, IEEE 64-bit FP will start to mess up around
> $22,517,998,136,852.48 (+/- a factor of two or so). While $22 trillion
> is probably "sufficient" for most purposes, it's nice to know that we
> can go as high as $92 quadrillion if we need to...
Well, 22 trillion Italian lire is "only" about 11 billion (US) dollars (US)
the last time I looked, which is probably more than what the entire membership
of this mailing list will see in our collective lifetimes, but is not enough
if you eventually want gnucash to be taken seriously by mega-corporations like
Fiat or the Italian government. Korean won is approximately in that range as
well, and Hyundai will probably want their accounting system to count higher
than about 20 billion dollars. So that's yet another strike against double--it
tops out at values that may possibly become relevant.
Of course, it'll be years before gnucash can be taken seriously by Fiat in
any case, but you might as well do things right to begin with.
> So, what are the objections to this approach?
Well, for one thing, it's in C++ and gnucash is in C. :-) But I'll let other
people play the language advocacy game. It's worth noting, though, that
object-oriented programming is possible in C, and one needs to look no further
than gtk for an example. So that alone is not a good enough excuse to rewrite
gnucash in another language.
--
Shimpei Yamashita <http://www2.gol.com/users/shimpei/>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
