Python 3.0 new integer division

Discussion in 'Python' started by Hutch, Apr 8, 2008.

  1. Hutch

    Hutch Guest

    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

    >>> 12345678901234567890123456789012345678901234567890/345

    3.5784576525317586e+46


    >>> 12345678901234567890123456789012345678901234567890//345

    35784576525317588087314367504383610663481839327
    ^
    ^|
    35784576525317586000000000000000000000000000000 == 3.5784576525317586e+46
    Hutch, Apr 8, 2008
    #1
    1. Advertising

  2. On Apr 8, 9:13 am, "Hutch" <> 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
    >
    > >>> 12345678901234567890123456789012345678901234567890/345

    >
    > 3.5784576525317586e+46
    >
    > >>> 12345678901234567890123456789012345678901234567890//345

    >
    > 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.
    Jonathan Gardner, Apr 8, 2008
    #2
    1. Advertising

  3. Hutch

    Matimus Guest

    On Apr 8, 9:13 am, "Hutch" <> 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
    >
    > >>> 12345678901234567890123456789012345678901234567890/345

    >
    > 3.5784576525317586e+46
    >
    > >>> 12345678901234567890123456789012345678901234567890//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
    Matimus, Apr 8, 2008
    #3
  4. Hutch

    Hutch Guest

    "Matimus" <> wrote in message
    news:...
    > On Apr 8, 9:13 am, "Hutch" <> 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
    >>
    >> >>> 12345678901234567890123456789012345678901234567890/345

    >>
    >> 3.5784576525317586e+46
    >>
    >> >>> 12345678901234567890123456789012345678901234567890//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
    Hutch, Apr 8, 2008
    #4

  5. > 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?
    Grzegorz SÅ‚odkowicz, Apr 8, 2008
    #5
  6. Jonathan Gardner, Apr 8, 2008
    #6
  7. On Apr 8, 6:01 pm, Jonathan Gardner <>
    wrote:
    > On Apr 8, 2:25 pm, Grzegorz S³odkowicz <> wrote:
    >
    >
    >
    > > Isn't Decimal a BCD implementation?

    >
    > Yep, you are right and I am wrong.http://www.python.org/dev/peps/pep-0327/#why-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
    Mark Dickinson, Apr 9, 2008
    #7
  8. On Apr 9, 8:35 pm, Mark Dickinson <> wrote:
    > 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
    Arnaud Delobelle, Apr 9, 2008
    #8
  9. On Apr 9, 3:57 pm, Arnaud Delobelle <> wrote:
    > 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
    Mark Dickinson, Apr 9, 2008
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. walala
    Replies:
    12
    Views:
    1,871
  2. genlock
    Replies:
    22
    Views:
    25,978
    vipinlal
    Mar 17, 2010
  3. Darius Fatakia

    integer division

    Darius Fatakia, Jan 28, 2004, in forum: C++
    Replies:
    2
    Views:
    438
    Howard
    Jan 28, 2004
  4. Sidney Cadot

    integer division towards -infinity

    Sidney Cadot, Jul 10, 2003, in forum: C Programming
    Replies:
    3
    Views:
    617
    Glen Herrmannsfeldt
    Jul 11, 2003
  5. Replies:
    94
    Views:
    4,459
    ¬a\\/b
    Feb 9, 2007
Loading...

Share This Page