Floating point bug?

[robinsiebler@gmail.com]

I've never had any call to use floating point numbers and now that I
want to, I can't!

*** Python 2.5.1 (r251:54863, May 1 2007, 17:47:05) [MSC v.1310 32
bit (Intel)] on win32. ***

>>float (.3)

0.2999999999999 9999

>>foo = 0.3
>>foo

0.2999999999999 9999

>>>

[marek.rocki@wp.pl]

Re: Floating point bug?

Not a bug. All languages implementing floating point numbers have the
same issue. Some just decide to hide it from you. Please read
http://docs.python.org/tut/node16.html and particularly

http://docs.python.org/tut/node16.html#SECTION0016100000000000000000

Regards,
Marek

[Bjoern Schliessmann]

Re: Floating point bug?

robinsiebler@gm ail.com wrote:

I've never had any call to use floating point numbers and now that
I want to, I can't!

Ever considered phrasing your actual problem so one can help, let
alone looking at the archive for many, many postings about this
topic?

Regards,


Björn

--
BOFH excuse #66:

bit bucket overflow

[Jeff Schwab]

Re: Floating point bug?

Dennis Lee Bieber wrote:

On Wed, 13 Feb 2008 17:49:08 -0800, Jeff Schwab <jeff@schwabcen ter.com>
declaimed the following in comp.lang.pytho n:
>

>If you need a pretty string for use in code:
>>

> >>def pretty_fp(fpnum , prec=8):

> ... return ('%.8f' % fpnum).rstrip(' 0')
> ...

> >>pretty_fp(0.3 )

> '0.3'
>>

>
What's wrong with just
>
str(0.3)

Nothing!

that's what "print" invokes, whereas the interpreter prompt is using
>
repr(0.3)

Thanks for pointing that out.

[Christian Heimes]

Re: Floating point bug?

Dennis Lee Bieber wrote:

What's wrong with just
>
str(0.3)
>
that's what "print" invokes, whereas the interpreter prompt is using
>
repr(0.3)
>

No, print invokes the tp_print slot of the float type. Some core types
have a special handler for print. The tp_print slot is not available
from Python code and most people don't know about it. :]

Christian

[Christian Heimes]

Re: Floating point bug?

Bruno Desthuilliers wrote:

I Must have miss something...

Yeah, You have missed the beginning of the third sentence: "The tp_print
slot is not available from Python code". The tp_print slot is only
available in C code and is part of the C definition of a type. Hence tp_
as type.

Search for float_print and tp_print in

http://svn.python.org/view/python/trunk/Objects/floatobject.c?rev=60567&view=auto

Christian

[Duncan Booth]

Re: Floating point bug?

Bruno Desthuilliers <bruno.42.desth uilliers@wtf.we bsiteburo.oops. com>
wrote:

I Must have miss something...

Perhaps you missed the part where Christian said "The tp_print slot is not
available from Python code"?

[Bruno Desthuilliers]

Re: Floating point bug?

Christian Heimes a écrit :

Bruno Desthuilliers wrote:

>I Must have miss something...

>
Yeah, You have missed the beginning of the third sentence: "The tp_print
slot is not available from Python code".

oops, my bad ! I missed the "not" !-)

[Jeff Schwab]

Re: Floating point bug?

Christian Heimes wrote:

Dennis Lee Bieber wrote:

> What's wrong with just
>>
> str(0.3)
>>
>that's what "print" invokes, whereas the interpreter prompt is using
>>
> repr(0.3)
>>

>
No, print invokes the tp_print slot of the float type. Some core types
have a special handler for print. The tp_print slot is not available
from Python code and most people don't know about it. :]

Why does print use the tp_print slot, rather than str()? Are the two
effectively redundant? If (non-repr) string representations are
frequently needed for a given type, could str() be implemented as a
reference to tp_slot, via a C-language extension?

[Gabriel Genellina]

Re: Floating point bug?

En Thu, 14 Feb 2008 15:22:41 -0200, Jeff Schwab <jeff@schwabcen ter.com>
escribió:

Christian Heimes wrote:

>No, print invokes the tp_print slot of the float type. Some core types
>have a special handler for print. The tp_print slot is not available
>from Python code and most people don't know about it. :]

>
Why does print use the tp_print slot, rather than str()? Are the two
effectively redundant? If (non-repr) string representations are
frequently needed for a given type, could str() be implemented as a
reference to tp_slot, via a C-language extension?

As a side note, the print statement has FIVE related opcodes. Looks like
printing has been considered a very important operation...

--
Gabriel Genellina

[robinsiebler]

Re: Floating point bug?

I did try searching, but I never found what I was looking for. This
thread has been very useful and informative. Thanks for all your
help! I was able to fix my problem. :)

[Duncan Booth]

Re: Floating point bug?

Jeff Schwab <jeff@schwabcen ter.comwrote:

Christian Heimes wrote:

>Dennis Lee Bieber wrote:

>> What's wrong with just
>>>
>> str(0.3)
>>>
>>that's what "print" invokes, whereas the interpreter prompt is using
>>>
>> repr(0.3)
>>>

>>
>No, print invokes the tp_print slot of the float type. Some core types
>have a special handler for print. The tp_print slot is not available
>from Python code and most people don't know about it. :]

>
Why does print use the tp_print slot, rather than str()? Are the two
effectively redundant? If (non-repr) string representations are
frequently needed for a given type, could str() be implemented as a
reference to tp_slot, via a C-language extension?

The tp_print slot is used only when printing to a C file descriptor. In
most cases where it is used it simply duplicates the str and repr
functionality but avoids building the entire output in memory. It also
takes a flag argument indicating whether it should output the str or repr,
the latter being used when rendering the content inside an object such as a
dict or list.

So for example a dict's repr builds a list containing the repr of each
key/value pair and then joins the list using a comma separator. The
tp_print simply outputs the '{', then uses tp_print to output the repr of
the key and repr of the value with appropriate separators and finally the
closing '}'. It would not suprise me if by replacing the output of a single
large string with a lot of small calls to fputs 'print x' could be slower
than 'print str(x)'.

[Zentrader]

Re: Floating point bug?

That's a misconception. The decimal-module has a different base (10

instead of 2), and higher precision. But that doesn't change the fact
that it will expose the same rounding-errors as floats do - just for
different numbers.
>

>>import decimal as d
>>d = d.Decimal
>>d("1") / d("3") * d("3")

Decimal("0.9999 999999999999999 999999999")

Surely you jest. Your example is exact to 28 digits. Your attempted
trick is to use a number that never ends (1/3=0.3333...). It would
only convert back to one if you have and infinite number of
significant digits. That has nothing to do with the Python decimal
module (which does what it claims). It is one of the idiosyncrasies
of the base 10 number system. Remember we are working with base 10
decimals and not fractions.

[Jeff Schwab]

Re: Floating point bug?

Zentrader wrote:

>That's a misconception. The decimal-module has a different base (10
>instead of 2), and higher precision. But that doesn't change the fact
>that it will expose the same rounding-errors as floats do - just for
>different numbers.
>>

> >>import decimal as d
> >>d = d.Decimal
> >>d("1") / d("3") * d("3")

>Decimal("0.999 999999999999999 9999999999")

>
Surely you jest. Your example is exact to 28 digits. Your attempted
trick is to use a number that never ends (1/3=0.3333...). It would
only convert back to one if you have and infinite number of
significant digits. That has nothing to do with the Python decimal
module (which does what it claims). It is one of the idiosyncrasies
of the base 10 number system. Remember we are working with base 10
decimals and not fractions.

Diez was not claiming that the decimal module did anything less than
what it promised. He just pointed out that the module does not support
infinitely precise floating-point arithmetic, any more than tradition
base-2 representations do. Please review the thread (the parts you
snipped) for clarification.

[Zentrader]

Re: Floating point bug?

I disagree with this statement
<quote>But that doesn't change the fact that it will expose the same
rounding-errors as floats do - just for different numbers. </quote>
The example used has no rounding errors. For anything less that 28
significant digits it rounds to 1.0. With floats 1.0/3 yields
0.3333333333333 3331<-- on my machine. Also you can compare two
decimal.Decimal () objects for equality. With floats you have to test
for a difference less than some small value. BTW, a college professor
who also wrote code for a living made this offhand remark "In general
it is best to multiply first and then divide." Good general advice.