Steve Summary of views on the Is-It-Actually-Better? (was re: a use for...)
sh at ttsoftware.co.uk
Tue Jul 24 20:33:43 CEST 2001
On 24 Jul 2001 18:32:08 +1200, Paul Foley <see at below> wrote:
>On Mon, 23 Jul 2001 15:08:16 +0100, Steve Horne wrote:
>> And what do you mean *correctly* - integer division is NOT incorrect,
>It's not division, either.
>> it is the only form of division that is appropriate for integer
>> measures. If you are using inherently real measures you should use
>> floats - not integers.
>If you want integers, write floor(a,b) [or floor(a/b)], since that's
>what you really mean.
To address this issues, but also summarise my main objections to many
1. The fact that mathematicians have had many views on integers
and division, and the one that is in most non-specialist mindsets
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
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).
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
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.
3. Practically all programs use discrete integer quantities -
indices, subscripts, counters, sizes and more - whereas numerics
is a particular specialist field.
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.
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
This is much more fundamental than just switching between
different representations of continuous measures.
The pro-pep groups arbitrarily application of continuous measure
division principles with a discrete integer type is wrong in
mathematics, and it is wrong in engineering, and it is wrong in
programming. 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.
5. Having established that division on the discrete integer type
should work in the only practical way that makes sense while
not erroneously confusing the properties of discrete and
continuous measures, it makes sense for it to apply a simple
everyday convension for rounding direction - wordy and pragmatic
systems should be saved for the specialist fields where they are
6. No-one has yet explained why bugs with misusing discrete
integer types in continuous contexts cannot be detected and
handled by simple validation.
IMO, no-one can consider themselves a professional programmer if
they assume the need for validation of externally sourced inputs
does not apply to them.
If the validation requirements are too fiddly to be practical,
then that is a valid reason to consider adding new validation
syntax and semantics which could even have wider applications. It
is not a valid reason to break the widespread uses of discrete
integer division in existing code, nor to make the distinction
between discrete and continuous measures even harder to maintain
than it already is.
7. People who are really dealing with numerics and who cannot trace
down big errors caused by the buggy use of discrete integer types
in a continuous context are surely incapable of tracing down the
subtle and insidious problems caused by float approximations?
8. If you are worried about the learning curve of newbies and
students, then you should be worried about making the learning
curve faster and easier - not disguising or hiding it, and not
creating a comfort zone where you encourage bad habits while
pretending there is no principle that needs to be learned.
9. If you are dealing with 3D graphics, then you are either getting a
library or hardware interface to do the rendering for you and MOST
(but not all) of what you handle will be continuous measures
represented by floats (which obviously should not be confused with
discrete integers), or else you will be doing the rendering
yourself and you will need to handle a lot of discrete integer
mathematics AND continuous floating point mathematics. Pixels are
a discrete integer measure and they are handled using algorithms
that require discrete integers to behave as discrete integers.
Discrete and continuous principles should not be arbitrarily
10. Discrete integer division is not fundamentally different to
continuous float or rational division - continuous measures simply
use logical extensions of the same principles that apply to
discrete integers. There is no need for a different notation for
division, as mathematitians noticed long ago. The fact that
mathematicians have additional notations for floor and ceiling
which they use when necessary in specialist fields is irrelevant -
we have the capability if we need it but most of the time using a
simple convention is more practical.
Discrete and continuous types, however, are fundamentally
different things and should be kept as cleanly separate and
unconfused as possible. That is done by using different data types
for discrete and continuous data.
If anything is broken, it is in the automatic erroneous
'promotion' of discrete quantities into continuous types in many
cases, which should clearly be treated as errors.
Such a change would of course cause breakage, but we can set up
a transition procedure for that so get with the program. Obviously
it is far better to introduce code breaks that are highly visible
in that the code aborts through an exception rather than creating
insidious hidden bugs in long-time trusted code.
That just about covers it. It's pretty irritating the way I worded it
as if any alterative opinion is blatantly wrong and stupid, eh -
wonder where I learned that trick?
This is a self consistent view that explains why the proposed new
division handling is clearly rationally debatable and arguably just
wrong even in the 20-years-time case, let alone here and now. It isn't
the main issue in the here and now, but it remains a serious cause of
Adopting some method to minimise the damage at least for many Python
users and advocates may be a good thing, but please lets not just
assume the change is the right thing.
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk
More information about the Python-list