On Sun, 17 Sep 2017 02:07 pm, Paul Rubin wrote: > Steve D'Aprano <steve+pyt...@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. -- https://mail.python.org/mailman/listinfo/python-list
