Deposing Dictators

[Stephen Horne]

On Sun, 5 Aug 2001 17:59:53 -0400, "Tim Peters" <tim.one at home.com>
wrote:

>> I believe PEP0238 is wrong in principle because...
>>
>> 1.  The fact that mathematicians have had many views on integers
>>     and division,
>
>Factually incorrect; mathematicians have no disagreement over the meaning of
>int/int (it's a rational).

Python uses '/' as a division operator - not a way to denote
rationals. Should the Python scanner ever recognise '1/2' as a
rational literal rather than an expression containing a division
operator, maybe you'll have some justification to that claim - the
type of a rational literal clearly being rational, and thus clearly
implying working in the domain of rationals rather than integers.

Mathematicians *have* had *many* views on division, however, depending
on the particular branch of mathematics. Yes, even at least two for
integer division - allow a remainder, or disallow integer division
altogether. Division has been applied in many numeric and symbolic
domains, and each has its own set of assumptions. The remainder in
polynomial division, for instance, has an algorithmic relationship to
the remainder in integer division (the same long division algorithm is
applied in both cases) - but if you know the numeric values of the
numerator and denominator expressions and do numeric division with
those the remainder will have no relationship with the previous
polynomial division remainder - assuming the domain is reals, there
will be no remainder from the numeric division.

>>     and the one that is in most non-specialist mindsets
>
>Hard to know what this means, but the idea that the majority of
>non-specialists see "2/3" and think "0" is absurd on the face of it, if
>that's what it means.

The notation 2/3 in mathematics represents a rational number, and
therefore is not even the same type as integer 0. However...

In the domain of integers  : 2 ÷ 3 = 0 remainder 2
In the domain of rationals : 2 ÷ 3 = 2/3

>>     doesn't meet the pragmatic requirements for several fields of
>>     mathematics, is understood. That doesn't make the other
>>     definitions from less demanding, more down-to-earth fields
>>     invalid.
>
>PEP 238 retains an operator for flooring division (assuming that's what you
>mean).

I was referring to the way that some people claimed integer division
was 'wrong' division and did not exist in mathematics - a claim made
by some people because of specialist areas such as field theory, as if
field theory was the whole of mathematics. IIRC, you did not go so far
as to claim integer division is non-existent but you did claim that
all integer division requires a floor or ceiling notation just because
such notations are required in certain areas of mathematics, so you
can hardly claim to be unaware of that issue - but then maybe I'm
confusing Tims again.

>> 2.  It particularly does not invalidate the practical view which most
>>     people can easily understand, which is taught to everyone at
>>     a very early age and which also happens to work extremely well
>>     for typical programming tasks (not just specialist applications).
>
>PEP 238 doesn't dispute the utility of flooring division (assuming etc).

I was refering again to the expressed views of certain PEP238
advocates that take particular specialist fields of mathematics to be
the whole of mathematics. The word 'particularly' in English tends to
imply that you are following on from the previous point.

I am fully aware of what PEP238 says.

>>     Doesn't the pro-pep views insistence on the most pragmatic
>>     possible definition of discrete integer division seem more than a
>>     little inconsistent with their sloppy attitude to the much more
>>     fundamental difference between discrete and continuous
>>     mathematics?
>>
>>     Just because it isn't the unnecessarily pragmatic (for normal
>>     programming tasks) field of mathematics that a few people
>>     subscribe to, it doesn't make it wrong. It is simply from a less
>>     specialised, more basic and more generally useful field that
>>     doesn't address the  specialist problems of the minority over the
>>     general day-to-day practicality of the majority.
>
>If that were English, it would be easier to make a response <wink>.

Read it again. The awkwardly precise wording was forced by some people
willingness to force a wedge into the slightest imprecision in
wording.

The facts are quite simple, though. Some on the pro-PEP have tried to
use field theory as a justification for the claim that integer
division does not exist in mathematics, and should therefore be
supported only through a distinct operator. Yet they are quite happy
to lose the distinctions between numeric domains by discarding the
metadata implicit in types, apparently simply to suit the needs of
heavy users of floats and first-day programmers.

>> 3.  Practically all programs use discrete integer quantities -
>>     indices, subscripts, counters, sizes and more - whereas numerics
>>     is a particular specialist field.
>
>You've got some private definitions for these terms I was never able to
>grok.

Look them up in a kiddies math dictionary. The difference between
working in a discrete domain and working in a continuous domain are
well recognised. Loop indices, list subscripts, counters and sizes of
lists, strings and other structures are all integers, and working with
them implies working in a discrete domain - specifically the integer
domain.

>>     Making life more awkward for the majority just to suit a few
>>     specialist fields is not rational. It's the specialists dealing
>>     with specialist fields who should have to deal with awkward
>>     special case syntax and semantics - not the everyday user.
>
>The idea that a majority of non-specialists believe 2/3 means 0 has not been
>established, and IMO is almost certainly false.

Of course, in maths the rational number 2/3 is not an integer at all,
let alone zero. But the division operator, which is represented by '/'
in Python, can be used in any numeric domain except those specialist
domains (such as fields) that explicitly ban it. That includes the
integer domain in which, using a common mathematical notation, '2 ÷ 3
= 0 remainder 2' - just as in the rational domain '2 ÷ 3 = 2/3'.

>> 4.  Discrete measures and continuous measures are not the same thing
>>     and should not be arbitrarily confused.
>
>PEP 238 suggests two distinct operators in order to reduce confusion(!).

Great. Lets also have different operators for rationals when they are
added, to further reduce confusion then. After all, float arithmetic
has limited precision and we discard the remainder - different to what
is done for both integers and rationals.

Or alternately, we can carry on doing what we already do - carrying
meta-data about the numeric domain in the type of the values and not
bothering with an arbitrary range of special-case division operators.

>>     Discrete integer division makes perfect sense despite the fact
>>     that specialist fields have outlawed it for specialist reasons
>>     relating to specialist problems.
>
>Nobody has "outlawed" any meaning for division, "specialist" or otherwise.

I didn't say a meaning of division was outlawed - I said that division
itself was outlawed in certain specialist fields.

An example is field theory, which outlaws division in all fields
(except those based on modulo arithmetic with a prime base, IIRC)
because division cannot be a perfect inverse of multiplication in such
fields. That is the argument I was countering.

>>     This is much more fundamental than just switching between
>>     different representations of continuous measures.
>
>"This" doesn't appear to have a sensible referent.

The prior paragraph was...

"""
4.  Discrete measures and continuous measures are not the same thing
    and should not be arbitrarily confused. Discrete integer division
    makes perfect sense despite the fact that specialist fields have
    outlawed it for specialist reasons relating to specialist
    problems.
"""

To give a simple example, the difference between working in the
discrete integer domain and the continuous real domain is much more
fundamental than whether you use a float, rational or fixed point
representation to approximate values in the real domain.

>>     The pro-pep groups arbitrarily application of continuous measure
>>     division principles with a discrete integer type is wrong in
>>     mathematics,
>
>Factually incorrect.

Oh - so, when working in the integer domain, it is perfectly valid to
produce non-integer results then?

>>     and it is wrong in engineering,
>
>Whether it's velocity = distance/time, or voltage = watts/amps, engineers
>rarely have "discrete" division in mind.  So "wrong" is wrong here too.

Your naming of a few examples of real measures does not disprove the
existence of integer measures in engineering. Having half a support to
hold up a bridge would be pretty pointless, wouldn't it? Or how about
distributing the weight of an aircraft between its 2.7 wheels, 1.8 of
them being under the 1.4 wings? Rather naff examples, but having
worked in an engineering field for some years in the past I can assure
you that integer measures/scales/the integer domain/whatever occurs
quite frequently.

>>     and it is wrong in programming.
>
>The meaning of division a program needs depends entirely on context.  Any
>meaning is "wrong" in some programming contexts.

I said *arbitrary* application of assumptions from a particular a
particular numeric domain was wrong.

>>     My use of more practical day-to-day discrete principles for
>>     discrete integer arithmetic than would be appropriate in field
>>     theory - or even 16-year-old pure mathematics, I fully agree
>>     - is not the same thing at all.
>
>Couldn't parse that one.

It refers back again to claims made by certain pro-PEP238 people that
integer division does not exist, or always requires additional
notations which are used in certain specialist mathematical fields, or
whatever.

>> 5.  Having established that division on the discrete integer type
>>     should work in the only practical way that makes sense
>
>LOL!  I hope that was *meant* to be tongue-in-cheek.

The integer type is the only way we have to indicate we are working in
the integer domain, as (despite your best attempts to twist my words)
my message stated. But then, as you are so convinced that arithmetic
in the integer domain should be allowed to produce non-integer
results, I can see how you would find this statement laughable.
Personally, I find your suggestion laughable - you are arbitrarily
applying principles from the real domain to the integer domain where
they don't apply again.

>This is too time-consuming, Steve, and I think it's clear why you didn't get
>support for the kinds of arguments above even from the anti-PEP camp.

I absolutely agree - far too time-consuming. There are none so blind
as those who will not see. It's not even as if I'm claiming that your
view is invalid - only that the alterative view has equal validity,
and that it is possible to counter any position in support of your
viewpoint just as it is possible to counter any position in support of
mine, as is the nature of any religious debate. I'm simply
disappointed that no-one has come up with a sufficiently strong
counter that it breaks the self-consistency of my view - arguments
against my view have almost entirely relied on ignoring the meaning of
my words, and that is very tiring.

>Code breakage was and remains a strong anti-PEP argument.  You once thought
>it was supremely important to "do what other scripting languages do", but
>since the JavaScript and VB examples backfired you don't mention that claim
>anymore.  I thought that was a marginal but plausible argument, and still
>do.  No other anti-PEP argument survived my personal credibility cutoff.

I once thought it was important to consider what other programming
languages (not just scripting languages) did based on sheer numbers.
Note that's particularly not just scripting languages as a Python user
is much more likely to be using C, VB, Java or Delphi along with
Python - most are unlikely to be using loads of different scripting
languages at the same time?

I made the mistake of thinking Visual BASIC (the most used single
programming language for some time) followed the pattern of C, C++ and
Java. I was wrong, and the numbers of Visual BASIC and Delphi users
certainly make the issue uncertain. So it's not that the issue is
unimportant (though of course it is a relatively minor issue), just
that it cannot provide a clear answer in the way I once thought it
could.

I explicitly admitted my mistake when that error was pointed out.

Guido then raised the view that other languages would only be relevant
if we knew the rationale for the change. At which point I noted that
Java deliberately kept the division behaviour from C and C++ whereas
Ada deliberately changed from the two-division-operators used in
Pascal etc. That is, where a language has been created based on a
deliberate attempt to take past languages and clean them up, the only
two examples I'm aware of have shown a clear preference to division
the same way that Python currently does it. And the rationales are
available on the web if you care to look.

At that point the result was silence, and it has continued to be
silence when I re-raised it in response to another pro-PEP238
distortion similar to your "since the JavaScript and VB examples
backfired you don't mention that claim anymore" claim from above, and
in at least one other case where I reraised it quite recently.

Similarly, when someone pointed out an error in a pro-PEP238 claim
about Ruby, the result was again silence.

How many people around here have explicitly admitted they are wrong
when they are wrong?

I have on several occasions. Care to name anyone else?

The general pattern is that when I point out that working in the
integer domain is different to working in the real domain, people
accuse me of claiming that the rational 2/3 is equal to the integer 0.
And when I contradict a claim that integer division does not exist, I
get accused of claiming that PEP238 will not allow integer division.
And so on. Even when they read the words, they certainly ignore the
meaning.

>if-you-still-feel-ignored-it's-not-because-you're-ignored<wink>-ly
>    y'rs  - tim

No? - you also seem to have done a pretty good job of reading the
words and ignoring the meaning.