Steve Summary of views on the Is-It-Actually-Better? (was re: a use for...)
Stephen Horne
steve at lurking.demon.co.uk
Wed Jul 25 03:27:03 EDT 2001
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.
More information about the Python-list
mailing list