Who told str() to round my int()'s!!!

[John Machin]

On Aug 12, 5:37 am, Zentrader <zentrad... at gmail.com> wrote:
> On Aug 11, 9:40 am, "Adam W." <AWasile... at gmail.com> wrote:
>
> > After a fair amount of troubleshooting of why my lists were coming
> > back a handful of digits short, and the last digit rounded off, I
> > determined the str() function was to blame:
>
> > >>> foonum
>
> > 0.0071299720384678782
>
> > >>> str(foonum)
> > '0.00712997203847'
>
> > Why in the world does str() have any business rounding my numbers, and
> > how do I get around this?
>
> If 15 digit precision is a concern, I would suggest that you us the
> decimal class instead of floating points.  Floating point problems on
> X86 machines are well documented.http://docs.python.org/lib/module-decimal.htmlhttp://pydoc.org/2.4.1/decimal.htmlhttp://gmpy.sourceforge.net/

If you are concerned with precision of *communication*:

The problem is not with floating "points" in general; floating point
arithmetic can be done using a decimal representation for the numbers.
The problem is not with "X86" machines in particular; just about all
modern machines have floating point hardware which implements the IEEE
754 standard for binary flaoting point arithmetic. The problem is with
trying to represent in one base (e.g. 10) a non-integer number that is
expressed in a different base (e.g. 2) -- where the number can be
represented exactly only in one base (e.g. 1./10.) or in neither (e.g.
1./3.)