[Python-Dev] Fixed-point numeric type

[Tim Peters]

[Ka-Ping Yee]
> Methods named "set-whatever" are typically understood to change a
> component of something.  If this must be done with a method, the method
> should be called something like "with_scale(x)" instead of
"set_scale(x)".\

I still like set_precision().  You ignore that this module has happy
users -- I know that the current names make sense to them.  I don't know
that abstract arguments will.

> But i think the method is unnecessary -- the constructor already
> provides a perfectly good way to make a new number with an altered
> precision, so why provide a second way to do the same thing?  There
> should be OOWTDI.

It's a dedicated method for a common case.  I doubt many (if any) current
module users realize that precision can be changed via the constructor, and
doing it that way seems strained even to me.  Presumably you would be
happier then if the constructor lost this ability.

> ...
> That's not an argument that 'precision' is the right name.  That's
> just a claim that we can confuse people into believing that 'precision'
> is not so bad.

I don't care whether it's "right", I only care that it's proven itself to
work in practce.

> ...
> The attribute we're talking about represents something *completely
> different*.

As I said before, existing users have had no problems with this.


>>>     (b) Set rounding function as an attribute of the number.

>> Bleech.

> Can you, er, elaborate?

Desired rounding is a function of the operand(s) and the operation they're
combined with.  The idea that there's a "round to even" 4.1 and a "add a
half and chop" 4.1 is simply bizarre.  It would make *some* kind of sense to
say there are "round to even" and "add a half and chop" flavors of the
addition operator, but then that multiplies too.  Real apps overwhelmingly
want "round to even" on every operation over some stretch, or overwhelmingly
want "add a half and chop" rounding on every operation over some stretch.

> And, can we reduce the issue to the rounding mode?  Can we agree on
> no global mutable default precision, at least?

FixedPoint never had global mutable default precision, and I don't believe
Doug added it.  The default precision is 2, period.  Cowlishaw's proposal
has other kinds of "input state", though.

> ...
> I'm assuming we both believe that people will want to adjust rounding
> modes more often with fixed-point than with floating-point.

I don't, at least not in a problematic sense.  A commerical app has to
adhere to financial rounding rules that, like time zone rules, are often
more informed by arbitrary political foolishness than sense.  I expect the
typical case is for an app to set the rounding mode once at its start, and
never change it again.

> The question is what happens to people who do mess with such things.
> Should such people find interoperability impossible, or merely tedious?

Tedious, surprising, and error-prone, but easy and pleasant for most people
most of the time.

> ...
> I feel pretty hard-line about the default precision, but i may be willing
> to concede the rounding issue if you have a good story for
interoperability.

There isn't a "default precision issue" that I can see, unless you object to
the current default of 2; if "interoperability" is a real issue I expect
that one of the module's users might have mentioned it by now <wink>.