[Python-Dev] Fixed-point numeric type

[David LeBlanc]

> -----Original Message-----
> From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On
> Behalf Of Ka-Ping Yee
> Sent: Tuesday, February 04, 2003 22:55
> To: Raymond Hettinger
> Cc: David LeBlanc; python-dev@python.org
> Subject: [Python-Dev] Fixed-point numeric type
>
>
> I know no one asked for my opinion, but if you will indulge me
> for a moment -- i think the most important concern is to keep the
> type simple, minimal, and above all *immutable*.
>
> Thus:
>
> 1.  Prevent setting of attributes.
>
> 2.  Turn 'precision' into a read-only attribute.  To set precision,
>     just make a new number with decimal(x, new_precision).

Hmmm... and what shall the precision of 4.5 + 2.331 be? I see this as being
some sort of output attribute and not an inherent property of the stored
value.

> 3.  But don't call it 'precision'.  The word 'precision' usually
>     means either the total number of significant digits, or the
>     least significant distinguishable unit.  What we're talking
>     about (number of digits after the decimal point) is neither.
>     I believe the correct term is 'scale' (from SQL).  See also
>     http://www2.hursley.ibm.com/decimal/.

I would think that calling it what most mathematicians would call it would
be most appropriate.

> 4.  Get rid of copy(); it's unnecessary if you're immutable.

Are floats and ints immutable? This should follow the standard for existing
numeric types IMO.

> 5.  Get rid of 'frac()'.  I don't see how it would be needed
>     very often, and it's easy to do x - long(x).


> That leaves a simple immutable numeric type with no public methods
> and just one attribute -- hence the least possible burden on a
> future version of Python, if this type eventually becomes built-in.
> (And the least possible burden is a good goal in general anyway.)

No public methods? No math operators? Is this a fixed point numeric
constant?

> Also:
>
> 6.  No global mutable state.  That means no global settings for
>     default precision or rounding mode.  Either pick a standard
>     precision or always require the second constructor argument.
>     Rounding mode is a tougher problem; i see two solutions:

Disagree. there is a "natural" precision that most people would tend to use
and I think it's 2 places to the right of the decimal point. Rounding varies
according to need and, again, I think there's a "natural" preference,
although in this case I don't know what it would be.

>     (a) Eliminate variable rounding; always round half to even.

I suspect financial people would not like this. See the discussion of
banker's rounding in the doc. Ideally, as is already built, rounding should
be both defaulted and overridable by a derivative class, for example "class
money (fixedpoint):"

>     (b) Set rounding function as an attribute of the number.
>         Operators use the rounding function of the first operand.
>         This lets modules control module-local rounding behaviour
>         if they really want to do so, without interfering with
>         the rest of the program.

I thend to think that I want rounding to be a display function and not
something that effects the stored value. Otherwise you propegate rounding
loss.

> This may sound like a harsh requirement, but i am convinced that
> global mutable settings will cause nightmares for people who try
> to make their modules and programs interoperate.

How?

>                         *       *       *
>
> I know the name is a relatively small issue, but my vote would be for
> the type to be called either "fixpoint" or "decimal".  The type name
> should definitely be lowercase for something as basic as a number,
> and also lowercase if it's to be a candidate for a future built-in.
>
> Arguments for "fixpoint":
>
> F1. Shorter than "fixedpoint".  It's okay to drop "-ed", since
>     "floating point" -> "float" is accepted.
>
> F2. "fix" alone is too unspecific.
>
> F3. The important difference between "fixpoint" and "float" is that
>     the precision doesn't change.
>
> F4. Already the name of some fixed-point number packages.

I like FixedPoint, Fixedpoint or fixedpoint - whatever the capitalization of
other Python types is.

> Arguments for "decimal":
>
> D1. Simple, short, friendly.
>
> D2. The important difference between "decimal" and "float" is that
>     the fractional part is decimal.
>
> D3. Already the name of a SQL standard data type.

I suspect decimal might impact Aahz' decimal.py. I have downloaded but not
looked at it yet; but perhaps it's worthy of inclusion into Tim's package.
What does decimal imply to a user that might not be true in fixedpoint? I
resist the idea of naming it to suggest any relation with an SQL datatype
unless it precisely mimics that datatype and there's a good reason for
mimicing it in the first place!

> I think i am currently leaning toward "decimal", because D2 holds
> a few microlitres more water than F3 for me.

I am currently leaning towards running and hiding behind Tim ;)

>
> -- ?!ng

Some rather more prosaic questions:
1. Should it work on versions of Python before 2.3?
2. Are there more unit tests required that need to be added to the Python
test suite?
3. What is the procedure for getting it into the distro, both bits and docs?
4. Is the class complete? Can it be pickled? Does it play well with floats
and ints? Does it have a to/from string method?
5. Does it have an impact on other classes?
6. Does it have any impact on string format specifiers? (It should IMO.)
7. Does Tim have enough time to look over our shoulders, channel Guido and
get this done right without taking up too much of his time?

I think the idea should be to get the package into the distro and not start
a rethink/redesign at this stage - otherwise it won't appear until Python
3000 ;).

gee-this-was-supposed-to-be-easily-yours

Dave LeBlanc
Seattle, WA USA