# [DB-SIG] Fixed point numbers (Result from DCOracle2 different from sqlplus)

paul@boddie.net paul@boddie.net
16 Nov 2001 12:21:41 -0000

```On Fri, 16 Nov 2001 10:46:12 +0100 "M.-A. Lemburg" <mal@lemburg.com> wrote:
>
>How strong is the need for a fixed point data type ?

For convenient handling of financial information, I would claim that it's a
very strong need. It's ironic that in the PEP 238 discussions and other debates
around the implementation of Python's numerics which even got into referring to
Visual Basic's currency type, if I remember correctly, no-one really addressed
the needs of applications like these, although some people may have mentioned
the dangers of floating point numbers in financial applications.

>I'm asking because I originally started the mxNumber project to
>eventually come up with an implementation for rational numbers
>or fixed point numbers. The rational number is there (it basically
>wraps the GNU MP rational data type and thus is reasonably
>fast), the fixed point number type is still missing -- mostly
>because I'm not sure how to handle rounding/truncation "right"
>(in some sense of the word "right").
>
>Does anyone have pointers as to which logic is the most
>common ?

Well, as you can see in the documentation that I referred to in my previous
message, the way that integers behave when implicitly rounded (in division) is
surprising, if not shocking, and any justification for it should really lead to
calling the Python integer type something else like "index". What I did in my
implementation is to follow commonly-believed basic arithmetic conventions; so,
for the ScaledDecimal class any rounding is done towards zero, whereas for
Python integer arithmetic such rounding is done towards minus infinity.

Operations involving ScaledDecimal objects tend to extend the precision until
such a time as either rounding or conversion to integer is done. The reason for
deferring rounding or truncation is that it isn't always clear that such things
are wanted by the programmer; I suppose one could have an option which
truncates or rounds after every operation - it would be the equivalent
of "autocommit" for numbers. ;-)

>Note that a fixed point type wouldn't be hard to do with
>Python's long implementation: you'd just have to keep an
>additional integer around which then defines the location
>of the decimal point.

That's pretty much what I do, yes.

Regards,

Paul

--