Steve Summary of views on the Is-It-Actually-Better? (was re: a use for...)

[Steve Horne]

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
others...

Because...

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
    invalid.

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
    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.

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
    problems.

    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
    necessary.

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
    confused, however.

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
concern.

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.

-- 
Steve Horne
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk