Python 3.0 new integer division

[Hutch]

We now have a float result when two integers are divided in the same mannor
as 2.4 or 2.5.
I can handle that and use the Floor division but a simple question.

Why in the world would you round down the last presented digit to a 6
instead of just leaving it along as an 8.
For some reason rounding down for a float in Python does not seem correct.

IDLE 3.0a4

>>123456789012345678901234567890123456789012345678 90/345

3.5784576525317586e+46

>>123456789012345678901234567890123456789012345678 90//345

35784576525317588087314367504383610663481839327
^
^|
35784576525317586000000000000000000000000000000 == 3.5784576525317586e+46

[Matimus]

On Apr 8, 9:13 am, "Hutch" <[e-mail]:

We now have a float result when two integers are divided in the same mannor
as 2.4 or 2.5.
I can handle that and use the Floor division but a simple question.

Why in the world would you round down the last presented digit to a 6
instead of just leaving it along as an 8.
For some reason rounding down for a float in Python does not seem correct.

IDLE 3.0a4

>1234567890123456789012345678901234567890123456789 0/345

3.5784576525317586e+46

>1234567890123456789012345678901234567890123456789 0//345

35784576525317588087314367504383610663481839327
^
^|
35784576525317586000000000000000000000000000000 == 3.5784576525317586e+46

This just has to do with the way floating point numbers are
represented in memory. More information:
http://docs.python.org/tut/node16.html

Matt

[Hutch]

"Matimus" <mc******@gmail.comwrote in message
news:b6**********************************@s33g2000 pri.googlegroups.com...

On Apr 8, 9:13 am, "Hutch" <[e-mail]:

>We now have a float result when two integers are divided in the same
mannor
as 2.4 or 2.5.
I can handle that and use the Floor division but a simple question.

Why in the world would you round down the last presented digit to a 6
instead of just leaving it along as an 8.
For some reason rounding down for a float in Python does not seem
correct.

IDLE 3.0a4

>>123456789012345678901234567890123456789012345678 90/345

3.5784576525317586e+46

>>123456789012345678901234567890123456789012345678 90//345

35784576525317588087314367504383610663481839327
^
^|
35784576525317586000000000000000000000000000000 ==
3.5784576525317586e+46

This just has to do with the way floating point numbers are
represented in memory. More information:
http://docs.python.org/tut/node16.html

Matt

Was thinking IBM decimal when I asked the question --should have remembered
detail of floats.
Thanks
Hutch

[Jonathan Gardner]

On Apr 8, 2:25*pm, Grzegorz S³odkowicz <[e-mail]:

>
Isn't Decimal a BCD implementation?

Yep, you are right and I am wrong. http://www.python.org/dev/peps/pep-0...y-not-rational

[Mark Dickinson]

On Apr 8, 6:01 pm, Jonathan Gardner <[e-mail]>
wrote:

On Apr 8, 2:25 pm, Grzegorz S³odkowicz <[e-mail]:

Isn't Decimal a BCD implementation?

Yep, you are right and I am wrong.http://www.python.org/dev/peps/pep-0...y-not-rational

Strictly speaking, BCD doesn't come into it: the coefficient of a
Decimal instance is stored simply as a string of digits. This is
pretty wasteful in terms of space: 1 byte per decimal digit
instead of the 4 bits per digit that BCD gives, but it's
convenient and fairly efficient.

An alternative representation that's gained popularity recently is
DPD (densely packed decimal), which packs 3 decimal digits into 10
bits in a clever way that allows reasonably efficient extraction
of any one of the 3 digits. Decimal doesn't use this either. :)

Mark

[Arnaud Delobelle]

On Apr 9, 8:35*pm, Mark Dickinson <[e-mail]:

Strictly speaking, BCD doesn't come into it: *the coefficient of a
Decimal instance is stored simply as a string of digits. *This is
pretty wasteful in terms of space: *1 byte per decimal digit
instead of the 4 bits per digit that BCD gives, but it's
convenient and fairly efficient.

An alternative representation that's gained popularity recently is
DPD (densely packed decimal), which packs 3 decimal digits into 10
bits in a clever way that allows reasonably efficient extraction
of any one of the 3 digits. *Decimal doesn't use this either. :)

Mark

Naive question: why not just use a long + an exponent?

e.g. 132560 -(13256, 1)
0.534 -(534, -3)
5.23e10 -(523, 8)

--
Arnaud

[Mark Dickinson]

On Apr 9, 3:57*pm, Arnaud Delobelle <[e-mail]:

Naive question: why not just use a long + an exponent?

e.g. 132560 *-(13256, 1)
* * *0.534 * -(534, -3)
* * *5.23e10 -(523, 8)

It's a good question. The standard answer is that if the
coefficient is a long then it's awkward to get at individual
digits; looking up a digit becomes an O(n^2) operation
(involving a division and a remainder) instead of the O(1)
that it should be. And you need access to the digits for
rounding operations, which are pretty darn common (one
round at the end of each arithmetic operation, as a rule).

But I could easily be convinced that storing the coefficient
as a long speeds things up for the usual use cases, even if
it gives horrible asymptotics for those trying to do really
high-precision calculations. And it would certainly make
the code slightly simpler in places.

It would be great if someone could try converting Decimal
so that the coefficient is stored as a long, to see if there's
any noticeable impact on speed one way or the other. It
wouldn't be such a hard change: a few hours of work at most.
It's on my todo list to try this, but so far down that it's
not looking like it'll end up at the top of the list before
Christmas 20??.

Mark