I think the risk of derailing this thread now is quite low, so I will make some selected comments, in an effort to reduce the misinformation and confusion which have gathered here.

**Python** has been mentioned several times but it seems you don't really understand what python's // do. Instead of making tests or try to find the answer on stack overflow, let's look at the documentation (!),

// wrote:
floor division of integers results in an integer; the result is that of **mathematical division** with the ‘floor’ function applied to the result

src.

Note my bold,

*mathematical division* is not the same as float division. Hence, in python,

**//** doesn't do the equivalent of the ahk code

floor(x/y), nor that of the python code

math.floor(x/y). I showed an example on github, from which this should be clear, explicit,

Code: Select all

```
a := 5000000000000249856
b := 5000
msgbox floor(a/b) == a//b ; 0
```

jeeswg wrote:
Great link thanks. It has some good reasons for why floor division (divide and round towards negative infinity) is more useful than integer division (divide and round towards zero).

No, he explains why

integer division in Python returns the floor of the result instead of truncating towards zero like C.

**//** does

*integer division* in python, although they call it

*floor divison* because that name matches their

*rounding* (truncation). The reason they

*round* this way is because it matches the behaviour of their modulo operator

**%**. And then he gives some reason for why their modulo operator behaves as it does.

jeeswg wrote:- I would like // in AHK v2 to behave like // in Python 3.

We'd need to change our

mod function too. These changes would complicate the implementation and degrade performance for no obvious benefit. Python added // to keep support for their integer division. The best answer I could find for why they extended the functionality to floats is

Motivation wrote:
[...]

Another reason for this change is the desire to ultimately unify Python's numeric model. This is the subject of

PEP 228 [0] (which is currently incomplete). A unified numeric model removes most of the user's need to be aware of different numerical types. This is good for beginners, but also takes away concerns about different numeric behavior for advanced programmers. (Of course, it won't remove concerns about numerical stability and accuracy.)

In a unified numeric model, the different types (int, long, float, complex, and possibly others, such as a new rational type) serve mostly as storage optimizations, and to some extent to indicate orthogonal properties such as inexactness or complexity. In a unified model, the integer 1 should be indistinguishable from the floating point number 1.0 (except for its inexactness), and both should behave the same in all numeric contexts. Clearly, in a unified numeric model, if a==b and c==d, a/c should equal b/d (taking some liberties due to rounding for inexact numbers), and since everybody agrees that 1.0/2.0 equals 0.5, 1/2 should also equal 0.5. Likewise, since 1//2 equals zero, 1.0//2.0 should also equal zero.

PEP 238 -- Changing the Division Operator

Disregarding that this

*unified numeric model* was withdrawn, our

*numeric model* is entirely different from python's. We need not support floats for this operator, but if we did, it shouldn't be

floor(x/y). I showed a formula on github which will probably yield a correct integer result for floats. I have not found a good answer to what the meaning of python's // with floats with non-zero fractions is, eg, 2.5 // 3.4.

iseahound wrote:I'm sorry but no integer division. It's not even useful, and seems to be a relic from back when we had to cast types. If anyone needs Float -> Int try one of these operators Ceil(), Round(), Floor().

It is not a relic from anything, it is one of the basic operations for the integer types, if we are supposed to support an integer type, we must support the most basic operations.

*Float -> Int* has nothing to do with this topic.

I'm against // because how would we do integer add, subtract, and multiply?

We support these operations with

**+**,

**-** and

*****.

jeeswg wrote:
if you wanted to do integer division you could use Integer.

No, converting the result from true division to integer type does not in general yield the same result as doing integer division.

Code: Select all

```
a := 5000000000000249856
b := 5000
msgbox integer(a/b) == a//b ; 0
```

Cheers.