Hacker News Reader

Comment by wyldfire | Hacker News Reader

> For SymPy, the fact that 1/2 gives 0 in Python 2 has historically been a major source of frustration for new users.

I love Python, and I think Py3k is great. But I guess I have written too much C/C++ or something because integer division yielding integers (implicitly "with truncation") is what I would expect and not a float. And I'm a big fan of the "Principle of Least Surprise" but in this case I'm surprised to see int/int give float.

But, hey, like I said -- Py3k is a net improvement. And I'm sympathetic to new programmers and I love that Python's so popular for those new to coding.

View on HN

The integer division is more surprising in a dynamic language because it might stay undetected until the day you happen to pass round numbers to your function.

I don't think you're correct. If you, the designer, made those operands, you should expect them to be int() or float() because of how you created them. int() and float() have lots of other differences beyond just how they're treated by division.

In my experience, at some point someone will write f(x, 2) instead of f(x, 2.0). This especially happens when you are trying to debug something at the REPL. The addition of the // operator has really solved the problem and given us the best of both worlds here.

The SymPy author was explicitly talking about users. The sort of folks that use matlab, mathematica, and maple.

I don't know of any of them that expect 2 / 3 to be an integer.

And as ufo says, it creates subtle bugs because it works right on most data until you just happen to get a pair of ints. Then boom.

eg in Matlab all numbers are doubles unless you take action to make them otherwise.

Having a function/operator return different results depending on the type seems a bit insane, from a non-C/Python perspective.

> There should be one-- and preferably only one --obvious way to do it.

If I divide 1 in half, I'm left with 0.5.

There's a better way.

    (/ 2 3)   ; => 2/3
    (/ 2.0 3) ; => 0.6666667

"you, the designer" may not have created the operands, just taken them as function arguments. Sure, you should have written tests for different types of input, but if you didn't, it may surprise you later.

I think part of the "surprise" comes from Python being so versatile. I mostly use it for prototyping numerical programming in a research setting, i.e. like MATLAB. So I'm occasionally surprised by the integer division stuff, because I want to just treat my numbers as numbers and be done with it. OTOH, when I'm doing systemsy stuff, it doesn't surprise me at all.

Usually I would agree, but it is written in the context of SymPy, as symbolic math library. There I would expect 1/2 is the solution to 2*x=1 .

Whether or not SymPy gives int(1)/int(2) as a float or Python gives int(1)/int(2) as an integer are wholly different things.

In the context of a programming language, I have to agree with wyldfire that int-on-int operations should yield integers.

Now if SymPy wanted to override the base behavior, I think they absolutely should! I could even understand that the context of symbolic math makes this the least surprising outcome.

But Python is a programming language, not a Domain Specific Language.

On the other hand, 1/3 is still not the (exact) solution to 3*x=1...

But it can be done, even in systems implemented in Python 2. Try the following in http://sagecell.sagemath.org/

x = 1/3 3 * x == 1

1. I introduced the "Sage preparser", which does things like replacing "1/3" by "Integer(1)/Integer(3)" in Sage, before feeding that input to Python to be evaluated; Robert Bradshaw also did a lot of work on the preparer. The preparser uses a hook into the IPython evaluation system. I decided I really needed Sage to use a preparser like this during a talk I gave at Pycon 2005, based on audience feedback, which is why it exists.

2. I would really like somebody to remove the preparse code from Sage and make it a standalone library available on pypi. Here's the code (happy to relicense it under BSD): https://github.com/sagemath/sage/blob/master/src/sage/repl/p...

3. Permalink to your example -- http://sagecell.sagemath.org/?q=nwzdzn

It depends on what / means. Sometimes it's integer division and sometimes it isn't. (You can use // to get integer division more consistently.)

> You can use // to get integer division more consistently

Exactly. / in Python 3 now consistently means "real" division. If you intend integer division, you can explicitly say that with //.

Apart from breaking compatibility with Python 2, I don't see any reason why this isn't 100% better/clearer/more consistent.

It's funny how different backgrounds give different perspectives. When you say "real" division I think of ALUs and if it's real it's "really what you meant" when you had two integer operands. Or did you not mean "actual" when you used "real"? Did you mean like Real numbers?

I get that it's confusing and a little subtle to new folks that "1 / 2" is not the same as "1.0/2.0".

But if I wanted float division I would've coerced one or both of the operands to floats.

I think of it as "real" in the sense of accurate. 1/2 = 0 is mathematically incorrect. 1/2 = 0.5 is mathematically correct. / is a broadly used symbol for division. It should do division, not type check. That's why have 1/2 = 0.5 and 1//2 = 0. The second one is explicitly requesting a "special" form of division (truncation).

> 1/2 = 0 is mathematically incorrect. 1/2 = 0.5 is mathematically correct.

Those are two different functions, and both are "mathematically correct". The notation is the problem. The former operation isn't specifying the division operator, it's specifying an integer division operator.

So "/" actually represents two completely different functions, and to disambiguate between them you inspect the types of the operands. That works OK in statically typed languages, but Python is dynamically typed. There's no way to specify which operator you want without verbosely type-casting before each use.

So Python 3 fixes this by separating the two different functions to use different operators: "/" for Real (float) division, and "//" for integer division. Problem solved.

I agree with anything that you just said, and that's not the portion of the previous post that I had a problem with. The Python3 disambiguation is a nice way to handle the former ambiguity.

I'm aware that they are different functions, but I strongly feel they were poorly implemented. / is a mathematical symbol in addition to being a function in Python, but in Python it is implemented in a different way that is mathematically (but not pragmatically) incorrect.

> I strongly feel they were poorly implemented.

I'll agree with this. In the context of Python, the behavior is surprising.

> but in Python it is implemented in a different way that is mathematically (but not pragmatically) incorrect.

I disagree with this statement, for pedantic reasons. I wouldn't expect someone to use "/" in the context of standard arithmetic to mean integer division without explicitly redefining it, but redefining it would certainly be "mathematically correct". Look at the notation for Galois fields. That redefines all of the standard operators to work within a field of limited elements, and I'd consider the use-case to be comparable.

> Look at the notation for Galois fields. That redefines all of the standard operators to work within a field of limited elements, and I'd consider the use-case to be comparable.

Finite fields define standard operators because using mathematical operations two sets of fields is ambiguous. So I don't consider that "redefining", in the sense that they are being used unexpectedly, I consider that just defining how to use them in this special use case.

Whereas Python is defining / to do two operations: divide and truncate. I call that redefining because there's a certain expected outcome if you've had elementary math, and that's not what Python delivers.

I put real in quotes for a combination of at least the following reasons:

* "real" as in real numbers instead of integers.

* to acknowledge the fact that computer division is only ever an approximation of real numbers.

* real as in "what division actually means". Only in computers would you expect 1/2 to be 0. If you're doing math, you express that with something like floor(1/2) (don't have time to copy/paste floor bracket symbols).

"Real" is sometimes used as a synonym for "floating-point". Many programming languages uses "real" as the name for the primitive floating-point type.

Sadly this is not true. // is flooring division on integers, but real division on floats.

No, // is flooring division on floats too. It returns a float, but that float is rounded down to a whole number.

I... could've sworn. I guess I'm just flat out wrong.

Just double checked in py 3.5.0 and the double slash will do flooring division for any type. i.e. 5.0 // 4.0 returns 1.0, not 1.25.

Lisp has it right.

    * (/ 1 2)
    
    1/2

Reply on news.ycombinator.com