By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,035 Members | 1,984 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,035 IT Pros & Developers. It's quick & easy.

Python 3.0 new integer division

P: n/a
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
Apr 8 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On Apr 8, 9:13 am, "Hutch" <A...@MCHSI.COMwrote:
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
Apr 8 '08 #2

P: n/a

"Matimus" <mc******@gmail.comwrote in message
news:b6**********************************@s33g2000 pri.googlegroups.com...
On Apr 8, 9:13 am, "Hutch" <A...@MCHSI.COMwrote:
>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
Apr 8 '08 #3

P: n/a
On Apr 8, 2:25*pm, Grzegorz Słodkowicz <jerg...@wp.plwrote:
>
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
Apr 8 '08 #4

P: n/a
On Apr 8, 6:01 pm, Jonathan Gardner <jgard...@jonathangardner.net>
wrote:
On Apr 8, 2:25 pm, Grzegorz Słodkowicz <jerg...@wp.plwrote:
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
Apr 9 '08 #5

P: n/a
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

Apr 9 '08 #6

P: n/a
On Apr 9, 3:57*pm, Arnaud Delobelle <arno...@googlemail.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
Apr 9 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.