Proposal for modifying gnucash to use exact quantities

Steven Murdoch sjmurdoch@linuxfan.com
Tue, 25 Jul 2000 16:09:01 +0100


I haven't been on this list for long, so if this has already been
discussed please accept my apologies.

One thing I was unsure about was in the gnc_numeric API was about the
handling of negative amounts, especially during rounding. I have a few
questions/suggestions about this

For Floor and Ceil there is a possible ambiguity for implementation. The
Ada 95 Reference manual[0] defines these operations in a way that I
think clears up any confusion so perhaps these could be used:

"Floor(X):  returns the largest (most positive) integral value less than
or equal to X. When X is zero, the result has the sign of X; a zero
result otherwise has a positive sign.

Ceil(X) returns the smallest (most negative) integral value greater than
or equal to X. When X is zero, the result has the sign of X; a zero
result otherwise has a negative sign when S=92Signed_Zeros is True."

This leads to a complication - do we allow zero values to have a sign.
In Ada this is an option by setting the attribute Signed_Zeros. To keep
things symmetric between floor and ceil it would be needed to have the
concept of negative zero - on so the representation would have to be
something like ones-complement, as opposed to two's complement. What do
others think?

Secondly there are the Trunc, Round, Round_Half_Up.

Truncation is fine, but the description could be more precise, again
from
the Ada 95 RM[0]

"Trunc(X) yields the value Ceil(X) when X is negative, and Floor(X)
otherwise. A zero result has the sign of X when S=92Signed_Zeros is True"=


Round and Round_Half_Up lead to problems in financial applications due
to the bias that 1/2 is always rounded in one direction, this could lead
to significant bias in some conditions.
The solution I would suggest would be to use instead the technique
called either "Banker's Rounding" or "Unbiased Rounding". In this way .5
up sometimes and down sometimes. Normally we round to the nearest even
number, so 1.5 and 2.5 round to 2, and 3.5 and 4.5 round to 4. A precise
definition can be found in the Ada 95 RM[0]:
"Unbiased_Round(X) yields the integral value nearest to X, rounding
toward the even integer if X lies exactly halfway between two integers.
A zero result has the sign of X when S=92Signed_Zeros is True."

If you wish Round and Round_Half_Up to remain in the API then may I
suggest altering the specification that in the case of a value exactly
halfway between two integers, that Round(X) rounds towards zero rather
than downwards. This only affects negative numbers, but I believe this
is more of a standard. Thus the definition could be taken from the Ada
95
RM[0]:
"Round(X) yields the integral value nearest to X, rounding away from
zero if X lies exactly halfway between two integers. A zero result has
the sign of X when S=92Signed_Zeros is True."

In a similar way Round_Half_Up could be renamed Round_Towards_Zero, or
similar, where the definition would be the opposite of Round (No
function
like this exists in Ada 95 but the description is obvious)
"Round_Towards_Zero(X) yields the integral value nearest to X, rounding
towards from zero if X lies exactly halfway between two integers. A zero
result has the sign of X when S=92Signed_Zeros is True."

For all operations I would think that Unbiased_Round should be used, so
it would be a performance issue whether any or all of the other
operations remain in the API. (I haven't though about this much, but I
would tend toward leaving them in for versatility, if the cost is low)

Many of these rounding methods have the option of giving a negative
zero, so I would be interested in knowing what other people think of
whether this should be allowed.

As for Round_Never I think the description is clear.

I should say that I am not a experienced C programmer (I'm a student
having studied Maths and Ada 95, but C soon) so if you think that I have
made a mistake then you are probably right.

I'll have a good look through the rest of the spec later, but in the
meantime I would appreciate any comments on what I have said.

Thanks,

-- =

Steven Murdoch.
email: sjmurdoch@linuxfan.com
web: http://www.bigfoot.com/~murdomania/
PGP Keys: http://www.bigfoot.com/~murdomania/contact.htm
Geek Code: http://www.bigfoot.com/~murdomania/geek.htm