[Python-Dev] Fixed-point numeric type

[Ka-Ping Yee]

On Wed, 5 Feb 2003, David LeBlanc wrote:
> 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.

Already covered -- read the documentation at http://fixedpoint.sf.net/.
I'm starting with what's specified there and proposing adjustments.

> Are floats and ints immutable?

Yes, and it's essential.

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

No need for methods.  Other numeric types don't have them.  (Well,
complex has .conjugate(), but that's very complex-specific.)

> > 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.

I didn't contradict your suggestion.  A default of 2 places is fine.
But there must be a fixed default; no global mutable setting.

> 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.

I believe the natural preference is round-half-to-even, also known
as "banker's rounding", which is the current default in FixedPoint.

> 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.

There must be some limit to storage precision.  If you want to avoid
propagating loss, use high precision, then round when you're done.

> > 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?

Suppose two modules use different default precisions or rounding modes,
and they set this by changing a global flag.  If you use both modules,
one will break, and it will be practically impossible to fix.

> 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 ;).

The adjustments i'm suggesting look pretty small to me: remove
mutability, remove global state.

When in doubt, simplify or remove features.  Features can be always
added later; but once a feature is in, dependencies force it to stay.


-- ?!ng