On Fri, 16 Jun 2000 23:01:21 MST, the world broke into rejoicing as
Dave Peticolas <[EMAIL PROTECTED]> said:
> Buddha Buck writes:
> > Can someone tell me if I am missing anything here?
>
> > 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...
> >
> > So, what are the objections to this approach?
>
> We can't assume that every architecture will have a 64-bit integer.
>
> For that reason, and for the simple fact that if we are going to go to
> the trouble of doing this, we might as well go all the way :), I think
> we should use gmp's multiple precision integers. Then, it will work on
> all architectures, and we can say that gnucash can support values of
> arbitrary size.
_Can't_ we assume 64 bit integers?
a) glib provides gint64. It also offers the option of not supporting
that type, but widely offers it.
b) GCC provides long long. On 32 bit architectures, no less.
c) Even Plan 9, about as different from *BSD, Linux, Solaris, and AIX as
it gets, supports 64 bit integers.
d) How about we do a survey? Put a sample file into the sources that
tests for existence of 64 bit ints. If the survey finds no
64-bit-less platforms, I strongly doubt that many will get _added_.
I would strongly argue _against_ gmp: It means that money values are
no longer of fixed size. Which seems a thorny problem to me; that
means there's _no_ option of putting them into SQL databases, except
via encoding them into VARCHAR fields, and losing all ability for the
DBMS to support calculations. I don't think we should be doing this
_soon_, or necessarily _ever_; just be aware that "going gmp" destroys
the possibility of doing:
select sum(amount) from txntable where account = "Checking Account";
Likely a more practical question: how do we cope with variable size
representation when we decide to add in a CORBA interface? Note that
CORBA provides, as standard, in 2.3:
a) long long, which is the C/C++ 64 bit type, as well as
b) fixed <size,scale>, a type designed for money.
for instance:
typedef fixed<15,2> money;
will provide a fixed-at-compile-time structure thus:
typedef struct
{
CORBA_unsigned_short _digits;
CORBA_short _scale;
CORBA_char _value[8]; /* 8 = ceiling(15/2) */
} CORBA_fixed_15_2;
Note: This code fragment was generated by orbit-idl, so
this functionality is _decidedly_ supported by GNOME-based
apps.
Floating point systems are indeed problematic to "prove right;" you need
Ph.Ds in numerical analysis for that. Verifying that integer-based
schemes calculate right is a much more modest requirement; we can use
Peano axioms and induction to establish the properties we need, and it's
_not_ an incredibly hard thing to verify that the basic operators +, -,
and * work properly, with some well-defined rounding rules.
I think the only reasonable alternatives _are_ "long long" and
some form of "fixed<size,scale>". CORBA supports them; DBMSes are
moving to support them; GCC supports them to some extent. gmp is
interesting, but I think it's no alternative to these.
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/>
Rules of the Evil Overlord #154. "I will instruct my Legions of Terror
in proper search techniques. In particular, if they are searching for
escapees and someone shouts, "Quick! They went that way!", they must
first ascertain the identity of this helpful informant before dashing
off in hot pursuit." <http://www.eviloverlord.com/>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
