PEP 238 (revised)

[Bruce Sass]

On 5 Aug 2001, Marcin 'Qrczak' Kowalczyk wrote:
> Sun, 05 Aug 2001 19:56:21 +0100, Stephen Horne <steve at lurking.demon.co.uk> pisze:
>
> > In any division process where the dividend is not a multiple of the
> > divisor, there will be a remainder involved.
> > """
> >
> > This seems to imply type. If you are working in the set of reals (or
> > rationals, or complex numbers), then any divisor other than zero can
> > be multiplied by some definite value to exactly recreate the dividend.
>
> AFAIK "multiple" means integer multiple, independently of the type.
> For example 0.6 is a multiple of 0.2, and 0.7 is not.

I see too many references to (e.g.) 150%, which only makes sense as a
1.5 multiple of whatever 100% is, to believe multiple implies integer.

> > For me, -(a/b) == (-a)/b is an *obvious* identity to preserve
>
> For me, only when dealing with division without remainter. It doesn't
> necessarily hold for division with remainder. It's an evidence that
> there are two concepts called division involved.

...or, there is one concept called "division", the problems come from
trying to coerce between different representations of numbers that
live in different possible worlds (sorry, I don't now the proper
terminology, but it does appear to be a modal logic problem).

If you view it as `two concepts', you end up with a definition of
division in all possible worlds, and no guarantee that you will be
able to map "division" between them as your numbers move between the
possible worlds (i.e., when the representation changes).... so one
ends up thinking of (e.g.) "truncating" vs. "non-truncating" division
(possibly with as many "vs." pairs as there are combinations of
representations).

If you view it as a single concept, you end up translating the inputs
to a common type, doing division, then translating to the output
type... so any two numbers that can be represented with a common type
can be `divided', and the output can be of the same type as either of
the inputs or of some other type that can also be represented in that
same common type.

Of course, this is all conceptual at the users level, and doesn't
address the `least surprise' problem that PEP-238 is attacking.


I'm starting to think the re-worked numerical model is a must, and
that nothing should be done to the division operator until it is
completely worked out...  It may be the case that a single
operator, translation rules, and a way to specify the output format of
the division operation, is the more flexible and high-level way to go.

I'm torn in 0.5 by PEP-238; the motives are reasonable, but there is
really no way of knowing about the correctness of the proposed
implementation without knowing what the base numerical model is.
But, I guess that's mostly Guido's problem, since he is the one who
may end up re-writing the internals of "/" and "//" (which in my world
would just be a shortcut for (a/int/b)[0], because q,r=a/int/b,
aren't you glad I'm not a language designer ;-) to better work with a
new numerical model.


- Bruce