On Fri, 16 Jun 2000 03:33:34 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]> said:
> On Thu, 15 Jun 2000, Hendrik Boom wrote:
> > > Each currency has its own "primitive" amount and all transactions are
> > > conducted in terms of that unit. Prices are often expressed to a higher
> > > precision or as a rational fraction of that unit.
> >
> > This suggests that we should be storing integers that indicate
> > how many of the primitive amount are to be used. For US$ this would
> > be an exact count of pennies.
>
> I believe that this is the correct approach.
I'd tend to agree.
> > The range of integers must be greater than 32-bits, because
> > that would limit amounts to about #40,000,000.00.
>
> You are correct. 32 bits are inadequate. It would be sufficient for MY
> personal accounts :-( ....
> but not those of Mr. Gates.
>
> > So the obvious type is int64
>
> Or we can "roll our own" with a money struct.
>
> In cases like this, C++ does have its advantages over C. But we can work
> around it.
I'd favor something like:
struct {
long long amount;
short mantissa;
char currency[4];
} money;
which would provide a reasonably efficient representation; we'd get
something a bit more portable via:
struct {
gint64 amount;
gint16 mantissa;
char currency[4];
} money;
Note that the CORBA C mapping takes
fixed<10,2> money;
and generates:
typedef struct
{
CORBA_unsigned_short _digits;
CORBA_short _scale;
CORBA_char _value[6]; /* 6 = ceiling((10+2)/2) */
} CORBA_fixed_10_2;
which is treated as BCD. [I remember the Z80 having BCD
instructions...]
C++ doesn't pack "fixed" values; it seems to be "one digit, one byte."
The main merit of C++ here is that you'd be able to define overloaded
operations for +, -, *, /, which allow you to at least _consider_ having:
total_money = v1_money + v2_money;
I'm not sure it generalizes much better than that...
Guile would probably cope with this better still; I expect we could
build GOOPS classes and structures that would work out _quite_ well.
(set! total (money+ value1 value2 value3 value4))
> > Thus, for display
> > purposes, we may have to know the primitive amount for each currency as
> > well as the format to be used.
>
> Correct.
>
> > I've always been doubtful about the use of floating point by gnucash.
>
> Likewise.
Ditto...
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/linux.html>
"I worry that the person who thought up Muzak may be thinking up
something else." -- Lily Tomlin
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
