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