Nick Maclaren wrote:
> Not at all. "Precision" has been used to indicate the number of
> digits after the decimal point for at least 60 years,
Not only, remember: Computer memories can't think in powers of ten.
> probably 100; in 40 years of IT and using dozens of programming
> languages, I ha
In article <[EMAIL PROTECTED]>,
"Ziga Seilnacht" <[EMAIL PROTECTED]> writes:
|>
|> There was a recent bug report identical to your complaints, which
|> was closed as invalid. The rationale for closing it was that things
|> like:
|>
|> print ("a, bc", "de f,", "gh), i")
|>
|> would be extremely
Nick Maclaren wrote:
> Well, it's not felt necessary to distinguish those at top level, so
> why should it be when they are in a sequence?
Well, this probably wasn't the best example, see the links below
for a better one.
> But this whole thing is getting ridiculous. The current implementation
In article <[EMAIL PROTECTED]>,
Bjoern Schliessmann <[EMAIL PROTECTED]> writes:
|>
|> > 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".
Not at all. "Precision" has been used to indi
In article <[EMAIL PROTECTED]>,
"Ziga Seilnacht" <[EMAIL PROTECTED]> writes:
|>
|> > 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
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 y
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
--
http://mail.python.org/mailman/listinfo/python-list
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
In article <[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]> 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
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 ?
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Bjoern Schliessmann <[EMAIL PROTECTED]> 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 probl
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 excus
In article <[EMAIL PROTECTED]>,
"Richard Brodie" <[EMAIL PROTECTED]> 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
"Nick Maclaren" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> x = (1.234567890125, 1.2345678901255)
> print x
> print x[0], x[1]
>
(1.234567890124, 1.2345678901254999)
1.23456789012 1.23456789013
>
> Is there a rational reason, or is that simply an artifact of the
x = (1.234567890125, 1.2345678901255)
print x
print x[0], x[1]
>>> (1.234567890124, 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.
--
h
15 matches
Mail list logo
