«

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

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

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
>
> >>> 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" <> wrote in message
news:b6eafdd4-dbf8-4269-962f-...
> 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
>>
>> >>> 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

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

On Apr 8, 2:25*pm, Grzegorz S³odkowicz <jerg...@wp.pl> wrote:
>
> 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

On Apr 8, 6:01 pm, Jonathan Gardner <jgard...@jonathangardner.net>
wrote:
> On Apr 8, 2:25 pm, Grzegorz S³odkowicz <jerg...@wp.pl> wrote:
>
>
>
> > 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

On Apr 9, 8:35*pm, Mark Dickinson <dicki...@gmail.com> 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,

--
Arnaud

On Apr 9, 3:57*pm, Arnaud Delobelle <arno...@googlemail.com> wrote:
> Naive question: why not just use a long + an exponent?
>
> e.g. 132560 *-> (13256, 1)
> * * *0.534 * -> (534, -3)
> * * *5.23e10 -> (523,
>

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