[issue45736] 2to3 does not support integer division fixing

[Łukasz Langa]

Łukasz Langa  added the comment:

We don't accept new features for 3.10 anymore, and since 2to3 is deprecated, we 
won't be updating it with new fixers and so on. It is pending removal in Python 
3.13.

Sorry, I understand this is a bummer but this part of Python hasn't seen 
serious development for the past few years and its parser is incompatible with 
modern 3.9+ code.

--
nosy: +lukasz.langa
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

Change by theeshallnotknowethme :


--
versions:  -Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

Change by theeshallnotknowethme :


--
versions: +Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

theeshallnotknowethme  added the comment:

A correction to the discussion: The PR I made only fixes CONSTANT integer 
division, not any other. The left and right operands are checked for 
non-constants and then are checked for integerness (specifically checks for 
`NOT A FLOAT`s). After both checks have passed, the division operator is turned 
into a floor division operator.

--

___
Python tracker 
<https://bugs.python.org/issue45736>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

theeshallnotknowethme  added the comment:

I have put some effort to make it work for constant integers. So this

x = a ** 3 / 7

would not be changed, since it refers to a name whose value is not known.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[Eric V. Smith]

Eric V. Smith  added the comment:

I think knowing that that's integer division is beyond what 2to3 can 
accomplish. Plus, with lib2to3 being deprecated, I don't think anyone's going 
to put any effort into this.

--
nosy: +eric.smith

___
Python tracker 
<https://bugs.python.org/issue45736>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

theeshallnotknowethme  added the comment:

When 2to3 supports integer division fixing, there would be this behaviour:

- x = 2 ** 8 / 5 / 7
+ x = 2 ** 8 // 5 // 7

Basically convert any integer division to floor division. The PR I made only 
works for constant integers, and any improvement would be appreciated.

--

___
Python tracker 
<https://bugs.python.org/issue45736>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

Change by theeshallnotknowethme :


--
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

Change by theeshallnotknowethme :


--
keywords: +patch
pull_requests: +27694
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29440

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45736] 2to3 does not support integer division fixing

[theeshallnotknowethme]

New submission from theeshallnotknowethme :

Right now, 2to3 does not support integer division fixing. Supposing `test.py` 
is a file with these contents:
x = 2 ** 8 / 5 / 7

Here's an example:
C:\Users\admin> py -m lib2to3 test.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: No files need to be modified.

--
components: 2to3 (2.x to 3.x conversion tool), Library (Lib)
messages: 405857
nosy: February291948
priority: normal
severity: normal
status: open
title: 2to3 does not support integer division fixing
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue45736>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[استاذ بشير كهربائي]

Change by استاذ بشير كهربائي :


--
nosy: +ba5367125

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43116] Integer division numerical error

[Mark Dickinson]

Mark Dickinson  added the comment:

Python's `//` operator does floor division: that is, the (true) quotient is 
converted to an integer by taking the floor (rounding towards -infinity) 
instead of truncating (rounding towards zero).

So indeed it's not a bug. The behaviour is documented here: 
https://docs.python.org/3/reference/expressions.html#binary-arithmetic-operations

See also #43034

--
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43116] Integer division numerical error

[Johannes]

New submission from Johannes :

I'm a bit confused because this seems to be too obvious to be a bug:

[code]
>>> -2094820900 // 1298
-1613884
>>> -2094820900 // -1298
1613883
[/code]

Obviously there is a +/- 1 difference in the result. 

Tested with Python 3.7, 3.8 and 3.9 on Debian Bullseye. Am I missing something?

--
messages: 386204
nosy: jfu33.4
priority: normal
severity: normal
status: open
title: Integer division numerical error
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue43116>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Au Vo]

Au Vo  added the comment:

thanks for the clarification. You have been a great help. Love Python and our 
supportive community!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Mark Dickinson]

Mark Dickinson  added the comment:

>From a little more digging, it seems that Trinket's Python 2 is based on 
>Skulpt (so is a JavaScript implementation of a subset of Python), while the 
>Python 3 "trinket" connects to an Ubuntu Linux server running CPython 3.6.6.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Mark Dickinson]

Change by Mark Dickinson :


--
resolution: not a bug -> third party

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Mark Dickinson]

Mark Dickinson  added the comment:

> Unfortunately, there's little information about how Trinket is implemented. 
> Is it CPython-based?

>From a little playing around, Trinket only provides a subset of Python (one 
>might say "batteries not included"), and it's not clear what its basis is. 
>None of `sys.version_info`, `sys.platform`, `sys.float_info`, 
>`sys.float_repr_style`, `int.bit_length` or `math.fmod` was available in my 
>Python 2 tests.

1 % 0.1 gives 0.1, but 1 // 0.1 gives 10, so the invariant that Tim mentions is 
broken on Trinket.

@Au Vo: it looks as though you should take this up with the Trinket developers. 
It looks like a problem with their Python-subset implementation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Mark Dickinson]

Mark Dickinson  added the comment:

> Can you double check this, and confirm which Python version and operating 
> system you're using?

Sorry; I missed the screenshots. It looks as though you labelled those the 
wrong way around, BTW: I think "Screen Shot 2019-02-18 at 9.07.37 PM.png" is 
the Python 2 one, and it looks as though Trinket does indeed give a result of 
10 for 1 // 0.1. Unfortunately, there's little information about how Trinket is 
implemented. Is it CPython-based?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Mark Dickinson]

Mark Dickinson  added the comment:

[Au Vo]

> Python2 produces 10.0 as the answers for all of the above calculation.

Can you double check this, and confirm which Python version and operating 
system you're using? Like others, I'm not seeing any difference between Python 
2 and Python 3, and as far as I'm aware the implementation of `//` for floats 
hasn't changed between Python 2 and Python 3.

There's no behavioural bug here: all operations are producing perfectly 
correctly rounded results, which is about as good as one could possibly hope 
for. And as Tim says:

> In any case, none of this is going to change after 30 years ;-)

It's surprising, sure, but it's correct, and I can't imagine any fudge that 
would make the two results match without introducing a horde of other weird 
corner cases.

[Tim]

> For Python 3 I had thought Guido agreed to change a % b for floats to
> return an exact result (exactly equal to the mathematical a - q*b for
> some mathematical integer q) such that abs(a % b) <= abs(b)/2, which
> is most useful most often for floats.  But that didn't happen.

If it's any consolation, we do at least have `math.remainder` in Python 3.7, 
which does exactly this.

Closing this issue.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Au Vo]

Au Vo  added the comment:

Here is the Python2 screenshot from trinket.io. There are discrepancies with 
1,2,4,8,9, with 9 is given in Python2 and 10 is given in Python3. Again, sorry 
that Trinket.io does not specify which version of Python3 it implements.

--
versions: +Python 2.7 -Python 3.8
Added file: https://bugs.python.org/file48153/Screen Shot 2019-02-18 at 9.08.19 
PM.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Au Vo]

Au Vo  added the comment:

Thanks for the quick turnaround. I have done a little bit more thorough 
investigation and it does indeed the floating point that causes the behavior. 
The screenshot attached is done via Python3 from trinket.io. I will submit a 
screenshot of the Python 2 screenshot from trinket.io for comparison. Even 
though floating point is the underlying concept, Python 2 and 3 do not converge 
in the result. 

On the side note, The behavior could be more easily expressed as follows:

2// .2 == 9.0
20/.2 == 99.0

--
Added file: https://bugs.python.org/file48152/Screen Shot 2019-02-18 at 9.07.37 
PM.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Tim Peters]

Tim Peters  added the comment:

Thanks, Steven!  I'll go on to suggest that the best intro to these issues for 
Python programmers is in Python's own tutorial:

https://docs.python.org/3/tutorial/floatingpoint.html

Raymond, `divmod(a, b)[0]` IS the mathematical `floor(a/b)`, where the latter 
is computed (as if) with infinite precision.  Rounding `a/b` to a float 
_before_ taking the floor is quite different, and was never seriously 
considered for Python.  For one thing, the result is ill-defined unless you 
control the rounding mode used by HW float division (4.0 / 0.4 == 10.0 only if 
the rounding mode is to-nearest/even or to-plus-infinity; it's 1 ULP less if 
to-minus-infinity or to-zero; then taking the floor gives 10 in the former 
cases but 9 in the latter).  It makes scant sense for the result of // to 
depend on rounding mode:  the very name - "floor division" - implies rounding 
is forced.  More fundamentally,

a = (a // b)*b + (a % b)

is the invariant Guido was most keen to preserve.  In any conforming C 
implementation (by the standard today, but by best practice at the time), 
fmod(4.0, 0.4) == 0.3998 on a box with 754 doubles, and Python had 
no interest in building its own idea of "mod" entirely from scratch.  Given 
that, 4 // 0.4 has to return 9.

That said, C's fmod makes more sense for floats than Python's % (which latter 
makes more sense for integers than C's integer %), because fmod is always 
exact.  Python's float % cannot be, because it retains the sign of the modulus: 
 in, e.g., 1 % -1e100, there is no mathematical integer `n` such that the 
mathematical 1 + n*-1e100 is both negative and representable as a float.

>>> 1 % -1e100
-1e+100   # negative, but not exactly 1 + 1*-1e100
>>> math.fmod(1, -1e100)
1.0   # is exactly 1 + 0*-1e100, but not negative

In any case, none of this is going to change after 30 years ;-)  For Python 3 I 
had thought Guido agreed to change a % b for floats to return an exact result 
(exactly equal to the mathematical a - q*b for some mathematical integer q) 
such that abs(a % b) <= abs(b)/2, which is most useful most often for floats.  
But that didn't happen.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Raymond Hettinger]

Raymond Hettinger  added the comment:

The open question in my mind is which is the least surprising definition of 
a//b.  Should it be math.floor(a/b) or divmod(a,b)[0]?

The advantage of the former is that floor(a/b) is arguably the definition of 
floor division. The advantage of the latter is that a//b, a%b, and divmod(a,b) 
are consistent with one another.

FWIW, it looks like NumPy and PyPy made the same design choice as CPython:

>>> a = numpy.array([4.0, 4.0, 4.0], dtype=numpy.float64)
>>> b = numpy.array([0.4, 0.5, 0.6], dtype=numpy.float64)
>>> a / b
array([10.,  8.,  6.6667])
>>> a // b
array([9., 8., 6.])

$ pypy3
Python 3.5.3 (fdd60ed87e941677e8ea11acf9f1819466521bf2, Apr 26 2018, 01:25:35)
[PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)] on 
darwin
Type "help", "copyright", "credits" or "license" for more information.
 4.0 / 0.4
10.0
 4.0 // 0.4
9.0

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with float

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Changing the title from referring to "decimal" to "float", since this has 
nothing to do with the decimal module or Decimal type.

Like Raymond and Tim, I too cannot reproduce the claimed difference in 
behaviour between Python 2.7 and 3.x.

Au Vo, there are many resources on the web explaining why floats such as 0.4 do 
not equal exactly four tenths. One of the best (but not the easiest to 
understand) is 

What Every Computer Scientist Should Know About Floating-Point Arithmetic 

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

A more accessible (to me at least) resource is Bruce Dawson's blog:

https://randomascii.wordpress.com/category/floating-point/page/1/

although it is written from the perspective of a C programmer.

There's also a Python FAQ about it:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

--
nosy: +steven.daprano
title: Integer Division discrepancy with decimal -> Integer Division 
discrepancy with float

___
Python tracker 
<https://bugs.python.org/issue36028>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with decimal

[Tim Peters]

Tim Peters  added the comment:

"Multiple roundings" in the float code is a red herring - that's just 
implementation details trying to cheaply get the same effect as computing with 
infinite precision.  Here with actual unbounded precision:

>>> from fractions import Fraction
>>> y = Fraction(0.4)
>>> y
Fraction(3602879701896397, 9007199254740992)
>>> q = 4 / y
>>> q
Fraction(36028797018963968, 3602879701896397)
>>> int(q)
9
>>> 4 - 9 * y
Fraction(3602879701896395, 9007199254740992)
>>> float(_)
0.3998
>>> 

So exactly the same results as divmod(4, 0.4) returned.

The underlying problem here is that the infinitely precise result of 4.0 / 0.4 
is NOT an integer, in turn stemming from that the float 0.4 is not four tenths.

So I recommend to close this as not-a-bug, but I'm not doing that now because I 
want clarification on what the OP meant by saying the results differ between 
Pythons 2 and 3.  I see no differences here between Pythons 2.7.11 and 3.7.2 on 
64-bit Windows (not in 4.0 vs 0.4, or in any of the other cases the OP 
mentioned).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with decimal

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm thinking this due to having two different algorithms in play, one of which 
has multiple intermediate roundings.

* For starters, 0.4 is not exactly representable. It is stored as the binary 
fraction 3602879701896397 / 9007199254740992 represented in hex as 
0x1.ap-2

* The / true division operator is implemented in 
Objects/floatobject.c:float_div() with a single, straight division of C 
doubles: "a = a / b;"  That is giving 10.0 when rounded.

* The // floor division operator is implemented in 
Objects/floatobject.c:float_floor_div() which in turn calls float_divmod().  
The latter has a number of steps that can each have a round-off and can make 
adjustments to preserve sign logic invariants:

mod = fmod(vx, wx);
/* fmod is typically exact, so vx-mod is *mathematically* an
   exact multiple of wx.  But this is fp arithmetic, and fp
   vx - mod is an approximation; the result is that div may
   not be an exact integral value after the division, although
   it will always be very close to one.
*/
div = (vx - mod) / wx;
if (mod) {
/* ensure the remainder has the same sign as the denominator */
if ((wx < 0) != (mod < 0)) {
mod += wx;
div -= 1.0;
}
}
else {
/* the remainder is zero, and in the presence of signed zeroes
   fmod returns different results across platforms; ensure
   it has the same sign as the denominator. */
mod = copysign(0.0, wx);
}
/* snap quotient to nearest integral value */
if (div) {
floordiv = floor(div);
if (div - floordiv > 0.5)
floordiv += 1.0;
}
else {
/* div is zero - get the same sign as the true quotient */
floordiv = copysign(0.0, vx / wx); /* zero w/ sign of vx/wx */
}

I don't see how to fix the discrepancy without having float_div() depend on the 
much slower logic in float_divmod().

--
nosy: +mark.dickinson, skrah, tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with decimal

[Rémi Lapeyre]

Change by Rémi Lapeyre :


--
nosy: +remi.lapeyre

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with decimal

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I get the same results in both Python 2 and Python 3.

Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 29 2018, 20:59:26) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> 4 / 0.4
10.0
>>> 4 // 0.4
9.0
>>> 4 % 0.4
0.3998
>>> divmod(4, 0.4)
(9.0, 0.3998)


Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license()" for more information.
>>> 4 / 0.4
10.0
>>> 4 // 0.4
9.0
>>> 4 % 0.4
0.3998
>>> divmod(4, 0.4)
(9.0, 0.3998)

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36028] Integer Division discrepancy with decimal

[Au Vo]

New submission from Au Vo :

In Python3, there is a discrepancy of integer division with decimal. 
Considering these two examples:

4/ .4 ==10.0. But 4//.4== 9.0 
Furthermore:

2//.2 == 9.0
3//.3 ==10.0
5//.5 ==10.0
6//.6 ==10.0

All answers should be 10.0? The problem is in Python3 and not in Python2. 
Python2 produces 10.0 as the answers for all of the above calculation. Is it a 
rounding out issue?

--
messages: 335863
nosy: Au Vo
priority: normal
severity: normal
status: open
title: Integer Division discrepancy with decimal
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue36028>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Question about slight deviations when using integer division with large integers.

[Christian Seberino]

Thanks to all who helped.  As was previously pointed out, many other languages
use truncation rather than rounding for // division.

Getting the behavior you want may be as easy as replacing // with the int()
function


>>> x = 9 ; y = 2

>>> x // y, -x // y, (-x) // y
(4, -5, -5)

>>> int(x / y), -int(x / y), int(-x / y)
(4, -4, -4)

Hope that helps.

Chris
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Paul Moore]

On Mon, 31 Dec 2018 at 09:00, Christian Seberino  wrote:
>
> Thanks.  I didn’t post new code.  I was just referring back to original
> post.  I need to duplicate the exact behavior of Java’s BigIntegers.
>
> I’m guessing difference between Java and Python is that Java BigIntegers do
> not switch to floor for negatives.

Presumably Java BigInteger division consistently rounds to zero,
whereas Python's // operator consistently rounds down.

> Possible to tweak rounding of Python to be like Java?

The correct answer is to have your developers understand the behaviour
of the language they are using, and not assume it's like another
language that they are more familiar with. But I appreciate that's not
always easy. So what you are looking for are ways to help your
developers avoid errors.

Python doesn't have any way to change the behaviour of the //
operator. I assume Java doesn't have a way to make BigInteger division
round down, either?

I doubt that using a custom-defined class in Python would help much -
developers would likely not use it, unless they understood the reason
for it (at which point, they wouldn't need it!). Code reviews,
focusing on the use of the // operator, might be an answer (hopefully
only needed short term until your developers understood the different
behaviours of Java and Python). Or maybe some form of coding
convention (all uses of // must be covered by unit tests that check
all combinations of signs of the 2 operands). Or maybe a function
java_style_divide(), that your conventions mandate must be used in
preference to //

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Cameron Simpson]

On 30Dec2018 23:33, Christian Seberino  wrote:

Thanks.  I didn’t post new code.  I was just referring back to original
post.


I think Ian looked up the first post on Google Groups, where your code 
was evident. The message was incomplete when it got here (the mailing 
list); I don't know why.



I need to duplicate the exact behavior of Java’s BigIntegers.
I’m guessing difference between Java and Python is that Java 
BigIntegers do

not switch to floor for negatives.
Possible to tweak rounding of Python to be like Java?


Directly but hacking the int type? Probably not. What you probably want 
to do is to make a JavaBigInteger Python class which subclasses int, and 
change its operator implementation. Eg (totally untested):


   class JavaBigInteger(int):

   def __floordiv__(self, other):
   sign = 1
   if self < 0:
   self = -self
   sign = -1
   if other < 0:
   other = - other
   sign *= -1
   result = self // other
   result *= sign
   return JavaBigOnteger(result)

i.e. convert both operands to positive values, divide, adjust the sign.

Some notes:

Changing __floordiv__ needs to have matching changes to __divmod__ and 
__mod__ because they're supposed to be consistent.


You probably also need to implement __truediv__, probably a lot like 
__floordiv__. There are also __rtruediv__ and __rfloordiv__ and __rmod__ 
and __rdivmod__.


You need to turn whatever integers you're working with into 
JavaBigIntegers to make them use the new operator methods, and those 
methods should themselves return JavaBigIntegers to keep the behaviour:


   # x and y are ints
   x = 11
   y = -2
   print(x // y)

   # you already have x and y from somewhere, eg a file
   # they are ints, make new JavaBigIntegers from them
   xj = JavaBigInteger(x)
   yj = JavaBigInteger(y)
   print(xj // yj)

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Christian Seberino]

Thanks.  I didn’t post new code.  I was just referring back to original
post.  I need to duplicate the exact behavior of Java’s BigIntegers.

I’m guessing difference between Java and Python is that Java BigIntegers do
not switch to floor for negatives.

Possible to tweak rounding of Python to be like Java?

On Sun, Dec 30, 2018 at 11:24 PM Cameron Simpson  wrote:

> On 30Dec2018 21:14, Christian Seberino  wrote:
> >What is simplest way to make both those
> >prints give same values?  Any slicker way
> >than an if statement?
>
> If your post had an attachment, be aware that the python-list list drops
> all attachments - it is a text only list. Please paste your code
> directly into your messages so that others can easily see it.
>
> Thanks,
> Cameron Simpson 
>
-- 
___

Christian Seberino, Ph.D.
Phone: (936) 235-1139
Email: cseber...@gmail.com
___
-- 
https://mail.python.org/mailman/listinfo/python-list

Question about slight deviations when using integer division with large integers.

[Christian Seberino]

Why are the following two similar prints slightly different and how fix?

>>> x = 0x739ad43ed636

>>> print(x + (-x) // 2048)
127046758190683

>>> print(x - x // 2048)
127046758190684

I'm working in an area where such deviations matter.  It would nice to 
understand what is happening.  

Any help greatly appreciated.

cs
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Ian Kelly]

On Sun, Dec 30, 2018 at 10:18 PM Christian Seberino  wrote:
>
> What is simplest way to make both those
> prints give same values?  Any slicker way
> than an if statement?

Stack Overflow has a few suggestions:
https://stackoverflow.com/questions/19919387/in-python-what-is-a-good-way-to-round-towards-zero-in-integer-division
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Chris Angelico]

On Mon, Dec 31, 2018 at 6:36 PM Ian Kelly  wrote:
>
> The Google group has an initial post in this thread that didn't make it
> through to the mailing list for whatever reason. For posterity, here
> it is:

Thanks Ian.

> > Why are the following two similar prints slightly different and how fix?
> >
> > >>> x = 0x739ad43ed636
> >
> > >>> print(x + (-x) // 2048)
> > 127046758190683
> >
> > >>> print(x - x // 2048)
> > 127046758190684
> >
> > I'm working in an area where such deviations matter.  It would nice to 
> > understand what is happening.

This is a distinctly different order of operations. Remember from
grade school that division is done before addition and subtraction;
the first one will calculate (-x)//2048 and then add that onto x, and
the second will calculate x//2048 and then subtract that from x. As
has already been pointed out, Python's // operator is *floor
division*, meaning that it will always round down, whether the number
is positive or negative.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Ian Kelly]

On Sun, Dec 30, 2018 at 10:27 PM Cameron Simpson  wrote:
>
> On 30Dec2018 21:14, Christian Seberino  wrote:
> >What is simplest way to make both those
> >prints give same values?  Any slicker way
> >than an if statement?
>
> If your post had an attachment, be aware that the python-list list drops
> all attachments - it is a text only list. Please paste your code
> directly into your messages so that others can easily see it.

The Google group has an initial post in this thread that didn't make it
through to the mailing list for whatever reason. For posterity, here
it is:

> Why are the following two similar prints slightly different and how fix?
>
> >>> x = 0x739ad43ed636
>
> >>> print(x + (-x) // 2048)
> 127046758190683
>
> >>> print(x - x // 2048)
> 127046758190684
>
> I'm working in an area where such deviations matter.  It would nice to 
> understand what is happening.
>
> Any help greatly appreciated.
>
> cs
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Cameron Simpson]

On 30Dec2018 21:14, Christian Seberino  wrote:

What is simplest way to make both those
prints give same values?  Any slicker way
than an if statement?


If your post had an attachment, be aware that the python-list list drops 
all attachments - it is a text only list. Please paste your code 
directly into your messages so that others can easily see it.


Thanks,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Christian Seberino]

What is simplest way to make both those 
prints give same values?  Any slicker way 
than an if statement?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Chris Angelico]

On Mon, Dec 31, 2018 at 1:56 PM Christian Seberino  wrote:
>
> Perhaps the "secret" is *not* do integer division with negative numbers?

I have no idea what you're replying to, but integer division with
negative numbers IS well defined. Python will floor - it will always
round down.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about slight deviations when using integer division with large integers.

[Christian Seberino]

Perhaps the "secret" is *not* do integer division with negative numbers?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Grobu]

On 22/01/16 04:48, Steven D'Aprano wrote:
[ ... ]


math.trunc( float(a) / b )



That fails for sufficiently big numbers:


py> a = 3**1000 * 2
py> b = 3**1000
py> float(a)/b  # Exact answer should be 2
Traceback (most recent call last):
   File "", line 1, in 
OverflowError: long int too large to convert to float


Note that Python gets the integer division correct:

py> a//b
2L


And even gets true division correct:

py> from __future__ import division
py> a/b
2.0


so it's just the intermediate conversion to float that fails.



Thanks! I did see recommandations to avoid floats throughout the thread, 
but didn't understand why.


Following code should be exempt from such shortcomings :

def intdiv(a, b):
return (a - (a % (-b if a < 0 else b))) / b


--
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Grobu]

def intdiv(a, b):
 return (a - (a % (-b if a < 0 else b))) / b




Duh ... Got confused with modulos (again).

def intdiv(a, b):
return (a - (a % (-abs(b) if a < 0 else abs(b / b

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Jussi Piitulainen]

Grobu writes:

>> def intdiv(a, b):
>>  return (a - (a % (-b if a < 0 else b))) / b
>>
>>
>
> Duh ... Got confused with modulos (again).
>
> def intdiv(a, b):
> return (a - (a % (-abs(b) if a < 0 else abs(b / b

You should use // here to get an exact integer result.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Grobu]

On 23/01/16 16:07, Jussi Piitulainen wrote:

Grobu writes:


def intdiv(a, b):
  return (a - (a % (-b if a < 0 else b))) / b




Duh ... Got confused with modulos (again).

def intdiv(a, b):
 return (a - (a % (-abs(b) if a < 0 else abs(b / b


You should use // here to get an exact integer result.



You're totally right, thanks! It isn't an issue for Python 2.x's 
"classic division", but it becomes one with Python 3's "True division", 
and '//' allows to play it safe all along.

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Jussi Piitulainen]

Steven D'Aprano writes:

> So my guess is that the fastest, and certainly the most obvious, way
> to get the same integer division behaviour as C99 would be:
>
> def intdiv(a, b):
>     # C99 style integer division with truncation towards zero.
> n = a//b
> if (a < 0) != (b < 0):
> n += 1
> return n

You should only increment if there is a (non-zero) remainder.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Steven D'Aprano]

On Thu, 21 Jan 2016 08:11 pm, Ben Finney wrote:

> Shiyao Ma <i...@introo.me> writes:
> 
>> I wanna simulate C style integer division in Python3.
> 
> I'm not sure I know exactly what behaviour you want (“C style” may mean
> different things to each of us).

Surely is means "whatever the C standard defines integer division to mean".

Are their any C programmers here who can tell us what the C standard says?

According to this:

http://stackoverflow.com/questions/3602827/what-is-the-behavior-of-integer-division-in-c

the behaviour of integer division was implementation dependent in C89, but
has now been specified in detail since C99. The answer is that a/b for
integers a and b *truncate towards zero*. That is, it returns the integer
part with no fractional part:

Both arguments are positive, or both negative:

11/2 = 5.5 so throw away the 0.5 and return 5

-11/-2 = 5.5 so throw away the 0.5 and return 5

One argument is positive and the other negative:

-11/2 = -5.5 so throw away the 0.5 and return -5

11/-2 = -5.5 so throw away the 0.5 and return -5


Python's integer division // performs flooring, not truncating, so it
disagrees in the case that exactly one of the arguments are negative:

py> 11//2
5
py> -11//-2
5

py> 11//-2
-6
py> -11//2
-6


So my guess is that the fastest, and certainly the most obvious, way to get
the same integer division behaviour as C99 would be:

def intdiv(a, b):
# C99 style integer division with truncation towards zero.
n = a//b
if (a < 0) != (b < 0):
n += 1
return n



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Jussi Piitulainen]

Paul Rubin writes:

> Ben Finney writes:
>> I'm not sure I know exactly what behaviour you want (“C style” may mean
>> different things to each of us).
>
> I thought he meant trunc-division, so -5 / 2 = -2 and -5 % 2 = -1.
> Python specifies floor division but C leaves it unspecified, I thought.

I found a statement that it's specified to be truncating since C99.
Before that it was flooring or truncating.

Reading OP's code, the intention seemed clear to me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Jussi Piitulainen]

Jussi Piitulainen writes:
> Shiyao Ma writes:
>
>> I wanna simulate C style integer division in Python3.
>>
>> So far what I've got is:
>> # a, b = 3, 4
>>
>> import math
>> result = float(a) / b
>> if result > 0:
>>   result = math.floor(result)
>> else:
>>   result = math.ceil(result)
>>
>> I found it's too laborious. Any quick way?
>
> The general principle is to define a function when something is too
> laborious to do inline. def truncdiv(a, b): ...
>
> But math.trunc rounds towards 0. Maybe you want to use that here.

It's actually best to avoid floating point altogether. The following
answer by Abhijit was linked from the StackOverflow page[1] where I
found out about C99 integer division:

def trunc_div(a,b):
q, r = divmod(a,b)
if  q < 0 and r:
q += 1
return q

It adjusts a negative floored quotient towards zero if there was a
remainder.

[1] 
http://stackoverflow.com/questions/15633787/truncated-versus-floored-division-in-python?rq=1
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Ben Finney]

Shiyao Ma <i...@introo.me> writes:

> I wanna simulate C style integer division in Python3.

I'm not sure I know exactly what behaviour you want (“C style” may mean
different things to each of us).

I'll point out that Python's ‘//’ operator specifies floor division
<URL:https://docs.python.org/3/reference/expressions.html#binary-arithmetic-operations>.

-- 
 \   “Timid men prefer the calm of despotism to the boisterous sea |
  `\of liberty.” —Thomas Jefferson |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Yann Kaiser]

You can use the // operator, which should do what you want.

On Thu, Jan 21, 2016, 09:40 Shiyao Ma <i...@introo.me> wrote:

> Hi,
>
> I wanna simulate C style integer division in Python3.
>
> So far what I've got is:
> # a, b = 3, 4
>
> import math
> result = float(a) / b
> if result > 0:
>   result = math.floor(result)
> else:
>   result = math.ceil(result)
>
>
> I found it's too laborious. Any quick way?
>
> --
>
> 吾輩は猫である。ホームーページはhttps://introo.me <http://introo.me>。
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Paul Rubin]

Ben Finney  writes:
> I'm not sure I know exactly what behaviour you want (“C style” may mean
> different things to each of us).

I thought he meant trunc-division, so -5 / 2 = -2 and -5 % 2 = -1.
Python specifies floor division but C leaves it unspecified, I thought.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Oscar Benjamin]

On 21 January 2016 at 08:39, Shiyao Ma <i...@introo.me> wrote:
>
> I wanna simulate C style integer division in Python3.
>
> So far what I've got is:
> # a, b = 3, 4
>
> import math
> result = float(a) / b
> if result > 0:
>   result = math.floor(result)
> else:
>   result = math.ceil(result)
>
>
> I found it's too laborious. Any quick way?

How precise do you want to be? I think that having a negative divisor
doesn't come up much in practise but this matches in all cases anyway:

   atruncb = abs(a) // abs(b) if a * b > 0 else - (abs(a) // abs(b))

If you don't care about the negative divisor case then it becomes:

   atruncb = abs(a) // b if a > 0 else - (abs(a) // b)

Note that for integers in Python these are exact and will work for
integers of any size. Using floating point is unnecessary here and
would have overflow problems.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Jussi Piitulainen]

Shiyao Ma writes:

> I wanna simulate C style integer division in Python3.
>
> So far what I've got is:
> # a, b = 3, 4
>
> import math
> result = float(a) / b
> if result > 0:
>   result = math.floor(result)
> else:
>   result = math.ceil(result)
>
> I found it's too laborious. Any quick way?

The general principle is to define a function when something is too
laborious to do inline. def truncdiv(a, b): ...

But math.trunc rounds towards 0. Maybe you want to use that here.
-- 
https://mail.python.org/mailman/listinfo/python-list

How to simulate C style integer division?

[Shiyao Ma]

Hi,

I wanna simulate C style integer division in Python3.

So far what I've got is:
# a, b = 3, 4

import math
result = float(a) / b
if result > 0:
  result = math.floor(result)
else:
  result = math.ceil(result)


I found it's too laborious. Any quick way?

-- 

吾輩は猫である。ホームーページはhttps://introo.me <http://introo.me>。
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Peter Heitzer]

Shiyao Ma <i...@introo.me> wrote:
>Hi,

>I wanna simulate C style integer division in Python3.

>So far what I've got is:
># a, b = 3, 4

>import math
>result = float(a) / b
>if result > 0:
>  result = math.floor(result)
>else:
>  result = math.ceil(result)


>I found it's too laborious. Any quick way?
In Python3 you have to use the floor division operator '//'
For example:
result=a//b



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Marko Rauhamaa]

Jussi Piitulainen <jussi.piitulai...@helsinki.fi>:

> Steven D'Aprano writes:
>
>> So my guess is that the fastest, and certainly the most obvious, way
>> to get the same integer division behaviour as C99 would be:
>>
>> def intdiv(a, b):
>> # C99 style integer division with truncation towards zero.
>> n = a//b
>> if (a < 0) != (b < 0):
>> n += 1
>> return n
>
> You should only increment if there is a (non-zero) remainder.

Maybe:

   def intdiv(a, b):
   return a // b if (a < 0) == (b < 0) else -(-a // b)


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Jussi Piitulainen]

Marko Rauhamaa writes:

> Jussi Piitulainen writes:
>
>> Steven D'Aprano writes:
>>
>>> So my guess is that the fastest, and certainly the most obvious, way
>>> to get the same integer division behaviour as C99 would be:
>>>
>>> def intdiv(a, b):
>>> # C99 style integer division with truncation towards zero.
>>> n = a//b
>>> if (a < 0) != (b < 0):
>>> n += 1
>>> return n
>>
>> You should only increment if there is a (non-zero) remainder.
>
> Maybe:
>
>def intdiv(a, b):
>return a // b if (a < 0) == (b < 0) else -(-a // b)

Nice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Wolfgang Maier]

On 1/21/2016 15:00, Jussi Piitulainen wrote:

Steven D'Aprano writes:


So my guess is that the fastest, and certainly the most obvious, way
to get the same integer division behaviour as C99 would be:

def intdiv(a, b):
 # C99 style integer division with truncation towards zero.
 n = a//b
 if (a < 0) != (b < 0):
 n += 1
 return n


You should only increment if there is a (non-zero) remainder.



Right. Merging Steven's suggestion and fractions.Fraction.__trunc__ 
implementation I think the right answer may be:


def intdiv2(a,b):
# C99 style integer division with truncation towards zero.
if (a < 0) != (b < 0):
return -(-a // b)
else:
return a // b

Cheers,
Wolfgang


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Random832]

On Thu, Jan 21, 2016, at 09:31, Marko Rauhamaa wrote:
> Maybe:
> 
>def intdiv(a, b):
>return a // b if (a < 0) == (b < 0) else -(-a // b)

Personally, I like a // b + (a % b and a ^ b < 0) - I've done the
opposite in C to get python-style division.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Marko Rauhamaa]

Random832 :

> On Thu, Jan 21, 2016, at 09:31, Marko Rauhamaa wrote:
>> Maybe:
>> 
>>def intdiv(a, b):
>>return a // b if (a < 0) == (b < 0) else -(-a // b)
>
> Personally, I like a // b + (a % b and a ^ b < 0) - I've done the
> opposite in C to get python-style division.

Well, then there's:

def intdiv(a, b):
return int(a / b)


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Terry Reedy]

On 1/21/2016 9:56 PM, Terry Reedy wrote:

On 1/21/2016 3:39 AM, Shiyao Ma wrote:


I wanna simulate C style integer division in Python3.


There are two problems with this spec: it assumes that 'C style integer
division' is well defined and that we know the definition.  Better:

"How do I write a function 'div' in Python 3 so that the following (with
values added after each '==') is True:

all((div(1,2) == , div(-1,-2) == , dif(-1,2) == , dif(1,-2) == ))"

For '//', the values would be 0, 0, -1, -1.  If you want 0, 0, 0, 0
(truncation toward 0), then

def div(i, j):
 return (i // j) + ((i < 0) ^ (j <  0))

print(all((div(1,2) == 0, div(-1,-2) == 0,
div(-1,2) == 0, div(1,-2) == 0)))

prints 'True'.


But fails with remainder 0, as others noted.  Lesson: include corner 
cases in validation test.  Anyway, my main point about writing a clear 
spec remains true.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Matt Wheeler]

On 21 January 2016 at 21:17, Marko Rauhamaa  wrote:
> Well, then there's:
>
> def intdiv(a, b):
> return int(a / b)

That depends on how accurate you need it to be

>>> def intdiv(a, b):
...  return a//b if (a < 0) == (b < 0) else -(-a//b)
...
>>> num = 3**171
>>> num
3870210234510307998744588107535211184800325224934979257430349324033792477926791547
>>> num2 = 4**80
>>> num2
1461501637330902918203684832716283019655932542976
>>> intdiv(num, num2)
2648105301871818722187687529062555
>>> int(num/num2)
2648105301871818477801931416797184



-- 
Matt Wheeler
http://funkyh.at
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Steven D'Aprano]

On Fri, 22 Jan 2016 12:59 pm, Grobu wrote:

> On 21/01/16 09:39, Shiyao Ma wrote:
>> Hi,
>>
>> I wanna simulate C style integer division in Python3.
>>
>> So far what I've got is:
>> # a, b = 3, 4
>>
>> import math
>> result = float(a) / b
>> if result > 0:
>>result = math.floor(result)
>> else:
>>result = math.ceil(result)
>>
>>
>> I found it's too laborious. Any quick way?
>>
> 
> math.trunc( float(a) / b )


That fails for sufficiently big numbers:


py> a = 3**1000 * 2
py> b = 3**1000
py> float(a)/b  # Exact answer should be 2
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to float


Note that Python gets the integer division correct:

py> a//b
2L


And even gets true division correct:

py> from __future__ import division
py> a/b
2.0


so it's just the intermediate conversion to float that fails.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Grobu]

On 21/01/16 09:39, Shiyao Ma wrote:

Hi,

I wanna simulate C style integer division in Python3.

So far what I've got is:
# a, b = 3, 4

import math
result = float(a) / b
if result > 0:
   result = math.floor(result)
else:
   result = math.ceil(result)


I found it's too laborious. Any quick way?



math.trunc( float(a) / b )

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Terry Reedy]

On 1/21/2016 3:39 AM, Shiyao Ma wrote:


I wanna simulate C style integer division in Python3.


There are two problems with this spec: it assumes that 'C style integer 
division' is well defined and that we know the definition.  Better:


"How do I write a function 'div' in Python 3 so that the following (with 
values added after each '==') is True:


all((div(1,2) == , div(-1,-2) == , dif(-1,2) == , dif(1,-2) == ))"

For '//', the values would be 0, 0, -1, -1.  If you want 0, 0, 0, 0 
(truncation toward 0), then


def div(i, j):
return (i // j) + ((i < 0) ^ (j <  0))

print(all((div(1,2) == 0, div(-1,-2) == 0,
   div(-1,2) == 0, div(1,-2) == 0)))

prints 'True'.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Random832]

Terry Reedy  writes:
> But fails with remainder 0, as others noted.  Lesson: include corner
> cases in validation test.  Anyway, my main point about writing a clear
> spec remains true.

My validation test for this was to loop both numerator and denominator
from -5 to 5 (skipping denominator 0) to cover all cases (comparing
against the original post's unoptimized code) without having to think
about a minimal set to cover them.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

I guess there's not much to be done here.

--
resolution:  - wont fix
stage:  - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

It is hard to get fine grained error messages in _decimal, since
the errors come from libmpdec.  A clean solution would require
changes to libmpdec, and I'm reluctant to do that right now.

It is certainly possible to document DivisionImpossible etc.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

Meanwhile, the pure Python decimal versions prior to Python 3.2
have better error messages.

Right now in Python 3.3+ it is hard to import the Python version
without going into contortions, but that may be fixed in #19232.

--
dependencies: +Speed up _decimal import

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[leewz]

leewz added the comment:

Fine grained? Do you mean that the error can't be distinguished from other such 
errors? Or that it's difficult to attach the message to DivisionError? I 
thought DivisionError was always about precision.

I looked up the error in libmpdec:
This occurs and signals invalid-operation if the integer result of a 
divide-integer or remainder operation had too many digits (would be longer than 
precision). The result is [0,qNaN]. 
(http://speleotrove.com/decimal/daexcep.html)

Now I'm more confused. Though it mentions precision, it is talking about the 
*result's* precision being too large (something which shouldn't happen with 
Python's unbounded ints, right?), rather than being unable to give a sane 
answer due to not having *enough* digits. That's also what the 2.7 error is:
decimal.InvalidOperation: quotient too large in //, % or divmod

I'm very much content with documenting it, but if possible, I'd like to 
understand whether this is an issue to take up with libmpdec.

P.S.: As a side-note to others, Python floats allows float%int even when 
precision isn't high enough, and seems to always returns 0.0 with no warning. 
So behavior is inconsistent, if that's important to anyone here.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

My apologies if that wasn't clear: fine grained refers to the exception
messages.  A function can raise InvalidOperation for different reasons.

decimal.py gives a specific error message in each case. libmpdec just
signals the standard conforming InvalidOperation.

The relevant passage from the standard is here:

http://speleotrove.com/decimal/daops.html#refremain

  This operation will fail under the same conditions as integer division.

decimal.py, decNumber and libmpdec all do the same thing, so there is no
libmpdec issue other than that the error *messages* could be improved.

I fully understand if you find the behavior surprising (after all the remainder
fits in the precision), but as long as we follow the standard we can't change
that.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[leewz]

leewz added the comment:

Nah. I found it surprising at first, but like I said, it's like the computer is 
given the first 28 digits of a number and then asked to figure out the 30th 
digit.

What I'm confused about is how it fits the definition of division impossible 
given by libmpdec's docs (about the result size), and whether you're saying 
it's difficult to translate the `[class 'decimal.DivisionImpossible']` part 
to an error message.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

In the case of DivisionImpossible it would actually be possible to use
the error message 'quotient too large in //, % or divmod'.

But that's just one condition.  In the case of InvalidOperation there
are something like 30 different error messages.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Raymond Hettinger]

Raymond Hettinger added the comment:

 It is certainly possible to document DivisionImpossible etc.

This should not be done.  We've made strong efforts to not extend the Decimal 
Arithmetic Specification.

Also, the API already suffers from high complexity.  Adding more exceptions to 
the mix just makes the module harder to learn.

Instead, you are welcome to add more specific text messages to the existing 
(and standards compliant) exceptions:

   raise InvalidOperation(Not enough precision to compute the answer.)

 I found it surprising at first, but like I said, it's like 
 the computer is given the first 28 digits of a number and 
 then asked to figure out the 30th digit.

People are always surprised when their mental model conflicts with the actual 
design model.  That doesn't mean the implementation should change.

There may be a documentation issue, but then again, people who are surprised 
usually haven't studied the docs in detail.

My overall sense for this bug report is that there isn't a real problem that 
needs to be solved.  AFAICT, this particular confusion has never arisen 
before (i.e. bug reports, questions in python classes, posts on stackoverlow, 
blog posts, etc).  Likewise, the issue does not seem to have ever arisen in the 
many other non-Python implementations of the decimal spec.

I recommend that this either be closed or be limited to tweaking some of the 
error messages for existing exceptions.

--
nosy: +facundobatista, rhettinger, tim.peters
priority: normal - low
versions: +Python 3.5 -Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

Raymond Hettinger rep...@bugs.python.org wrote:
  It is certainly possible to document DivisionImpossible etc.
 
 This should not be done.  We've made strong efforts to not extend the Decimal 
 Arithmetic Specification.

The exceptions are already there:

Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
 import decimal
 print(decimal.DivisionImpossible.__doc__)
Cannot perform the division adequately.

This occurs and signals invalid-operation if the integer result of a
divide-integer or remainder operation had too many digits (would be
longer than precision).  The result is [0,qNaN].

The specification distinguishes between conditions and signals. It is
true that the conditions are not technically raised, but they are very
much subclasses of InvalidOperation.

Cowlishaw himself makes the distinction between InvalidOperation
and IEEEInvalidOperation. The latter groups all conditions together:

#define DEC_IEEE_754_Invalid_operation (DEC_Conversion_syntax | \
DEC_Division_impossible |   \
DEC_Division_undefined |\
DEC_Insufficient_storage |  \
DEC_Invalid_context |   \
DEC_Invalid_operation)

So while I don't particularly care whether we document the conditions or
not, I don't think doing so would extend the specification.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Mark Dickinson]

Changes by Mark Dickinson dicki...@gmail.com:


--
nosy: +mark.dickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[leewz]

leewz added the comment:

Total list of issues now:
- Error message for `DivisionImpossible` is
  [class 'decimal.DivisionImpossible']
  instead of an actual error message.
- `decimal.DivisionImpossible.__doc__` is empty.
- Calling `help(decimal.DivisionImpossible)` turns up nothing useful.

I checked all of these just now on my 3.2.3 (Windows). These issues are a 
CHANGE from 3.2 to 3.3. For example:
- Old error:
  decimal.InvalidOperation: quotient too large in //, % or divmod
- New error:
  InvalidOperation: [class 'decimal.DivisionImpossible']

I assume that the issues also apply to the other InvalidOperation types. So I 
guess what I'm really asking for is to pull forward the 3.2 docs and messages.

 That doesn't mean the implementation should change.

Er, I was explaining why it wasn't really surprising once I thought about it.

 There may be a documentation issue, but then again, people who are 
 surprised usually haven't studied the docs in detail.

To clarify:
- I looked at the Decimal docs
- skimmed for references to modulo and division
- looked for `DivisionImpossible`
- Then looked on Google for 'DivisionImpossible Python'.
- Experimented with changing precision and fooling around with bigger and 
smaller numbers, and realized why the operation was logically impossible.
- Came here, posted, got a response that it was a flag raised by libmpdec.

I'm not asking for a change in behavior. I did point out that it was 
inconsistent with regular floats, in case consistency with Pyfloats was a thing 
that mattered. But I don't care about that. I only worry about anyone else who 
would use Decimal coming across the same unhelpful error.

 AFAICT, this particular confusion has never arisen before (i.e. bug 
 reports, questions in python classes, posts on stackoverlow, blog posts, 
 etc).  Likewise, the issue does not seem to have ever arisen in the many 
 other non-Python implementations of the decimal spec.

I agree it'd be (very) rare, but part of the reason why it might not appear 
online is that the issues at the top of this email are relatively new (3.3).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

leewz rep...@bugs.python.org wrote:
 - Error message for `DivisionImpossible` is
   [class 'decimal.DivisionImpossible']
   instead of an actual error message.

No, the error message for the *signal*  that is raised (InvalidOperation) lists
the *condition* that triggered the signal (DivisionImpossible).

I followed the recommendation at:

http://speleotrove.com/decimal/daexcep.html#refexcep

It is recommended that implementations distinguish the different conditions
 listed above, and also provide additional information about exceptional
 conditions where possible (for example, the operation being attempted and
 the values of the operand or operands involved).

Distinguishing the conditions is easy, adding additional information in
all cases would require changes to libmpdec.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Stefan Krah added the comment:

The idea behind the list as the exception message is this:  If multiple
conditions would have raised the signal they are all listed, while the
highest ranking signal is the one that is ultimately raised.

 from decimal import *
 c = getcontext()
 for v in c.traps:
... c.traps[v] = True
... 
 
 Decimal(8) ** 1000
Traceback (most recent call last):
  File stdin, line 1, in module
decimal.Overflow: [class 'decimal.Overflow', class 'decimal.Inexact', 
class 'decimal.Rounded']

Exception precedence is listed here at the bottom of the page:

http://speleotrove.com/decimal/daexcep.html

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[Stefan Krah]

Changes by Stefan Krah stefan-use...@bytereef.org:


--
assignee: docs@python - skrah
nosy: +skrah

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21227] Decimal class error messages for integer division aren't good

[leewz]

New submission from leewz:

Python's `decimal.Decimal` doesn't seem to like taking modulo or intdiv of 
large Decimals by integers (where large depends on how many digits are 
internally stored).

 from decimal import *
 getcontext().prec
28
 Decimal(10**29)%1
Traceback (most recent call last):
  File stdin, line 1, in module
decimal.InvalidOperation: [class 'decimal.DivisionImpossible']
 getcontext().prec=50
 Decimal(10**29)%1
Decimal('0')

Same for `Decimal(10**29)//1`

This is a logical problem: Alice has a 100-digit number which begins with 
1543256. What is the last digit?

But I found the error hard to understand. Searching for DivisionImpossible 
didn't turn up anything immediate (it wasn't added to the official docs?). I 
was most of the way through writing out a question to StackOverflow when it 
clicked. (Also, why is it an InvalidOperation that holds an exception as a 
message? Never saw that before.)

Suggestions:
- Improve docs with further examples. The examples of InvalidOperation are 
logical MATH errors (e.g. division by 0), not logical PROGRAMMING errors.
- Uh, maybe the error message could be changed to something like, The answer 
you seek lies beyond the mantissa. Or more sanely, Not enough precision to 
compute the answer. Or something else that hints to me to look into precision.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 216253
nosy: docs@python, leewz
priority: normal
severity: normal
status: open
title: Decimal class error messages for integer division aren't good
type: enhancement
versions: Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19446] Integer division for negative numbers

[Mark Dickinson]

Mark Dickinson added the comment:

Nitin:

 Is there any operator for integer division in python?

Yes, there is: the '//' operator.  :-)

There's no universally agreed upon definition for 'integer division' when 
negative numbers enter the mix, but I'm guessing that in this case you need 
something that rounds towards 0 instead of towards -infinity.  There's no 
dedicated operator for that, but you can simply do (assuming that b is 
positive):

   -(-a // b) if a  0 else a // b

References:

[1] 
http://python-history.blogspot.co.uk/2010/08/why-pythons-integer-division-floors.html
[2] http://docs.python.org/2/faq/programming.html#why-does-22-10-return-3

--
nosy: +mark.dickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19446
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19574] Negative integer division error

[Vatroslav Suton]

New submission from Vatroslav Suton:

integer division obviously uses float division with math.floor, which produces 
invalid result when result is less than 0, simply try the following 5/2 versus 
-5/2. Please use math.ceil function for results less than 0.
btw is there any way to patch that in __builtins__ ?

--
components: Library (Lib)
messages: 202778
nosy: vatroslavsuton
priority: normal
severity: normal
status: open
title: Negative integer division error
type: behavior
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19574
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19574] Negative integer division error

[R. David Murray]

R. David Murray added the comment:

This is not an aspect of Python that can possibly change, I'm afraid, for 
backward compatibility reasons.

--
nosy: +r.david.murray
resolution:  - duplicate
stage:  - committed/rejected
status: open - closed
superseder:  - Integer division for negative numbers

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19574
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19574] Negative integer division error

[Mark Dickinson]

Mark Dickinson added the comment:

See also http://docs.python.org/2/faq/programming.html#why-does-22-10-return-3

BTW, integer division does not use float division internally.  That would fail 
for integers too large to be exactly representable as floats.  The 
implementation can be seen in Objects/intobject.c and Objects/longobject.c if 
you're interested.

--
nosy: +mark.dickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19574
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19446] Integer division for negative numbers

[Nitin Kumar]

New submission from Nitin Kumar:

Mathematically python is not giving correct output for integer division for 
negative number, e.g. :  -7//2= -3 but python is giving output -4.

--
components: IDLE
files: Integer_division.py
messages: 201715
nosy: Nitin.Kumar
priority: normal
severity: normal
status: open
title: Integer division for negative numbers
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file32420/Integer_division.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19446
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19446] Integer division for negative numbers

[Nitin Kumar]

Changes by Nitin Kumar nitinkumar@gmail.com:


Removed file: http://bugs.python.org/file32420/Integer_division.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19446
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19446] Integer division for negative numbers

[Nitin Kumar]

Changes by Nitin Kumar nitinkumar@gmail.com:


Added file: http://bugs.python.org/file32421/Integer_division.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19446
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19446] Integer division for negative numbers

[Georg Brandl]

Georg Brandl added the comment:

Hi Nitin,

a // b is defined as the floor division operation, same as what math.floor(a 
/ b) gives: the largest integer = a / b.

-7/2 is -3.5, the largest integer = -3.5 is -4.

--
nosy: +georg.brandl
resolution:  - invalid
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19446
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19446] Integer division for negative numbers

[Nitin Kumar]

Nitin Kumar added the comment:

Hi  Georg,

Is there any operator for integer division in python?

On Wed, Oct 30, 2013 at 1:00 PM, Georg Brandl rep...@bugs.python.orgwrote:


 Georg Brandl added the comment:

 Hi Nitin,

 a // b is defined as the floor division operation, same as what
 math.floor(a / b) gives: the largest integer = a / b.

 -7/2 is -3.5, the largest integer = -3.5 is -4.

 --
 nosy: +georg.brandl
 resolution:  - invalid
 status: open - closed

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue19446
 ___


--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19446
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

python3 integer division debugging

[Neal Becker]

The change in integer division seems to be the most insidious source of silent 
errors in porting code from python2 - since it changes the behaviour or valid 
code silently.

I wish the interpreter had an instrumented mode to detect and report such 
problems.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python3 integer division debugging

[Oscar Benjamin]

On 28 August 2013 16:15, Neal Becker ndbeck...@gmail.com wrote:
 The change in integer division seems to be the most insidious source of silent
 errors in porting code from python2 - since it changes the behaviour or valid
 code silently.

 I wish the interpreter had an instrumented mode to detect and report such
 problems.

Is that a joke?

Run the code under Python 2.6/2.7 with the -3 flag:

$ cat test.py

print(10 / 7)

$ python -3 test.py
test.py:2: DeprecationWarning: classic int division
  print(10 / 7)
1


Oscar
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python3 integer division debugging

[random832]

On Wed, Aug 28, 2013, at 11:15, Neal Becker wrote:
 The change in integer division seems to be the most insidious source of
 silent 
 errors in porting code from python2 - since it changes the behaviour or
 valid 
 code silently.
 
 I wish the interpreter had an instrumented mode to detect and report such 
 problems.

There is such a mode in python2 from version 2.2 through 2.7: -Q warn.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python3 integer division debugging

[Chris Angelico]

On Thu, Aug 29, 2013 at 1:21 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
 On 28 August 2013 16:15, Neal Becker ndbeck...@gmail.com wrote:
 The change in integer division seems to be the most insidious source of 
 silent
 errors in porting code from python2 - since it changes the behaviour or valid
 code silently.

 I wish the interpreter had an instrumented mode to detect and report such
 problems.

 Is that a joke?

 Run the code under Python 2.6/2.7 with the -3 flag:

I wouldn't say that's a joke, it's just another demonstration of
Guido's time machine :)

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python3 integer division debugging

[Neal Becker]

Chris Angelico wrote:

 On Thu, Aug 29, 2013 at 1:21 AM, Oscar Benjamin
 oscar.j.benja...@gmail.com wrote:
 On 28 August 2013 16:15, Neal Becker ndbeck...@gmail.com wrote:
 The change in integer division seems to be the most insidious source of
 silent errors in porting code from python2 - since it changes the behaviour
 or valid code silently.

 I wish the interpreter had an instrumented mode to detect and report such
 problems.

 Is that a joke?

 Run the code under Python 2.6/2.7 with the -3 flag:
 
 I wouldn't say that's a joke, it's just another demonstration of
 Guido's time machine :)
 
 ChrisA

Ah!  I looked for it in python3.  Funny it isn't there as well.  Thanks!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python3 integer division debugging

[Terry Reedy]

On 8/28/2013 11:15 AM, Neal Becker wrote:

The change in integer division seems to be the most insidious source of silent
errors in porting code from python2 - since it changes the behaviour or valid
code silently.


In Python since 2.??, put 'from __future__ import integer_division' 
(sp?) at the top of your code



--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

[issue12831] 2to3 and integer division

[Mark Dickinson]

Mark Dickinson dicki...@gmail.com added the comment:

 / 2 is an integer division, so it should be // 3 in Python 3.

No, I don't think that's right: 2to3 has no way of knowing that the programmer 
intended an integer division here (self.maxstars could be a float).

Instead, you should always use '//' in Python 2 code where an integer division 
is intended.

--
nosy: +mark.dickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12831
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12831] 2to3 and integer division

[Mark Dickinson]

Changes by Mark Dickinson dicki...@gmail.com:


--
nosy: +benjamin.peterson
resolution:  - invalid
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12831
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12831] 2to3 and integer division

[Alexander Rødseth]

Alexander Rødseth rods...@gmail.com added the comment:

Even though it's hard to cover every case, it should be possible in quite a few 
cases:

self.maxstars = 4
half = self.maxstars / 2

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12831
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com