Re: denominating currency

[Richard Wackerbarth]

On Thu, 15 Jun 2000, Ben Stanley wrote:

> (The C++ bit is nice here because
> overflow checking can be incorporated into the number class.)

It also makes it easy to handle currency problems by subclassing "beans" and 
hiding the particulars of "counting" (adding) them.

> However, I realise that you guys like C and want to keep it that way.

Careful who you snare in your "guilt by association".

The project was started in C and AFAICT stuck there by inertia and the bias 
of some of those who are running things.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Dave Peticolas wrote:
> Richard Wackerbarth writes:
> > > > Each currency has its own "primitive" amount and all transactions are
> > > > conducted in terms of that unit.

> > > This suggests that we should be storing integers

> I don't think this is very practical. There are well over 100
> currencies in circulation and keeping track of them is not a small
> task. Also, it's not just a matter of gathering the information once,
> because, as someone has already pointed out, the 'primitive' amount of
> a currency can change.
Yes, but not very often. In a practical sense, you set up the currencies that 
you use and forget the rest.

> Furthermore, gnucash also should be able to
> track mutual fund shares, precious metal quantities, and anything else
> of financial value that users might wish, in whatever accuracy they
> want.

Agreed. Stock in XYZ Corp is just another currency. And to complicate things,
it trades in different units in different places.

> If the use of floating points becomes an issue,
As far as I am concerned, it IS an issue.

> I think a better
> solution would be to use an arbitrary precision library. We would
> still get absolute accuracy, but we would dispense with the need to
> track 'primitive units' for every currency/whatever that people might
> wish to count.

When transactions occur, they are rounded. In general, the roundoff error 
accumulates to an amount which exceeds the displayed precision.
We need to model the actual behavior rather than approximating it.

This can only be done by knowing the rounding precision of each transaction.
Therefore, we must track the 'primitive units'.

If I cannot convince the gnucash folks of this, I'll have to advocate 
agnu-er-cash project since a project based on "floating point is good enough" 
will never "get it right".

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Dave Peticolas]

Richard Wackerbarth writes:
> 
> When transactions occur, they are rounded. In general, the roundoff error 
> accumulates to an amount which exceeds the displayed precision.
> We need to model the actual behavior rather than approximating it.
> 
> This can only be done by knowing the rounding precision of each transaction.
> Therefore, we must track the 'primitive units'.

Could you give a concrete example of this for the purposes of discussion?

thanks,
dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Hendrik Boom]

> 
> You are correct. 32 bits are inadequate. It would be sufficient for MY 
> personal accounts :-( 
> but not those of Mr. Gates.

Mr Gates is unlikely to use gnucash on Linux.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Buddha Buck]

> Richard Wackerbarth writes:
> > 
> > When transactions occur, they are rounded. In general, the roundoff error 
> > accumulates to an amount which exceeds the displayed precision.
> > We need to model the actual behavior rather than approximating it.
> > 
> > This can only be done by knowing the rounding precision of each transaction.
> > Therefore, we must track the 'primitive units'.
> 
> Could you give a concrete example of this for the purposes of discussion?

I buy peaches at 3/$1.  If I buy them one at a time, each transaction 
is rounded, and I get 1 peach for $0.33.  After three such 
transactions, I've spent $0.99 for 3 peaches.  The rounding error 
accumulated in my favor.

I buy apples at 3/$2.  If I buy them one at a time, each transaction is 
rounded, and I get 1 peach for $0.67.  After three transactions, I've 
spent $2.01 for 3 apples.  The rounding error accumulated in my 
grocer's favor.

Or, for a more GnuCash-ish example...

I have a couple of outstanding student loans, which I am dilligently 
paying back.  Every month, I make a student loan payment of a fixed 
amount, on a fixed date, etc.  This is the perfect scenario for the (as 
I understand it) not-yet-completed scheduled recurring transaction 
functions of GnuCash.

But the transactions are not perfectly identical.  This months payment 
of $p is going to pay interest at an annual rate of r, and the rest is 
going to principle.  So what I'd really like to happen is for each 
recurring transaction to have a Journal Entry like so:

x/14/00  Student Loan Payment
Checking account$p
 Interest on Loans  $B*r/12
 Stafford Loan Balance  $p-$B*r/12

where $B is the previous balance on the student loan.

The problem comes with the computation of $B*r/12, since this is 
unlikely to come out to an integral number of cents.  If $B is $20,000, 
r is 8%, then this works out to $B*r/12 = $133.33, which gets 
rounded (in real life) to simply $133.33.  Which means that if my loan 
payment was (say) $250, then I'd pay $116.67 towards the principle.

I'd want GnuCash to record that as interest of $133.33, principle of 
$116.67, since that is what my creditor will record it as.

If GnuCash recorded the balances internally as FP numbers, then the 
amounts wouldn't get rounded off.  The difference would be small, true, 
but over time could result in the GnuCash computed values differing 
from the "real" values significantly, where a cent may be considered 
"significant".

(BTW, is the recurring transaction system going to be able to handle 
transactions like that?  That seems like a fairly common type of 
recurring transaction.)

> 
> thanks,
> dave
> 
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
> 
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Dave Peticolas wrote:
> Richard Wackerbarth writes:
> > When transactions occur, they are rounded. In general, the roundoff error
> > accumulates to an amount which exceeds the displayed precision.
> > We need to model the actual behavior rather than approximating it.
> >
> > This can only be done by knowing the rounding precision of each
> > transaction. Therefore, we must track the 'primitive units'.
>
> Could you give a concrete example of this for the purposes of discussion?

Assume the case where an item is priced at 3 for $2.
For this discussion, the price NEVER changes.

Purchase one item.
and another
and a third
Total cost = 3* $0.67 = $2.01
Now purchase 3 at once. Cost = $2.00

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Buddha Buck wrote:
> > Could you give a concrete example of this for the purposes of discussion?
>
> I buy peaches at 3/$1
...
> I buy apples at 3/$2
...

> Or, for a more GnuCash-ish example...
> I have a couple of outstanding student loans
...

Thanks, your description is certainly better than mine was.

And if you don't believe these are real problems, I encountered them some 
thirty years ago when I (actually my client) bought some 20,000 such loans 
for $139,000,000.00

Keeping those books REQUIRED both more than 32 bits precision and counting 
pennies on each individual transaction.



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Christopher Browne wrote:

> 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))

I think that the advantage of C++ (or guile) is in the OO aspect of having 
methods to add, print, etc. and otherwise manipulate the "money" without 
having to worry about the currency characteristics.

total_money = v1_money + v2_money;
vs
total(total_money , v1_money , v2_money);

is just notational.

The key is that the call works the same for dollars or lira or shares of XYZ 
corp.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Dave Peticolas]

Buddha Buck writes:
> 
> If GnuCash recorded the balances internally as FP numbers, then the 
> amounts wouldn't get rounded off.  The difference would be small, true, 
> but over time could result in the GnuCash computed values differing 
> from the "real" values significantly, where a cent may be considered 
> "significant".

Ok, you've convinced me of the need to track 'smallest denominational
units', but not why we need to use integers rather than FP numbers.
You can round FP numbers, too. Why couldn't we just round the FP
amounts to the appropriate precision when needed? If you're worried
about the loss of accuracy, you should provide a realistic example
where the precision of 64-bit floating points is insufficient. And if
you're really worried about that kind of accuracy, I think arbitrary
precision would be required. You will lose accuracy in intermediate
calculations doing division and multiplication of the integer&mantissa
structs/classes as well.


> (BTW, is the recurring transaction system going to be able to handle 
> transactions like that?  That seems like a fairly common type of 
> recurring transaction.)

I don't see why it couldn't, I mean, it hasn't been started yet, so
it's all up in the air.

dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Dave Peticolas wrote:

> Ok, you've convinced me of the need to track 'smallest denominational
> units', but not why we need to use integers rather than FP numbers.
> You can round FP numbers, too. Why couldn't we just round the FP
> amounts to the appropriate precision when needed? If you're worried
> about the loss of accuracy, you should provide a realistic example
> where the precision of 64-bit floating points is insufficient.

I don't have a problem with 64 bit FP precision. However, I worry that
you don't gain anything by using FP. And you do run the risk of forgetting
to process the values as money rather than true reals.

In that respect, having a struct type which does not allow the "+" operator
would help make sure that you didn't inadvertently overload the simple 
arithmatic operators.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Dave Peticolas]

Richard Wackerbarth writes:
> On Fri, 16 Jun 2000, Dave Peticolas wrote:
> 
> > Ok, you've convinced me of the need to track 'smallest denominational
> > units', but not why we need to use integers rather than FP numbers.
> > You can round FP numbers, too. Why couldn't we just round the FP
> > amounts to the appropriate precision when needed? If you're worried
> > about the loss of accuracy, you should provide a realistic example
> > where the precision of 64-bit floating points is insufficient.
> 
> I don't have a problem with 64 bit FP precision. However, I worry that
> you don't gain anything by using FP. And you do run the risk of forgetting
> to process the values as money rather than true reals.

The reason why I like doubles is that a huge amount of work has gone
into making the IEEE floating point specification "correct". These
quantities are used ubiquitously and are scrutinized by many people.
I have great confidence that the calculations are being done
correctly. OTOH, if we roll our own numerical library, I will have
much less confidence. It's not that I think we are bad developers,
it's just that the problem is quite complicated. It took a long time
to get IEEE floating point correct, and there were some extremely
smart people involved.

For that reason, if we decide to drop doubles, I would rather use
a library like gmp which has already been written/debugged rather
than start from scratch. We've got too many other things to do.


> In that respect, having a struct type which does not allow the "+" operator
> would help make sure that you didn't inadvertently overload the simple 
> arithmatic operators.

I agree.

dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Dave Peticolas wrote:
> Richard Wackerbarth writes:
> > On Fri, 16 Jun 2000, Dave Peticolas wrote:
> > > Ok, you've convinced me of the need to track 'smallest denominational
> > > units', but not why we need to use integers rather than FP numbers.
> > > You can round FP numbers, too. Why couldn't we just round the FP
> > > amounts to the appropriate precision when needed? If you're worried
> > > about the loss of accuracy, you should provide a realistic example
> > > where the precision of 64-bit floating points is insufficient.
> >
> > I don't have a problem with 64 bit FP precision. However, I worry that
> > you don't gain anything by using FP. And you do run the risk of
> > forgetting to process the values as money rather than true reals.
>
> The reason why I like doubles is that a huge amount of work has gone
> into making the IEEE floating point specification "correct". These
> quantities are used ubiquitously and are scrutinized by many people.
> I have great confidence that the calculations are being done
> correctly. OTOH, if we roll our own numerical library, I will have
> much less confidence. It's not that I think we are bad developers,
> it's just that the problem is quite complicated. It took a long time
> to get IEEE floating point correct, and there were some extremely
> smart people involved.

Unlike FP, Scaled integer arithmetic is easy. The main thing that we do is
addition. And that is the easiest to do.
Actually, the hard part is getting the rounding done in the right places.
A good FP package won't help there at all.

> For that reason, if we decide to drop doubles, I would rather use
> a library like gmp which has already been written/debugged rather
> than start from scratch. We've got too many other things to do.
I have no problem using gmp when Int64 is not available.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Dave Peticolas]

Richard Wackerbarth writes:
> On Fri, 16 Jun 2000, Dave Peticolas wrote:
> > Richard Wackerbarth writes:
> > > On Fri, 16 Jun 2000, Dave Peticolas wrote:
> > > > Ok, you've convinced me of the need to track 'smallest denominational
> > > > units', but not why we need to use integers rather than FP numbers.
> > > > You can round FP numbers, too. Why couldn't we just round the FP
> > > > amounts to the appropriate precision when needed? If you're worried
> > > > about the loss of accuracy, you should provide a realistic example
> > > > where the precision of 64-bit floating points is insufficient.
> > >
> > > I don't have a problem with 64 bit FP precision. However, I worry that
> > > you don't gain anything by using FP. And you do run the risk of
> > > forgetting to process the values as money rather than true reals.
> >
> > The reason why I like doubles is that a huge amount of work has gone
> > into making the IEEE floating point specification "correct". These
> > quantities are used ubiquitously and are scrutinized by many people.
> > I have great confidence that the calculations are being done
> > correctly. OTOH, if we roll our own numerical library, I will have
> > much less confidence. It's not that I think we are bad developers,
> > it's just that the problem is quite complicated. It took a long time
> > to get IEEE floating point correct, and there were some extremely
> > smart people involved.
> 
> Unlike FP, Scaled integer arithmetic is easy. The main thing that we do is
> addition. And that is the easiest to do.
> Actually, the hard part is getting the rounding done in the right places.
> A good FP package won't help there at all.

Addition may be the main thing thing, but it's not the only thing.
Even if you only do a multiplication/division/etc. once in a while,
you've still got to do it correctly.

> > For that reason, if we decide to drop doubles, I would rather use
> > a library like gmp which has already been written/debugged rather
> > than start from scratch. We've got too many other things to do.
> I have no problem using gmp when Int64 is not available.

If we're going to use gmp sometimes, we should use it all the time.
Mixing two libraries is just silly.

dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Rob Browning]

Buddha Buck <[EMAIL PROTECTED]> writes:

> I buy peaches at 3/$1.  If I buy them one at a time, each
> transaction is rounded, and I get 1 peach for $0.33.  After three
> such transactions, I've spent $0.99 for 3 peaches.  The rounding
> error accumulated in my favor.

But when is this acutally a problem in gnucash?

So far, from everything everyone's said.  I can't see one place where
switching to some home-grown fixed point solution for the actual
representation has *any* advantage over sticking with 64-bit floating
point.  The *only* practical difference I can see would be wrt
performance, and that's just not relevant these days.  People are
spending plenty of time making sure that floating point processors are
more than fast enough for our purposes.

The issue of when we need to round our values, and to what extent is
AFAICT a *completely* separable issue from whether or not we represent
them as floating point internally.  I'm sure that IEEE 64-bit floats
have far more than enough accuracy to handle any currencies we're
going to run across -- as far as currency-range values are concerned,
the IEEE-64 representation of 1.3 *is* exactly 1/3 because the lossage
is so far out to the right that you'll never see it, and even if
someone can prove me wrong there, then I maintain that the right
solution would just be to see about switching to an arbitrary
precision library, and then we'd still need to ask the same questions
about when and what to round.

So yes there may be times we need to round, but that's not related to
whether or not we use doubles as the underlying representation, and I
suspect that most often the "rounding" will be done by hand because
you'll be entering the values yourself.  If the groccery sells apples
3/dollar and you buy two, you'll get charged $0.67, and that's what
you'll enter into gnucash.

IMO

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Randolph Fritz]

On Fri, Jun 16, 2000 at 01:44:01PM -0700, Dave Peticolas wrote:
> 
> The reason why I like doubles is that a huge amount of work has gone
> into making the IEEE floating point specification "correct". These
> quantities are used ubiquitously and are scrutinized by many people.
> I have great confidence that the calculations are being done
> correctly. OTOH, if we roll our own numerical library, I will have
> much less confidence. It's not that I think we are bad developers,
> it's just that the problem is quite complicated. It took a long time
> to get IEEE floating point correct, and there were some extremely
> smart people involved.
> 
> For that reason, if we decide to drop doubles, I would rather use
> a library like gmp which has already been written/debugged rather
> than start from scratch. We've got too many other things to do.
> 

Let me point out that, so far as I know, no responsible accountant
would recommend uncorrected binary floating-point arithmetic for
bookkeeping, though it is used in economic modelling.  A system where
1% of $10 is not 10 cents is not acceptable for bookkeeping!  Interval
arithmetic  would--I
think--solve this problem, but the standard for bookkeeping is IBM's
decimal arithmetic.  A proposed version for Java, including a detailed
discussion and code can be seen at .

-- 
Randolph Fritz
Eugene, Oregon, USA

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Randolph Fritz]

On Fri, Jun 16, 2000 at 04:27:32PM -0500, Rob Browning wrote:
> 
> But when is this acutally a problem in gnucash?
> 

Every time interest is computed.

> 
> The issue of when we need to round our values, and to what extent is
> AFAICT a *completely* separable issue from whether or not we represent
> them as floating point internally.  I'm sure that IEEE 64-bit floats
> have far more than enough accuracy to handle any currencies we're
> going to run across -- as far as currency-range values are concerned,
> the IEEE-64 representation of 1.3 *is* exactly 1/3 because the lossage
> is so far out to the right that you'll never see it, and even if
> someone can prove me wrong there, then I maintain that the right
> solution would just be to see about switching to an arbitrary
> precision library, and then we'd still need to ask the same questions
> about when and what to round.
> 

There are already accounting standards in this area--they all start with
fixed-point decimal.  One of your accounting experts can probably speak
to this in more details.

-- 
Randolph Fritz
Eugene, Oregon, USA

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Rob Browning wrote:

> So far, from everything everyone's said.  I can't see one place where
> switching to some home-grown fixed point solution for the actual
> representation has *any* advantage over sticking with 64-bit floating
> point.

> The issue of when we need to round our values, and to what extent is
> AFAICT a *completely* separable issue from whether or not we represent
> them as floating point internally.

> So yes there may be times we need to round, but that's not related to
> whether or not we use doubles as the underlying representation,

I agree that the underlying representation is not the problem.
The problem is that people are bypassing the class wrapper and doing 
operations directly on these values. It is this misuse which is the problem.

For example, if I add up a series of 10,000 transactions, I must convert the
intermediate results back to "exact" money so that the error does not 
accumulate.

> I suspect that most often the "rounding" will be done by hand because
> you'll be entering the values yourself.  If the groccery sells apples
> 3/dollar and you buy two, you'll get charged $0.67, and that's what
> you'll enter into gnucash.

Well, gnucash is already messing up my brokerage account because of its 
mishandling of shares, prices, and amounts

Remember that accounting is a COUNTING 
and counting is done in integers

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Buddha Buck]

Rob Browning said...
> Buddha Buck <[EMAIL PROTECTED]> writes:
> 
> > I buy peaches at 3/$1.  If I buy them one at a time, each
> > transaction is rounded, and I get 1 peach for $0.33.  After three
> > such transactions, I've spent $0.99 for 3 peaches.  The rounding
> > error accumulated in my favor.
> 
> But when is this acutally a problem in gnucash?

This isn't...  After all, as you say below, I'd enter 0.33 for each 
peach, based on my receipt, and all is well.

But I did give another example, which you don't make reference to, 
which deals -specifically- to gnucash.

> So far, from everything everyone's said.  I can't see one place where
> switching to some home-grown fixed point solution for the actual
> representation has *any* advantage over sticking with 64-bit floating
> point.  The *only* practical difference I can see would be wrt
> performance, and that's just not relevant these days.  People are
> spending plenty of time making sure that floating point processors are
> more than fast enough for our purposes.

The main reason I have for integer/fixed point over floating point is 
because the domain of the problem is fixed point arithmetic, not 
floating point.

You are a scheme programmer, right?  I maintain that IEEE floating 
point is optimised for inexact real computations.  As such, it is an 
ideal represenation of Scheme inexact real classes.  On the otherhand, 
I also think that accounting, by it's nature, is -exact-.  As such, 
using an inexact type when a suitable exact type exists (or can be made 
to exist) is not useful.

Consider this:  The -vast- majority of operations on currency done in 
accounting are addition, with subtraction being a close second.  We 
never multiply currencies by currencies.  When we do multiply 
currencies by scalers, we -always- immediately round, so that we 
maintain the same number of decimal places.  And we also compare 
currency values -- if for no other reason than to assure that the books 
balance.We do that commonly by adding everything up and comparing 
to 0.

As a counterpoint, addition and subtraction is one of the weaknesses of 
floatingpoint numbers, whereas they are an optimised representation for 
multiplication/division.  And another traditional weakness is in 
floating point equality comparisons.  And comparisons with 0 are 
particularly prone.

> The issue of when we need to round our values, and to what extent is
> AFAICT a *completely* separable issue from whether or not we represent
> them as floating point internally.  I'm sure that IEEE 64-bit floats
> have far more than enough accuracy to handle any currencies we're
> going to run across -- as far as currency-range values are concerned,
> the IEEE-64 representation of 1.3 *is* exactly 1/3 because the lossage
> is so far out to the right that you'll never see it, and even if
> someone can prove me wrong there, then I maintain that the right
> solution would just be to see about switching to an arbitrary
> precision library, and then we'd still need to ask the same questions
> about when and what to round.

IEEE does have sufficient precision such that if rounding is done 
-consistantly-, everytime and -when- a currency value gets multiplied 
by an arbitrary double, we will likely never run into an error after 
rounding, even given the inherent problems with floating point addition 
and subtraction.  Except possibly with comparisons -- Sure, both 
$175.53/7 and $526.59/21 will both round to something that will display 
as $25.07, but are those two values internally equal?

> So yes there may be times we need to round, but that's not related to
> whether or not we use doubles as the underlying representation, and I
> suspect that most often the "rounding" will be done by hand because
> you'll be entering the values yourself.  If the groccery sells apples
> 3/dollar and you buy two, you'll get charged $0.67, and that's what
> you'll enter into gnucash.

What about the recurring transaction I mentioned in my last message?  
The transaction was a $250 payment on a loan, automatically split 
between interest (computed as a percentage of the outstanding 
principle) and the principle (computed as $250-interest)?

> 
> IMO

IMO, as well...

> 
> -- 
> Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
> 
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
> 
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Terry Boldt]

On Fri, 16 Jun 2000, you wrote:
> Richard Wackerbarth writes:
> > On Fri, 16 Jun 2000, Dave Peticolas wrote:
> > > Richard Wackerbarth writes:
> > > > On Fri, 16 Jun 2000, Dave Peticolas wrote:
> > > > > Ok, you've convinced me of the need to track 'smallest denominational
> > > > > units', but not why we need to use integers rather than FP numbers.
> > > > > You can round FP numbers, too. Why couldn't we just round the FP
> > > > > amounts to the appropriate precision when needed? If you're worried
> > > > > about the loss of accuracy, you should provide a realistic example
> > > > > where the precision of 64-bit floating points is insufficient.
> > > >
> > > > I don't have a problem with 64 bit FP precision. However, I worry that
> > > > you don't gain anything by using FP. And you do run the risk of
> > > > forgetting to process the values as money rather than true reals.
> > >
> > > The reason why I like doubles is that a huge amount of work has gone
> > > into making the IEEE floating point specification "correct". These
> > > quantities are used ubiquitously and are scrutinized by many people.
> > > I have great confidence that the calculations are being done
> > > correctly. OTOH, if we roll our own numerical library, I will have
> > > much less confidence. It's not that I think we are bad developers,
> > > it's just that the problem is quite complicated. It took a long time
> > > to get IEEE floating point correct, and there were some extremely
> > > smart people involved.
> > 
> > Unlike FP, Scaled integer arithmetic is easy. The main thing that we do is
> > addition. And that is the easiest to do.
> > Actually, the hard part is getting the rounding done in the right places.
> > A good FP package won't help there at all.
> 
> Addition may be the main thing thing, but it's not the only thing.
> Even if you only do a multiplication/division/etc. once in a while,
> you've still got to do it correctly.
> 
> > > For that reason, if we decide to drop doubles, I would rather use
> > > a library like gmp which has already been written/debugged rather
> > > than start from scratch. We've got too many other things to do.
> > I have no problem using gmp when Int64 is not available.
> 
> If we're going to use gmp sometimes, we should use it all the time.
> Mixing two libraries is just silly.
> 
> dave
> 
> --

This may not be a big deal for the total gnucash package - but using scaled
integer arthimetic for the financial calculator and amortization schedule
computations I am finalizing and getting ready to send to Dave is done totally
in double. All of the calculations can probably be done in scaled integers, but
the complexity will go up several orders of magnitude. log and exp functions
are used and would have to be rewritten to use scaled integers. I don't know
about gmp - does it contain log and exp functions. Also rewriting for scaled
integers in the calculation of interest from the other valiables. I haven't
looked closely, but from the top of my head, rewriting the Newton apprixmation
starting point alone would not be trivial and would introduce much source for
error. As long as doubles can be used - I think that staying with them would be
the best for the calculator at least - unless someone very familiar with scaler
integer arthimetic would volunteer to rewrite from the present source.  Also, I
would willing to bet that for some of the computations which are iterative in
nature, the time delay introduction would be significant. Of course we can rely
on faster H/W to alleviate the problem :-).

Of course, the calculator could remain in FP and appropriate translations done
on its input/output.

Just my two cents worth.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Dave Peticolas]

Terry Boldt writes:
> 
> This may not be a big deal for the total gnucash package - but using scaled
> integer arthimetic for the financial calculator and amortization schedule
> computations I am finalizing and getting ready to send to Dave is done totall
> in double. All of the calculations can probably be done in scaled integers, b
> the complexity will go up several orders of magnitude. log and exp functions
> are used and would have to be rewritten to use scaled integers. I don't know
> about gmp - does it contain log and exp functions.

Glancing through it's info pages, it doesn't appear to.

dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Terry Boldt wrote:

> This may not be a big deal for the total gnucash package - but using scaled
> integer arthimetic or the financial calculator and amortization schedule
> computations I am finalizing and getting ready to send to Dave is done
> totally in double.

Typically, the calculations of compounded interest, etc. are done in FP
and then multiplier by the money to yield a monetary answer.

However, in computing an amortization schedule, the periodic interest is 
computed and converted to money. Then the actual amount of principal and 
resulting balance are computed (in money) to begin the next cycle.

As a result, there will be a slightly different final payment to correct for 
the accumulated compounded rounding errors.

> Just my two cents worth.

Did you mean 1.993 cents?

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Fri, 16 Jun 2000, Dave Peticolas wrote:
> Terry Boldt writes:
> > using scaled integer arithmetic

> > log and exp functions are used and would have to be rewritten to use
> > scaled integers.

No, the only operations that you do on money are
Add money to money
Subtract money from money
Multiply money by a scalar and convert the result to money

The only log functions that I see in the financial computations
are to compute the scalar factor which is multiplied by the principal.

> I don't know about gmp - does it contain log and exp functions.

It doesn't matter. The scalar factors would be computed in FP.
Any refinement thereto can only be done by trial and error.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Stanley Long]

Richard Wackerbarth wrote:
> 
> On Fri, 16 Jun 2000, Rob Browning wrote:
> 
> > So far, from everything everyone's said.  I can't see one place where
> > switching to some home-grown fixed point solution for the actual
> > representation has *any* advantage over sticking with 64-bit floating
> > point.
> 
> > The issue of when we need to round our values, and to what extent is
> > AFAICT a *completely* separable issue from whether or not we represent
> > them as floating point internally.
> 
> > So yes there may be times we need to round, but that's not related to
> > whether or not we use doubles as the underlying representation,
> 
> I agree that the underlying representation is not the problem.
> The problem is that people are bypassing the class wrapper and doing
> operations directly on these values. It is this misuse which is the problem.
> 
> For example, if I add up a series of 10,000 transactions, I must convert the
> intermediate results back to "exact" money so that the error does not
> accumulate.
> 
> > I suspect that most often the "rounding" will be done by hand because
> > you'll be entering the values yourself.  If the groccery sells apples
> > 3/dollar and you buy two, you'll get charged $0.67, and that's what
> > you'll enter into gnucash.
> 
> Well, gnucash is already messing up my brokerage account because of its
> mishandling of shares, prices, and amounts
> 
> Remember that accounting is a COUNTING
> and counting is done in integers
>

When bankers first used mainframes, some slick programmers established
"hidden accounts" which received the tinsy fractional part of the
interest, the part lost when rounding DOWN to integer pennies ...

It wasn't much, but as it happen at the end of every day, on every
savings account ...  they made money for themselves.  A case of one
procedure for me, another for all the rest of you. :-)

Another test: 
Try to verify the finance charges on your credit card statement(s).
See if they all come up with exactly the same result for a data-set of
scattered daily purchases ??

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Bill Gribble]

Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> Assume the case where an item is priced at 3 for $2.
> For this discussion, the price NEVER changes.
> 
> Purchase one item.
> and another
> and a third
> Total cost = 3* $0.67 = $2.01
> Now purchase 3 at once. Cost = $2.00

Repeating this example doesn't make it any more relevant.  This is a
straw man.

Gnucash isn't responsible for computing how much the store charges
you; you enter $2.00, or $2.01, whichever your receipt tells you.

Buddha has repeated an example of a repeating transaction with
interest computation.  Another straw man.  It is not gnucash's job to
completely and accurately model *any* other financial process.  If you
mis-calculate an interest payment by a penny, then your repeating
transaction will be off by a penny, and you catch it in the
reconciliation step.  We should do the best job we can, but going from
a simple straightforward solution to a complicated one involving
arbitrary precision computation to fix this problem is going to need
some better support than this to get my vote.

My former employer had a rounding issue with my paycheck, which
alternated between having twenty-two and twenty-three pennies on the
amount.  Is gnucash suppsed to know without being told which month
will be .22 and which will be .23?  No.  Repeating transactions are a
convenience function.

Bill Gribble


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Sat, 17 Jun 2000, Bill Gribble wrote:

> Repeating this example doesn't make it any more relevant.  This is a
> straw man.
>
> Gnucash isn't responsible for computing how much the store charges
> you; you enter $2.00, or $2.01, whichever your receipt tells you.

But every time I make the entry, gnucash is changing the price.

THE PRICE DID NOT CHANGE. PERIOD.

If you would 
accept the price as 3 for $2.00 and 
accept that I purchased 1 and
accept that I paid $0.67,
When you stand a chance of getting it right.
The way that you neither round nor accept imbalance DOES NOT WORK.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Bill Gribble]

Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> But every time I make the entry, gnucash is changing the price.

Please describe how you made the entry you describe below.  I'd like
to try to reproduce it myself.

> If you would 
> accept the price as 3 for $2.00 and 
> accept that I purchased 1 and
> accept that I paid $0.67,

b.g.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Hendrik Boom]

> When bankers first used mainframes, some slick programmers established
> "hidden accounts" which received the tinsy fractional part of the
> interest, the part lost when rounding DOWN to integer pennies ...
> 
> It wasn't much, but as it happen at the end of every day, on every
> savings account ...  they made money for themselves.  A case of one
> procedure for me, another for all the rest of you. :-)

I heard of this story, too, back in the 70's.
Apparently the programmer inserted this into the program he was writing,
and placed the stray pennies into his own account.  (The pennies originated
from him rounding up on one end of a transaction and down on the other).

After a while, the bank wondered where their breakage was.  It seems
the bank had also been doing this themselves, and now this revenue stream
mysteriously disappeared when they automated.  They tracked down the
code, and found the programmer's bank account number...


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Rob Browning]

Randolph Fritz <[EMAIL PROTECTED]> writes:

> Every time interest is computed.

But right now we never compute interest.  You *hand enter* the value.

However, as I said before.  I agree that there are going to be times
when we need to round, but that doesn't have anything to do with the
underlying representation, as long as that representation has
sufficient range and resolution.  That's the main thing we should be
concerned about, and, as I've mentioned, IMP gmp is the right place to
start looking if we decide doubles aren't good enough.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Rob Browning]

Buddha Buck <[EMAIL PROTECTED]> writes:

> You are a scheme programmer, right?  I maintain that IEEE floating 
> point is optimised for inexact real computations.  As such, it is an 
> ideal represenation of Scheme inexact real classes.  On the otherhand, 
> I also think that accounting, by it's nature, is -exact-.  As such, 
> using an inexact type when a suitable exact type exists (or can be made 
> to exist) is not useful.

Except that there's the practical argument to be made.  *If* doubles
are for for all intents and purposes accurate enough that we wouldn't
ever notice the difference between them and a scaled integer
representation, then the current solution using doubles has the *vast*
advantage of existence and simplicity, and if doubles really are
functionally equivalent, presuming we round at the right times, they
also allow more flexibility.  If we decide we *need* to represent 1/3,
we can (more or less), whereas with the integer representation, we'd
be stuck.

> IEEE does have sufficient precision such that if rounding is done 
> -consistantly-, everytime and -when- a currency value gets multiplied 
> by an arbitrary double, we will likely never run into an error after 
> rounding, even given the inherent problems with floating point addition 
> and subtraction.  Except possibly with comparisons -- Sure, both 
> $175.53/7 and $526.59/21 will both round to something that will display 
> as $25.07, but are those two values internally equal?

In the abstract, I understand the point you're making here, and I tend
to agree with you, but I'm having a hard time thinking of a time where
an equality test like this would be meaningful.  That doesn't mean
there aren't plenty of times like that, though.

> What about the recurring transaction I mentioned in my last message?
> The transaction was a $250 payment on a loan, automatically split
> between interest (computed as a percentage of the outstanding
> principle) and the principle (computed as $250-interest)?

I would maintain that the code doing the "automatic splitting" would
be responsible for the rounding, or does that not solve the problem?

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Rob Browning]

Dave Peticolas <[EMAIL PROTECTED]> writes:

> Terry Boldt writes:
>
> >  This may not be a big deal for the total gnucash package - but
> > using scaled integer arthimetic for the financial calculator and
> > amortization schedule computations I am finalizing and getting
> > ready to send to Dave is done totall in double. All of the
> > calculations can probably be done in scaled integers, b the
> > complexity will go up several orders of magnitude. log and exp
> > functions are used and would have to be rewritten to use scaled
> > integers. I don't know about gmp - does it contain log and exp
> > functions.
>
> 
> Glancing through it's info pages, it doesn't appear to.

The power functions are there.  See mpz_pow*, and so are the square
root functions, but I don't see any logarithms available directly.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Keith Refson]

I'll copy this to the list as it's of general interest.  Herein begins 
floating-point arithmetic 101. :)

Dave Peticolas writes:
 > I wrote
 > > it is inevitable that rounding errors will accumulate when
 > > adding a large column of figures because none of the quantities being
 > > added has an exact binary fractional representation.  Rounding after
 > > addition will NOT solve this problem.
 > 
 > Why is that? I would have thought that rounding would eliminate the
 > introduced error.

Consider adding up, for example 100 (one million) identical
transactions, all for $1.01.  $1.01 can not be stored exactly -- the
nearest representation is likely to be 1.009...  In single
precision floating point this is stored to between 6 and 7 d.p.  For
the sake of argument let's say 6.  So we add 1.00 to itself one
million times.  If our processor was exact we would get the result
100.0 and NOT 101.  Clearly no rounding scheme applied after
the summation can round  100.0 to 101 without getting other
calculations badly wrong.  

That is with an ideal processor with at least 7 guard bits.
Unfortunately the situation with real processors is MUCH worse due to
the finite precision of the result.  Halfway through the calculation
the sum is

505000.0 + 1.00

which stored to 6 significant figures is

505001.0

Notice that this is correct but that we have lost .00 and this
happens on most of the additions.  So in general the result is MUCH
less than the expected one.  Try the following program on your computer

   #include 
   main()
   {
  int i;
  float r=0;
  for(i=0; i< 100; i++)
 r += 1.01;
  printf("Result = %16.4f\n",r);
   }  

Compiled using gcc on a Sun sparc I get "1003222.0".  You may
get different results on different machines, with different
optimization levels and ieee rounding modes set.  The important lesson
to learn is that although  we did our computations to 6 or 7
significant figures individually, the final result is only accurate
to 2 significant figures, and we have lost 4-5 digits of precision.

In some calculations it is quite easy to lose ALL the precision, but
even the most straightforward case of adding a list of values can
cause severe loss of accuracy.  Using double precision gives you a
little more headroom, but accuracy is not guaranteed.

Of course there are ways around this.  If you add up the numbers in a
different order you will get a different result, since floating point
arithmetic is not associative.  For example a binary sum where
numbers are added  in pairs and the cycle repeated until only one
result remains will give a more accurate answer.  Of course this
sensitivity to the order of addition may not please accountants.

This is why there is an entire field of mathematics -  numerical
analysis - devoted to devising ways of performing numerical
calculations accurately using floating-point computer arithmetic.  It
is far from easy and far from obvious.

Here endeth the lesson.

-- 
Dr Keith Refson,"Paradigm is a word too often used by those who would
Dept of Earth Sciences  like to have a new idea but cannot think of one." 
Parks Road,  -- Mervyn King, Deputy Governor, Bank of England
Oxford OX1 3PR, UK
Keith.Refson@   Tel: 01865 272026
 earth.ox.ac.uk Fax: 01865 272072

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Richard Wackerbarth]

On Tue, 20 Jun 2000, Keith Refson wrote:
> I'll copy this to the list as it's of general interest.  Herein begins
> floating-point arithmetic 101. :)
[snip - description of FP calculations]

> Of course there are ways around this.  If you add up the numbers in a
> different order you will get a different result, since floating point
> arithmetic is not associative.

Or we can do it the way the accountants do.
1) Use quantities that we can (and do) express EXACTLY.
2) Whenever we make an inexact calculation, IMMEDIATELY round it to an exact 
value.

> This is why there is an entire field of mathematics -  numerical
> analysis - devoted to devising ways of performing numerical
> calculations accurately 
...
> It is far from easy and far from obvious.

> Here endeth the lesson.

Well, Herr Doktor, the problem is that numerical analysis is no longer 
required study for wanna'be engineer/programmers. Neither is a historical 
perspective. Further, the youngsters of today in Western cultures are 
unwilling to accept the "respect your elders" ethic which remains in the 
Eastern cultures. As a direct result, they are bound to repeat the mistakes 
of the past.

Been there; done that, too.
... But then I grew up.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency

[Dave Peticolas]

Keith Refson writes:
> I'll copy this to the list as it's of general interest.  Herein begins 
> floating-point arithmetic 101. :)
> 
> Dave Peticolas writes:
>  > I wrote
>  > > it is inevitable that rounding errors will accumulate when
>  > > adding a large column of figures because none of the quantities being
>  > > added has an exact binary fractional representation.  Rounding after
>  > > addition will NOT solve this problem.
>  > 
>  > Why is that? I would have thought that rounding would eliminate the
>  > introduced error.
> 

> less than the expected one.  Try the following program on your computer
> 
>#include 
>main()
>{
>   int i;
>   float r=0;
>   for(i=0; i< 100; i++)
>r += 1.01;
>   printf("Result = %16.4f\n",r);
>}  
> 

I guess I should have clarified my statement. What I meant was
that you should round after each addition. Also, we are using
doubles, not floats which have much less precision.

When I run the following program:

#include 
#include 

main()
{
  double r = 0.0;
  int i;

  for(i = 0; i < 100; i++)
  {
r += 1.01;
r *= 100.0;
r  = floor(r + 0.5);
r /= 100.0;
  }

  printf("Result = %16.10f\n", r);
}  

I get: 101.00


dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

OT (was: denominating currency)

[Randolph Fritz]

On Fri, Jun 16, 2000 at 08:14:41PM -0500, Richard Wackerbarth wrote:
> 
> Did you mean 1.993 cents?
> 

I am Pentium of Borg.  Division is futile!  You will be approximated! :)

-- 
Randolph Fritz
Eugene, Oregon, USA

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency - was: non-functional 'if clause

[Richard Wackerbarth]

On Wed, 14 Jun 2000, Shimpei Yamashita wrote:

> BTW, the American dollar goes down to more than two decimal places if
> you're looking at stock quotes, because the unit there is sixteenth of a
> dollar. 
Or 1/32 or 1/256 or ...

Prices are handled differently from amounts.

The price is multiplied by the quantity and that result is adjusted to the
"integral" amount of exchange.
At one time the US used "mils" ($0.001). However, clerks worked for $1 per day
or less. With inflation, the smallest exchange is now the penny ($0.01) and
commerce is conducted in those units.

Back in the time of WWII, the Italian Lira was worth so little that they 
traded in thousands or millions of them and ignored "the change".

> But normally you would want to round at the cent level. How are
> you going to figure out which limit to apply at any given time?

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.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency - was: non-functional 'if clause

[Hendrik Boom]

> Prices are handled differently from amounts.
> 
> The price is multiplied by the quantity and that result is adjusted to the
> "integral" amount of exchange.
> At one time the US used "mils" ($0.001). However, clerks worked for $1 per day
> or less. With inflation, the smallest exchange is now the penny ($0.01) and
> commerce is conducted in those units.
...
> 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
me an exact count of pennies.

The range of integers must be greater than 32-bits, because
that would limit amounts to about #40,000,000.00.
So the obvious type is int64, which is not quaranteed to be present
by either C or glib, but often is; the less obvious type is
double, provided we make sure we only store integer values in the double
variables (i.e., frequent rounding to integral).  Thus, for display purposes,
we may have to know the primitive amount for each currency as well
as the format to be used.

-- hendrik.

I've always been doubtful about the use of floating point by gnucash.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency - was: non-functional 'if clause

[Ben Stanley]

Hendrik Boom wrote:

> I've always been doubtful about the use of floating point by gnucash.

The problem with floating point types is that they only provide an approximation to
what you want.

To go into painful detail, here's what I understand about floating point types.
The first bit past the decimal point represents 2^-1, or 1/2. The next position is
2^-2, or 1/4. And so on, for as many bits form the mantissa. The exponent just says
how far the decimal point has been moved (in base 2). The mantissa is normalised so
that it is just a fraction, being in the range -1..1.

Now, let us consider the problem of representing 0.1 (decimal) in binary
fractions.Remember that 10 (decimal) can be written as 1 * 8 + 0 * 4 + 1 * 2 + 0 *
1, which we write in binary as 1010. Binary fractions use negative powers of 2 to
do a similar thing:

1/2 = 0.5 > 0.1, so we have 0 * 2^-1.
1/4 = 0.25 > 0.1, so we have 0 * 2^-2.
1/8 = 0.125 > 0.1, so we have 0 * 2^-3.
0 * 1/2 + 0 * 1/4 + 0 * 1/8 + 1 * 1/16 = 0.0625, so we have 0.375 left over.
0 * 1/2 + 0 * 1/4 + 0 * 1/8 + 1 * 1/16 + 1 * 1/32 = 0.09375, so we have 0.00625
left over.
1/64 = 0.015625 > 0.00625, so we have 0 * 2^-6.
1/128 = 0.0078125 > 0.00625, so we have 0 * 2^-7.
1/256 = 0.00390625 <= 0.00625, so
0 * 1/2 + 0 * 1/4 + 0 * 1/8 + 1 * 1/16 + 1 * 1/32 + 0 * 1/64 + 0 * 1/128 + 1 *
1/256 = 0.09375, so we have 0.00234375 left over.

You continue with this approximating process until you run out of bits, or you have
completely converted the number. I think you will see that the remainder is getting
smaller, but it's unlikely to be matched exactly by one of the factors at our
disposal. We may approximate to as many bits as we want, but it's just that: an
approximation.

This type of number is fine in a physics calculation, where you know that the
precision of the answer will be related to the precision of the input, and you
don't mind much if the last few digits are not exactly correct. (More to the point,
you know how many are corect, and you only quote the significant figures in your
results.) However, in a financial application, we need to reliably track every last
cent (or penny, or yen, or whatever). Thus, I feel that the double type is
eminently unsuitable.

What's the solution to this problem?

I will first mention a historical solution - this probably bears little relevance
to what we should do, but anyway...

I seem to remember that the 6502 microprocessor, which was used in the C64, had a
BCD flag. When it was enabled, it entered a special mode, where all math operations
assumed that each byte held 2 decimal digits, being allowed to range from 0 to 9.
If you added 09 and 01, you got 10 (as expected), but in terms of the raw binary,
that would be 1001 + 0001 = 0001. It was inefficient on space, but
prevented rounding errors that we have seen may occur in floating point. I believe
that this mode was used by a spreadsheet.

Alternately, integers have no rounding error. However, they are susceptible to
overflow. Their range is

unsigned: 0..4,294,967,295 (2^32-1)
signed: -2,147,483,648...2,147,483,647 (2^31-1)

long long (or int64) would give us

unsigned: 0 ... 18,446,744,073,709,551,615
signed: -9,223,372,036,854,775,808 ... 9,223,372,036,854,775,807

One would think this might be enough to record the net worth of the world economy,
but perhaps someone else could comment on that. If this is insufficient, then the
multiple precision package mentioned earlier should be employed, but only if it has
an integer mode. (Aside: If we were using C++, we could substitute a portable
user-defined type for 64-bit integers on platforms which don't have builtin
compiler support, and we would not have to change any other code... It could even
be binary compatible with the int64 type.)

If we are going to change the fundamental type, what impact will this have on the
reports, and the parts of the GUI written in scheme?

Whatever we do, we should alert the user if overflow ever does occur, but it would
be nicer if it never did. (The C++ bit is nice here because overflow checking can
be incorporated into the number class.)

However, I realise that you guys like C and want to keep it that way.

Ben.



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency - was: non-functional 'if clause

[Richard Wackerbarth]

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.

> 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.

> 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.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency - was: non-functional 'if clause

[Dave Peticolas]

Richard Wackerbarth writes:
> 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 don't think this is very practical. There are well over 100
currencies in circulation and keeping track of them is not a small
task. Also, it's not just a matter of gathering the information once,
because, as someone has already pointed out, the 'primitive' amount of
a currency can change. Furthermore, gnucash also should be able to
track mutual fund shares, precious metal quantities, and anything else
of financial value that users might wish, in whatever accuracy they
want.

If the use of floating points becomes an issue, I think a better
solution would be to use an arbitrary precision library. We would
still get absolute accuracy, but we would dispense with the need to
track 'primitive units' for every currency/whatever that people might
wish to count.

dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominating currency - was: non-functional 'if clause

[Christopher Browne]

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] - 
"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]

Re: denominating currency - was: non-functional 'if clause

[Stanley Long]

Ben Stanley wrote:
> 
> Hendrik Boom wrote:
> 
> > I've always been doubtful about the use of floating point by gnucash.
> 
> The problem with floating point types is that they only provide an approximation to
> what you want.
> 
 [ snipped ]
> 
> 1/2 = 0.5 > 0.1, so we have 0 * 2^-1.
> 1/4 = 0.25 > 0.1, so we have 0 * 2^-2.
> 1/8 = 0.125 > 0.1, so we have 0 * 2^-3.
> 
 [ snipped ]

> results.) However, in a financial application, we need to reliably track every last
> cent (or penny, or yen, or whatever). Thus, I feel that the double type is
> eminently unsuitable.
> 
> What's the solution to this problem?
> 
> I will first mention a historical solution - this probably bears little relevance
> to what we should do, but anyway...
> 
> I seem to remember that the 6502 microprocessor, which was used in the C64, > had a 
>BCD flag. When it was enabled, it entered a special mode, where all 
> math operations assumed that each byte held 2 decimal digits, ...

 [ snipped ]
> 
> Alternately, integers have no rounding error. However, they are susceptible 
> to overflow. Their range is ...
> 


PL/I tried to do EVERYTHING that had been done before.
Even the subset used on CP/M boxes (ie, S-100) had integers, floating
point, and BCD (Binary-Coded-Decimal).  The subset left out Complex :-((

"money" problems could be worked in BCD, even if they were part of an
engineering calculation that was mostly floating point.  Financial
presentations meant to rank wished-for projects can be done in floating
point, even the net-present-worth stuff, because the overall
approximation is good enough. Monthly credit card interest charges may
have internal rounding, but the month end is rounded to $0.01. Corporate
Accounting departments are leary of engineers who make shortcut (but
useful :-) math routines for keeping track of money!!

Stanley Long, PE
Consulting Electrical Engineer
Anchorage, Alaska

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]