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

>>1234567890123 456789012345678 901234567890123 4567890/345

3.5784576525317 586e+46

>>1234567890123 456789012345678 901234567890123 4567890//345

357845765253175 880873143675043 836106634818393 27
^
^|
357845765253175 860000000000000 000000000000000 00 == 3.5784576525317 586e+46

[Matimus]

Re: Python 3.0 new integer division

On Apr 8, 9:13 am, "Hutch" <A...@MCHSI.COM wrote:

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
>

>12345678901234 567890123456789 012345678901234 567890/345

>
3.5784576525317 586e+46
>

>12345678901234 567890123456789 012345678901234 567890//345

>
357845765253175 880873143675043 836106634818393 27
^
^|
357845765253175 860000000000000 000000000000000 00 == 3.5784576525317 586e+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]

Re: Python 3.0 new integer division


"Matimus" <mccredie@gmail .comwrote in message
news:b6eafdd4-dbf8-4269-962f-531126bb10c0@s3 3g2000pri.googl egroups.com...

On Apr 8, 9:13 am, "Hutch" <A...@MCHSI.COM wrote:

>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
>>

>>1234567890123 456789012345678 901234567890123 4567890/345

>>
>3.578457652531 7586e+46
>>

>>1234567890123 456789012345678 901234567890123 4567890//345

>>
>35784576525317 588087314367504 383610663481839 327
> ^
> ^|
>35784576525317 586000000000000 000000000000000 000 ==
>3.578457652531 7586e+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]

Re: Python 3.0 new integer division

On Apr 8, 2:25 pm, Grzegorz S³odkowicz <jerg...@wp.plw rote:

>
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]

Re: Python 3.0 new integer division

On Apr 8, 6:01 pm, Jonathan Gardner <jgard...@jonat hangardner.net>
wrote:

On Apr 8, 2:25 pm, Grzegorz S³odkowicz <jerg...@wp.plw rote:
>
>
>

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]

Re: Python 3.0 new integer division

On Apr 9, 8:35 pm, Mark Dickinson <dicki...@gmail .comwrote:

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]

Re: Python 3.0 new integer division

On Apr 9, 3:57 pm, Arnaud Delobelle <arno...@google mail.comwrote:

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