Python 3.0 new integer division

H

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
3.5784576525317586e+46
35784576525317588087314367504383610663481839327
^
^|
35784576525317586000000000000000000000000000000 == 3.5784576525317586e+46
 
J

Jonathan Gardner

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


35784576525317588087314367504383610663481839327
                                ^
                                ^|
35784576525317586000000000000000000000000000000  == 3.5784576525317586e+46

Floats are weird that way. Part of the problem is you are representing
a decimal number (base 10) in binary (base 2). The other part is that
you can't increment floats by a very tiny amount. In other words, a +
b = a for floats when b is sufficiently small but not zero.

Blame floats, not Python.

If you want precision with fractions, you should be using the Decimal
type, which uses a rational. A rational, if you recall from your math
classes, is one integer divided by another.
 
M

Matimus

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


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
 
G

Grzegorz SÅ‚odkowicz

If you want precision with fractions, you should be using the Decimal
type, which uses a rational. A rational, if you recall from your math
classes, is one integer divided by another.

Isn't Decimal a BCD implementation?
 
M

Mark Dickinson


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
 
A

Arnaud Delobelle

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

Mark Dickinson

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top