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

[Stephen Horne]

Updating to address another issue - I figure it's better to maintain
it here in one complete lump than keep splatting bits all over the
newsgroup.

The focus is the long-term pros/cons of the new semantics, but the
relative here-and-now cost compared with alternative changes is
mentioned in several places.

Please ignore the I'm-right-you're-wrong-and-what-your-doing-is-stupid
wording - it was deliberately aimed at some similar cases from the
pro-pep side (which are not as representative as my anger led me to
percieve) but I haven't got time to fix it ATM.

Changes marked with - (deletion), + (insertion) and # (other change).


This updates are...

a.  Point 10 - to address Paul Prescods claim that integer division
    and float division are fundamentally different because of the
    existence of the remainder in integer arithmetic.

b.  Removing a couple of particularly bad bits of sarcasm and general
    nastiness.


I believe PEP0238 is wrong in principle 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.

#   The need for validation of externally sourced inputs is a
#   fundamental principle which should not be discarded just because
#   it is inconvenient.

    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 should be used to
#   dealing with subtle and insidious float approximations problems.
#   They should already be able to spot and handle the big errors
#   caused by confusing discrete integers and floats.

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

+   Float division is a clear extension of integer division. The fact
+   that it extends far enough into less-significant-digit territory
+   that remainder is rarely of interest is besides the point.
+
+   However, it could be argued that supporting the remainder for
+   floats MIGHT be useful for specific applications to determine the
+   error in specific calculations. I could even imagine it being used
+   in numerics to help track the scale of errors in different
+   evaluation methods which would, for exact evaluation, give the
+   same result but with floats do not.
+
+   There would also need to be some kind of error tracking facility
+   for other functions and operators, though, if this were to have
+   any real use - e.g. a 'this is the rounding error from adding
+   these two floats' such that a + b == c + error (where error is
+   typically extremely small, consisting of the lost-through-shifting
+   bits of the smaller of a and b in the mantissa and an appropriate
+   exponent).
+
+   However, such technicalities with floats are rarely of use in
+   float calculations - awareness of the issues and care when writing
+   sensitive expressions is the rule. Therefore I'd never suggest
+   imposing any of this on typical Python programmers.
+
+   Therefore a float division with float, float -> float, float would
+   be just as pointless as the never-asked-for integer division with
+   int, int -> int, int.

    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 arguably be treated as errors.

#   Such a change would of course cause breakage, but the breakage
#   would be immediately visible irrespective of the visibility of
#   warnings in the run-time environment (causing an exception) and
#   therefore trusted apps will never silently report wrong results.
#   This is therefore arguably a much more justifiable change than
#   changing the semantics of the division operator.