Velocity Reviews > Bizarre floating-point output

Bizarre floating-point output

Nick Maclaren
Guest
Posts: n/a

 01-08-2007

x = (1.234567890125, 1.2345678901255)
print x
print x[0], x[1]

>>> (1.2345678901249999, 1.2345678901254999)
>>> 1.23456789012 1.23456789013

Is there a rational reason, or is that simply an artifact of the way
that the code has evolved? It is clearly not a bug

Regards,
Nick Maclaren.

Richard Brodie
Guest
Posts: n/a

 01-08-2007

"Nick Maclaren" <(E-Mail Removed)> wrote in message
news:enthjb\$p0l\$(E-Mail Removed)...
>
> x = (1.234567890125, 1.2345678901255)
> print x
> print x[0], x[1]
>
>>>> (1.2345678901249999, 1.2345678901254999)
>>>> 1.23456789012 1.23456789013

>
> Is there a rational reason, or is that simply an artifact of the way
> that the code has evolved? It is clearly not a bug

print x[0] gives the same result as printing str(x[0]),
the value of x formatted as a string (rounded to a
sensible number of places).

x[0] at the command prompt gives the same result as
printing repr(x), the representation of the text value as
a string.

When you do print on a tuple it doesn't recursively
call str(), so you get the repr representations.

You can get similar results with anything where the
str() and repr() values are different.
e.g. x = ( u'a', u'b')

Nick Maclaren
Guest
Posts: n/a

 01-08-2007

In article <entj5d\$o4\$(E-Mail Removed)>,
"Richard Brodie" <(E-Mail Removed)> writes:
|>
|> When you do print on a tuple it doesn't recursively
|> call str(), so you get the repr representations.

Ah! That explains it. I would call that reason intermediate
between rational and an artifact of the way the code has evolved!

Regards,
Nick Maclaren.

Bjoern Schliessmann
Guest
Posts: n/a

 01-08-2007
Nick Maclaren wrote:

> Ah! That explains it. I would call that reason intermediate
> between rational and an artifact of the way the code has evolved!

Which code has evolved? Those precision problems are inherent
problems of the way floats are stored in memory.

Regards,

Björn

--
BOFH excuse #292:

We ran out of dial tone and we're and waiting for the phone company
to deliver another bottle.

Nick Maclaren
Guest
Posts: n/a

 01-08-2007

In article <(E-Mail Removed)>,
Bjoern Schliessmann <(E-Mail Removed)> writes:
|> Nick Maclaren wrote:
|>
|> > Ah! That explains it. I would call that reason intermediate
|> > between rational and an artifact of the way the code has evolved!
|>
|> Which code has evolved? Those precision problems are inherent
|> problems of the way floats are stored in memory.

The use of different precisions for the two cases is not, however,
and it is that I was and am referring to.

Regards,
Nick Maclaren.

Fredrik Lundh
Guest
Posts: n/a

 01-08-2007
Nick Maclaren wrote:

> The use of different precisions for the two cases is not, however,
> and it is that I was and am referring to.

that's by design, of course. maybe you should look "repr" up in the
documentation ?

</F>

Nick Maclaren
Guest
Posts: n/a

 01-08-2007

In article <(E-Mail Removed)>, Fredrik Lundh <(E-Mail Removed)> writes:
|> Nick Maclaren wrote:
|>
|> > The use of different precisions for the two cases is not, however,
|> > and it is that I was and am referring to.
|>
|> that's by design, of course. maybe you should look "repr" up in the
|> documentation ?

I think that you should. Where does it say that tuple's __str__ is
the same as its __repr__?

The obvious interpretation of the documentation is that a sequence
type's __str__ would call __str__ on each sub-object, and its __repr__
would call __repr__.

Regards,
Nick Maclaren.

Bjoern Schliessmann
Guest
Posts: n/a

 01-08-2007
Nick Maclaren wrote:

> I think that you should.

Big words.

> Where does it say that tuple's __str__ is the same as its
> __repr__?

Where does it say that a tuple's __str__ does not call its contents'
__repr__?

> The obvious interpretation of the documentation is that a sequence
> type's __str__ would call __str__ on each sub-object,

Where do you read that? BTW, that makes absolutely no sense to me.
Also, lists of Strings would quickly get messed up when displaying
them using __str__.

Regards,

Björn

--
BOFH excuse #359:

YOU HAVE AN I/O ERROR -> Incompetent Operator error

Bjoern Schliessmann
Guest
Posts: n/a

 01-08-2007
Nick Maclaren wrote:

> The use of different precisions for the two cases is not, however,
> and it is that I was and am referring to.

You mistake "precision" with "display".

Regards,

Björn

--
BOFH excuse #12:

dry joints on cable plug

Ziga Seilnacht
Guest
Posts: n/a

 01-08-2007
Nick Maclaren wrote:

> I think that you should. Where does it say that tuple's __str__ is
> the same as its __repr__?
>
> The obvious interpretation of the documentation is that a sequence
> type's __str__ would call __str__ on each sub-object, and its __repr__
> would call __repr__.

How would you distinguish ['3', '2', '1'] from [3, 2, 1] in that case?

Ziga