Bizarre floating-point output

Discussion in 'Python' started by Nick Maclaren, Jan 8, 2007.

  1. 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.
    Nick Maclaren, Jan 8, 2007
    #1
    1. Advertising

  2. "Nick Maclaren" <> wrote in message
    news:enthjb$p0l$...
    >
    > 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')
    Richard Brodie, Jan 8, 2007
    #2
    1. Advertising

  3. In article <entj5d$o4$>,
    "Richard Brodie" <> 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.
    Nick Maclaren, Jan 8, 2007
    #3
  4. 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.
    Bjoern Schliessmann, Jan 8, 2007
    #4
  5. In article <>,
    Bjoern Schliessmann <> 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.
    Nick Maclaren, Jan 8, 2007
    #5
  6. 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>
    Fredrik Lundh, Jan 8, 2007
    #6
  7. In article <>, Fredrik Lundh <> 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.
    Nick Maclaren, Jan 8, 2007
    #7
  8. 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, Jan 8, 2007
    #8
  9. 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
    Bjoern Schliessmann, Jan 8, 2007
    #9
  10. 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
    Ziga Seilnacht, Jan 8, 2007
    #10
  11. In article <>,
    "Ziga Seilnacht" <> 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__ on each sub-object, and its __repr__
    |> > would call __repr__.
    |>
    |> How would you distinguish ['3', '2', '1'] from [3, 2, 1] in that case?

    Well, it's not felt necessary to distinguish those at top level, so
    why should it be when they are in a sequence?

    print "3", 3
    3 3

    But this whole thing is getting ridiculous. The current implementation
    is a bizarre interpretation of the specification, but clearly not an
    incorrect one. It isn't important enough to get involved in a religious
    war over - I was merely puzzled as to the odd behaviour, because I have
    to teach it, and it is the sort of thing that can confuse naive users.


    Regards,
    Nick Maclaren.
    Nick Maclaren, Jan 8, 2007
    #11
  12. In article <>,
    Bjoern Schliessmann <> 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 indicate the number of digits
    after the decimal point for at least 60 years, probably 100; in 40 years
    of IT and using dozens of programming languages, I have never seen
    "display" used for that purpose.


    Regards,
    Nick Maclaren.
    Nick Maclaren, Jan 8, 2007
    #12
  13. 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
    > is a bizarre interpretation of the specification, but clearly not an
    > incorrect one. It isn't important enough to get involved in a religious
    > war over - I was merely puzzled as to the odd behaviour, because I have
    > to teach it, and it is the sort of thing that can confuse naive users.


    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 confusing if the current behaviour was changed. See
    http://www.python.org/sf/1534769
    for details.

    Ziga
    Ziga Seilnacht, Jan 8, 2007
    #13
  14. In article <>,
    "Ziga Seilnacht" <> 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 confusing if the current behaviour was changed. See
    |> http://www.python.org/sf/1534769
    |> for details.

    Well, I wasn't complaining - merely querying.

    If this approach is taken, it would be better to document it, so that
    authors of derived classes follow the convention.


    Regards,
    Nick Maclaren.
    Nick Maclaren, Jan 8, 2007
    #14
  15. 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 have never seen "display" used for that purpose.


    Yes, but since the representation in computers is based on powers of
    two, a certain precision in the dual system, i. e. a fixed amount
    of dual places, doesn't correspond with a fixed amount of decimal
    places. Thus the rounding while displaying -- just to make it look
    prettier. The very minimal additional error is silently accepted.

    Regards,


    Björn

    --
    BOFH excuse #199:

    the curls in your keyboard cord are losing electricity.
    Bjoern Schliessmann, Jan 8, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. H aka N
    Replies:
    15
    Views:
    15,621
    Ben Jones
    Mar 2, 2006
  2. Motaz Saad
    Replies:
    7
    Views:
    6,461
  3. Saraswati lakki
    Replies:
    0
    Views:
    1,298
    Saraswati lakki
    Jan 6, 2012
  4. teeshift
    Replies:
    2
    Views:
    243
    Chris Pearl
    Dec 1, 2006
  5. Replies:
    9
    Views:
    186
    Alex Young
    Nov 27, 2007
Loading...

Share This Page