Deposing Dictators

[Stephen Horne]

On Sun, 05 Aug 2001 17:49:07 GMT, "Terry Reedy" <tjreedy at home.com>
wrote:

I stated this all elsewhere, but I suppose it won't hurt once more.

>"Stephen Horne" <steve at lurking.demon.co.uk> wrote in message
>news:56fqmtcl20tg64aradbnarkj9kl514kg67 at 4ax.com...

>StatusQuo Viewpoint: Integers are algebraically distinct from
>rationals/reals and all operations thereon should produce an integer.
>/ is a convenient abbreviation for divmod[0].  (Counterpoint: // is
>almost as convenient.)

Convenience for new code is not the issue. The old code is already
written, and there is a lot of it.

>Change Viewpoint: Ints are embedded subset of floats, included
>separately for efficiency reasons.  Numerical expressions should give
>numerically equivalent answers when fed numerically equivalent inputs.
>(Do you really disagree that this is desirable?).  They do not now
>when / is used (and thus current / is design mistake).  They will in
>the future when either / or // is used.

Mathematicians are quite happy with the concept that working in the
domain of integers is different to working in the domain of reals. It
is not an efficiency consideration, they are fundamentally different
domains. In mathematics, the same notation with the same arguments
gives a different result depending on the context. In Python today, we
denote that context with the type of the arguments. What is the
problem?

1 is not equivalent to 1.0 - the '1 == 1.0' returns a true result only
because types are coerced. '1 is 1' returns true, but '1 is 1.0'
returns false. Neither comparison has anything to do with whether the
mathematical types are the same, but I just wanted to show that the
behaviour of '==' is of no special significance.

1 has the implicit meta-data that the domain is integers. 1.0 has the
implicit meta-data that the domain is reals. Coercion of mixed types
is a convenience which has nothing to do with this - and the fact that
Python is dynamically typed has nothing to do with it either.

>StatusQuo Pragmatic: Change will break code.  (Counter: which is why a
>long transition is planned.)

Making change easier or less painful does not mean that change is
necessary. In reality, if Python had always had two division operators
I'd simply consider that a minor wart and ignore it. But this change
is going to break almost all the code I have ever written in Python.
To justify that, I want a very very good reason - not a religious
viewpoint that is easily countered with equally strong rationales for
the opposite viewpoint.

>Change Pragmatic: Ambiguity of / (what is eight/three?) leads to
>errors, *especially* in a language like Python with polymorphic
>untyped names.   Change will enable other changes in numerics system.
>(Counter: they might not be so hot either.)

If the numerics system is to change (a *GOOD* idea) then it needs to
change in a way that still allows types (or some other form of
context) to carry meta-data about the way arithmetic operators work.
At the very least there needs to be some way to say 'I am working in
the domain of integers' and 'I am working with exact values (or
limited precision approximations)'. That need not be the same as
stating the *representation* of the values - an integer representation
may well be used for an argument when the full domain of reals is
valid for results. What the new numerics system needs to do is
separate numeric representations and algorithms from the concept of
type - not discard the concept of numeric type altogether.

This can be done without breaking code. After all, '0.5' only implies
a float representation because floats are the only way we have to
express reals at present. It could be taken as a value with a real
type, and represented with a float, rational or fixed-point notation
or whatever seemed convenient to the interpreter at the time, and
still be called. '2' could continue to imply an integer type (as
opposed to an integer representation).

The domain of integers is not somehow different from other domains -
it is simply one of many possible domains to work in, and one which
happens to be very useful for most programmers. I'd suggest that the
domain of non-negative integers would be another useful domain for
programmers.

Will symbolic division have 'polynomial division' and 'polynomial
remainder' operators?

The remainder from polynomial division has nothing to do with the
remainder from integer division, except in that both forms of division
extend from the same principles (as does float division, though the
float remainder has few real-life applications hence Python providing
an integer-division-based remainder even for float arithmetic).

IMO, division should stick with one notation irrespective of the
context - the context should be made explicit either in the type of
arguments or using some form of block structure.


This opinion was stated before the revised PEP238 was written, but it
has been ignored. Guido has continued with the assertion that there is
one 'mathematically correct' division with integer division being
something completely separate, despite the fact that mathematics
itself provides no grounds for that assertion - mathematics has many
forms of division, with the choice being implicit in the context -
particularly the domain.

Take a look at my posts titled 'Steve Summary of views on the
Is-It-Actually-Better?', and tell me precisely how many issues that I
raised have actually been addressed in the revised PEP.

The revised PEP ignores many points that Guido clearly knows about
because he has replied to them. He takes his reply as definitive and
absolute despite the further counters. And, as no doubt will happen
for this post, repetition simply leads to the 'we've heard all this
before' and 'go away until you're ready to be more reasonable'
replies.


Another issue - Guido claims that arguments based on other languages
are only relevant if the reasons for those decisions are understood.
So take two well know examples where a language has been created based
on deliberation based on past languages.

Java - based on the C/C++ way, kept the same position on division.
Ada - based on Pascal/Algol style languages - specifically chose to
use a single division operator instead of two separate ones.

Of course they are statically typed - rather than dynamically typed -
languages. I don't see the argument for why dynamically typed
languages should do even more implicit coercions/casts than statically
typed ones. Surely, given that the variables are untyped, we should be
taking even more care to make sure the values have the types we expect
them to have.

>> He [Guido] is a new-born division-must-be-done-this-way-ist.
>
>How did you ever get *that* idea.  He mentioned wanting a change about
>four years ago and described the exact proposed replacement nearly
>three years ago.  (Again, see 'deja/vu').

You can be a new born Christian for a very long time. It's not the
time that's important, it is the fact that a prior belief has been
reversed. It relates to a principle called post decisional dissonance
- the psychology equivalent of the schmitt trigger. Make a decision,
and that decision seems stronger and more valid to you than before you
chose, without needing further evidence. Thus it takes more effort to
change that opinion. Now repeat the cycle - actually get someone to
reverse that opinion - and the conviction will be even stronger again.
The evolutionary purpose is simply to keep working to a single
objective unless there is good reason to change. But of course, in
psychology, a good reason to change has more to do with social
pressure than logical reasoning.

Guidos initial position when he wrote Python is not the position he
takes today. However weak the original conviction, he has taken a
definite decision now which is the opposite of that view.
Post-decisional dissonance applies, just as it does for my decision
that having multiple division operators is unnecessary and misses the
point. But I don't claim my viewpoint is so strong that it justifies a
major change to a basic arithmetic operator in a widely used language,
breaking large amounts of old code.

Guido has certainly acted appropriately in seeking ways to cussion the
blow, but IMO he has not proved that there is an adequate long term
benefit to justify the blow in the first place. I doubt that any long
term benefits even outweigh the long term costs - costs which a lot of
people seem to be pretending are non-existent.