[Python-Dev] RE: Adding decimal (aka FixedPoint) numbers to Python

[Tim Peters]

[Michael McLay]
> Fixing the decimal place would make sense for applications having
> to do with money. That is quite different than how numbers are
> treated in scientific calculations.

Of course!  FixedPoint was written for people with fixed-point applications,
and especially for those of such who think a computer should be as good at
decimal math as their 12-year old daughter driving a $1 hand calculator
<0.500021 wink>.

> That is were I borrowed the idea of significant digits.  Accountants
> tend to think that all digits are significant, down to the last
> penny.

"The last penny" is an inherently fixed-point concept:  the last penny is
measured in units of 0.01 regardless of how many digits appear before the
decimal point.  That's what FixedPoint models directly.  The total number of
digits is unbounded, much like the national debt, but the position of the
decimal point is fixed.

> ...
> My goal is to have a new numerical type added to Python that
> satisfies the requirements for accountants and newbies.  Your
> description of fixed point seems to meet this goal.

That was its intent, but it is an expensive flavor of arithmetic, and not to
everyone's tastes.

> My confusion was raised by the 'e' notation seeming to add precision
> to numbers (e.g. 1.0e5 expands to 100000.0.)

Well, that didn't come from the FixedPoint module -- it always gives a
number of digits after the decimal point equal to the number the user tells
it to use; it doesn't try to infer anything from the form of a literal.

> This would be incorrect for reporting significant digits in scientific
> papers, but the rules for accounting math are different. This was
> simply my confusion.  FixedPoint appears to be sufficient for bankers
> and accountants.

I believe so, but IANAB and IANAA.

> ...
> This is a very good long term goal.  So for Python3k the standard
> numerical type will be Cowlishaw's decimal numbers.

Don't know.  It brings its own kinds of problems, not least of which is
sloth.

> To bad the decNumber library from IBM is not open source.

A Java implementation is open:

    http://www2.hursley.ibm.com/decimalj/

> In the short term what do you advise be done with the patch to
> add a fixed point literal and a builtin fixed point conversion
> function?

In the short term it's most important to get FixedPoint into 2.3 (under
whatever name people like).  One thing at a time is more than I can handle
these days.

> I could change the name from decimal() to FixedPoint(), but the
> capital letters in the name scream "ugly".

I don't care about the name.

> This isn't consistent with the short names used by
> the other numerical conversion functions (int, float, hex, oct...).
> Would fixed() be an acceptable name?

Make everyone unhappy and call it decimal_fixed_point() <0.9 wink>.  I'm not
sure why you might prefer fixed() to decimal(), BTW.  One reason I would is
that decimal() reminds of oct() and hex(), but would do something very
different.

> This also suggests the suffix should be changed to 'f' and
> 'F' instead of 'd' and 'D'.

-1.  'f' is a legit suffix for a float literal in C, and so much of Python's
literal syntax is identical to C's that reusing part of it to mean something
else seems a Bad Idea.

>>     http://www2.hursley.ibm.com/decimal/decifaq.html

> According to this reference the most frequent numerical column
> type used in commercial databases is decimal (55%). The float type
> is used just 1.4% of the time with the rest being split between
> Integer and SmallInt.
> ...
> Is it safe to conclude that Python will be be much more appealing
> to a huge segment of the IT market if grows a native decimal number
> type?

I've never worked in the IT market and don't know what drives them.  From
email received in response to FixedPoint, all I've gleaned is that (1) they
want arithmetic that exactly mimics whatever idiosyncratic schemes are used
by a huge variety of software systems I never heard of; and, (2) they're
unable to explain what those schemes are well enough to mimic them.  Most
people in this business have no idea what "the rules" are, they just know
that their butt is on the line if they deviate from what The Company has
been seeing for the last 20 years.  So, e.g., you get requests for flatly
insane rounding rules, like "if the fraction is over 0.4, round away from 0,
else round toward it".  Most of the time it turns out that isn't really the
rule they need, either, it's just the first one they generalized from one
example, after failing to find docs.

FixedPoint is extremely careful to give the best possible numeric result in
all cases.  I do know that isn't really what the IT market cares about --
compatability with legacy systems-- themselves incompatible with each
other --is much more important to them.  OTOH, giving the best possible
result is, as the IEEE-754 fp standard demonstrated with force in practice,
explainable, reproducible, and ultimately compelling.  That it's also
expensive is just icing on the cake <wink>.

[Michael McLay]
>> I could change the name from decimal() to FixedPoint(), but the
>> capital letters in the name scream "ugly".

[Greg Ewing]
> Worse, it would completely lose the connotation that it is a *decimal*
> number type, which surely is the main point of it in the first place!

Only to a compsci type.  The intended audience never heard of binary
fixed-point -- fixed-point means decimal to them as surely as New Zealand
means anarchy to an American <wink>.

> If it's somehow important that the name contain at least one capital
> letter,

It isn't.