a print bug?

[Summercoolness]

it seems that the behavior of "print" is that it will round off
properly for any floating point imperfection, such as shown in the
first two samples. The third sample seems to be a bug? It doesn't
know how to handle the floating imperfection in this case.

1.2344999999999999
1.2345

1.234
1.235
1.234
1.235

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

it seems that the behavior of "print" is that it will round off
properly for any floating point imperfection, such as shown in the
first two samples. The third sample seems to be a bug? It doesn't
know how to handle the floating imperfection in this case.

It has nothing to do with the print command, and everything with
floating point precision. See http://docs.python.org/tut/node16.html

Sybren

 

[Summercoolness]

It has nothing to do with the print command, and everything with
floating point precision. See http://docs.python.org/tut/node16.html

how about the discrepancy between

1.2345

1.234

the first one, print knows enough to recognize and print it as 1.2345.
however, in the second line, when it is round off, it doesn't know it
is 1.2345 any more.

 

[Summercoolness]

how about the discrepancy between


1.234

the first one, print knows enough to recognize and print it as 1.2345.
however, in the second line, when it is round off, it doesn't know it
is 1.2345 any more.

I think maybe this is the reason: the first one, print will print it
out with a rounding to the 11th decimal point, therefore hiding any
floating point imperfection.

however, in the second one, print will not first round it off to the
11th decimal point with a subsequent rounding off to the 3rd decimal
point. In that case, the floating point imperfection is manifested.
(by thinking it is 1.2344999999999999)

a question is: since print can nicely hide and smooth out the floating
point imperfection, and probably most people prefer it that way, how
come the implementation of print "%10.3f" doesn't also do that --
eliminating the imperfection first, and then print it out accordingly.
I think one argument is the loss of precision, but we only print it,
rather than modify the number or the variable itself... hm... say, if
a bank uses python to print out the "change that should be returned to
the customer" using print "%20.2f", then there will be a cent missing
here and there... why not smooth out that imperfection and return that
penny to the customer? (not that they really care).

 

[casevh]

That is because it isn't 1.2345 anymore. 1.2345 cannot be represented
exactly in radix-2 floating point arithmetic.

I think maybe this is the reason: the first one, print will print it
out with a rounding to the 11th decimal point, therefore hiding any
floating point imperfection.

however, in the second one, print will not first round it off to the
11th decimal point with a subsequent rounding off to the 3rd decimal
point. In that case, the floating point imperfection is manifested.
(by thinking it is 1.2344999999999999)

a question is: since print can nicely hide and smooth out the floating
point imperfection, and probably most people prefer it that way, how

I wouldn't prefer it that way.

come the implementation of print "%10.3f" doesn't also do that --
eliminating the imperfection first, and then print it out accordingly.
I think one argument is the loss of precision, but we only print it,
rather than modify the number or the variable itself... hm... say, if
a bank uses python to print out the "change that should be returned to
the customer" using print "%20.2f", then there will be a cent missing
here and there... why not smooth out that imperfection and return that
penny to the customer? (not that they really care).

The decimal module will do what you want. One of its primary
motivations was correct rounding for financial activities.

casevh

 

[Duncan Booth]

how about the discrepancy between


1.234

the first one, print knows enough to recognize and print it as 1.2345.
however, in the second line, when it is round off, it doesn't know it
is 1.2345 any more.

But you wouldn't complain about this would you?
1.234

A value which is slightly than 1.2345 prints to 4 decimal places as 1.2345
and to 3 decimal places as 1.234.

That's all that happens with your value as well: 1.2345 is not exactly
representable as a floating point number, and the nearest representable
number is less than 1.2345.

 

[Steve Holden]

it seems that the behavior of "print" is that it will round off
properly for any floating point imperfection, such as shown in the
first two samples. The third sample seems to be a bug? It doesn't
know how to handle the floating imperfection in this case.

1.2344999999999999000000

You obviously haven't yet passed your floating-point number proficiency
test yet. Please restrict yourself to integers until you understand the
difficulties that inaccuracies in floating-point can create ;-)

regards
Steve

 

[Summercoolness]

But you wouldn't complain about this would you?

1.234

A value which is slightly than 1.2345 prints to 4 decimal places as 1.2345
and to 3 decimal places as 1.234.

That's all that happens with your value as well: 1.2345 is not exactly
representable as a floating point number, and the nearest representable
number is less than 1.2345.

This is the expected behavior though... even school when they first
teach "rounding off", they will tell you 1.23445 rounding off to 3
decimal places is not 1.235.... and i don't see anything weird about
the two lines above.

 

[Summercoolness]

You obviously haven't yet passed your floating-point number proficiency
test yet. Please restrict yourself to integers until you understand the
difficulties that inaccuracies in floating-point can create ;-)

hm, actually, i understand the limitation of floating point.
but my real concern is, how come "print" favors one version over the
other...
the first version will favor the correct rounding, while the second
doesn't favor it. to me, this is biased computing.... i will feel
happier if the behavior is consistent. (such as the first line
printing out as 1.2344999999999) . if most people favor the behavior
of line 1, that is, silently rounding off to about the 11th decimal
places, then why doesn't printing with formatting also use that same
behavior, which is rounding off to the 11th places first, and then
round off to whatever the user wants.

1.234

but then again, i just realize even if i do a

1.2344999999999999

so even if you round it off, it is still represented the same way....
still, how "print" handles 1.2345 and treating it and printing it as
1.2345, i wonder why we don't make the "print with formatting" the same
behavior, treating it as 1.2345 first and round it off to 1.235

 

[Roel Schroeven]

(e-mail address removed) schreef:

hm, actually, i understand the limitation of floating point.
but my real concern is, how come "print" favors one version over the
other...
the first version will favor the correct rounding, while the second
doesn't favor it. to me, this is biased computing.... i will feel
happier if the behavior is consistent. (such as the first line
printing out as 1.2344999999999) . if most people favor the behavior
of line 1, that is, silently rounding off to about the 11th decimal
places, then why doesn't printing with formatting also use that same
behavior, which is rounding off to the 11th places first, and then
round off to whatever the user wants.



but then again, i just realize even if i do a


1.2344999999999999

so even if you round it off, it is still represented the same way....
still, how "print" handles 1.2345 and treating it and printing it as
1.2345, i wonder why we don't make the "print with formatting" the same
behavior, treating it as 1.2345 first and round it off to 1.235

You do realize that your formatting uses less decimal places than the
print statement, do you?
1.2345

If you use 4 decimals after the decimal sign, you get the same result as
with a plain print statement (at least in this case). That means that
print is not treating it as 1.2345 first and then rounding it off to
1.235; it is just using the actual internal representation and rounding
it off to 1.2345. Which IMO is the only sensible thing one can do.

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

hm, actually, i understand the limitation of floating point. but my
real concern is, how come "print" favors one version over the
other...

It doesn't. int.__str__ and int.__repr__ have two different outputs.

try "print repr(1.2345)" and "print str(1.2345)"

so even if you round it off, it is still represented the same
way.... still, how "print" handles 1.2345 and treating it and
printing it as 1.2345, i wonder why we don't make the "print with
formatting" the same behavior, treating it as 1.2345 first and round
it off to 1.235

1.2344999999999999 is a closer and more accurate representation of
1.2345 than 1.235 is. That's why the former is favourable over the
latter.

Sybren

 

[Duncan Booth]

wrote:

This is the expected behavior though... even school when they first
teach "rounding off", they will tell you 1.23445 rounding off to 3
decimal places is not 1.235.... and i don't see anything weird about
the two lines above.

At least where I went to school they taught that the correct rounding was
to the even digit, so 1.2335 and 1.2345 would both round to 1.234.

However, that is irrelevant. The number in question here is
1.2344999999999999 and however you were taught to round numbers that ought
to round to 1.234 for 3 decimals, and 1.2345 for 4.

 

[Sybren Stuvel]

Duncan Booth enlightened us with:

At least where I went to school they taught that the correct
rounding was to the even digit, so 1.2335 and 1.2345 would both
round to 1.234.

Check out http://en.wikipedia.org/wiki/Rounding, there is no single
correct way to round numbers.

However, that is irrelevant. The number in question here is
1.2344999999999999 and however you were taught to round numbers that
ought to round to 1.234 for 3 decimals, and 1.2345 for 4.

According to most methods, indeed

Sybren