Old Man Yells At Cloud

[Steve D'Aprano]

On Sun, 17 Sep 2017 02:07 pm, Paul Rubin wrote:

> Steve D'Aprano <steve+python at pearwood.info> writes:
>>> concept               integer / integer => integer_result
>> That would be C, and C derived languages, perhaps?
> 
> Certainly not.  Fortran, machine languages, etc. all do that too.
> 
> Haskell does the right thing and makes int/int a compile time type
> error.  

Its not the right thing. Pascal did the right thing: int/int returns a floating
point value. Python does the right thing. Pocket calculators do the right
thing.

Haskell is great in many ways, but it is also obnoxiously pedantic about type
safety. At the point that the compiler won't even automatically coerce ints to
floats, but requires you to sign a release form that you take all
responsibility for it, er I mean manually do the coercion yourself, that's
excessive.

There's no reason why they couldn't have allowed int/int to return a float of
some sort, or a fraction if they want to be exact. In my arrogant opinion, its
just obnoxious, pretentious purity-beyond-all-sense to make "int / int" an
error. Its not like division on integers is undefined, its just not closed, but
lots of operations in Haskell aren't closed. The Haskell equivalent of
len(some_string) does not return a string.

To even *know* that there are branches of maths where int/int isn't defined, you
need to have learned aspects of mathematics that aren't even taught in most
undergrad maths degrees. (I have a degree in maths, and if we ever covered
areas where int/int was undefined, it was only briefly, and I've long since
forgotten it.)

There's a perfectly good, almost intuitive, understanding of int/int giving some
sort of rational value. Why don't they use it? They go so far as to provide two
pairs of division/remainder functions, differing only in their treatment of
negative values:

(x ‘quot‘ y)⋆y + (x ‘rem‘ y) == x  
(x ‘div‘  y)⋆y + (x ‘mod‘ y) == x

but can't provide an operator to do ordinary rational-valued division.


> Its integer division functions are div and quot.

quot is "integer division truncated toward zero", div is "integer division
truncated toward negative infinity".



> Python 2 does something reasonable 

Except that it isn't. It's surprising, and error prone, and was changed because
it was a bug magnet.


> and Python 3 does something that is 
> also debatably reasonable.  Switching from one reasonable thing to
> another without a very good reason is called fixing things that weren't
> broken.  Python 2 wasn't broken in that area and didn't need to be
> fixed.

Python 2 was badly broken in this area. The / operator doing integer division on
integers and true division on everything else was a constant source of pain and
silent errors. You would write a perfectly reasonable maths expression:

y = math.sin((2*x - 1)/(3*x + 1))

and test it with floats and it would work perfectly, then some day someone slips
an integer into x and you silently get garbage output, which you would probably
never even realise.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.