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

[Michael McLay]

On Monday 16 December 2002 01:48 am, Tim Peters wrote:
> [Michael McLay]
>
> > ...
> > The semantics of the precision parameter may be incorrect because
> > it is only addressing the precision of the fraction part of the
> > number.
>
> That's why the module was called FixedPoint.

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. That is were I borrowed the idea of significant digits. 
Accountants tend to think that all digits are significant, down to the last 
penny.

> > Shouldn't it reflect the number of significant digits?
>
> That would be more appropriate to a floating point scheme.  Aahz has been
> working on a Python implementation of Mike Cowlishaw's hybrid proposal:
>
>     http://www2.hursley.ibm.com/decimal/
>
> for about, oh, fifteen years now <wink>.

Wow, so Aahz anticipated the creation of Python and started early. This IS a 
dedicated community.

> > ...
> >
> > >>> 3.03e5d
> >
> > 303000.00d
> >
> > The representation is incorrect. It should have returned 3.03e5d
> > but it padded the result with bogus zeros.
>
> It seems you don't really want a fixed-point type.  The FixedPoint
> constructor avoided this rat hole by making the user be explicit about the
> fixed number of fractional digits (or accept the default 2).

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. My confusion was raised by the 'e' notation seeming 
to add precision to numbers (e.g. 1.0e5 expands to 100000.0.) 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.

---snip Tim's explanation of roundoff error, thanks for the clarification--- 

> That's really representation error.  Until the distinction becomes clear,
> you'll keep believing that decimal arithmetic is somehow better <wink>.

I get the distinction now, thanks. 

---snip discussion of rationales and division errors---
> [Brett Cannon]
>
> > ...
> > It is still going to take someone to champion the module to get BDFL
> > pronouncment from Guido autonomously or get enough people to rally
> > behind to put pressure on Guido to let it in.
>
> Guido already agreed to fold FixedPoint into 2.3, provided someone other
> than me do the work <wink>.  Doug Fort has done a great job on it
> (including LaTeX docs, Fred!), and we're just missing someone with the
> time/desire to do final integration.
>
> That's independent of Michael's patch, of course.  The FixedPoint module is
> just another library module.

-- snip Tim's comments on when his stuff gets added to Python --

> If Python were to grow a native decimal type, I'd rather move to
> Cowlishaw's design, because it has the best shot at becoming a standard
> influential enough to sway HW design (decimal fp in HW wouldn't be notably
> more expensive or slower than binary fp in HW, given current chip
> capacities; this was a much bigger deal when chip real estate was scarce).

This is a very good long term goal. So for Python3k the standard numerical 
type will be Cowlishaw's decimal numbers. To bad the decNumber library from 
IBM is not open source. 

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? I could change 
the name from decimal() to FixedPoint(), but the capital letters in the name 
scream "ugly". 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? This also suggests the suffix should be changed to 'f' and 
'F' instead of 'd' and 'D'. 

> >> The syntax change is primarily to make Python more appealing to
> >> professions that require the semantics of fixed point decimal numbers.
> >
> > I understand that, but who knows how many of those types of users are
> > out there (current and potentiol).
>
> "Do applications actually use decimal data?" from Cowlishaw's FAQ should go
> a way toward answering that:
>
>     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. The data was 
taken from an analysis of applications used by Airline systems, Banking, 
Financial Analysis, Insurance, Inventory control, Management reporting, 
Marketing services, Order entry, Order processing, Pharmaceutical 
applications, and Retail sales. 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?