round in 2.6 and 2.7

[Hrvoje Niksic]

I stumbled upon this. Python 2.6:

Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.10.0

So it seems that Python is going out of its way to intuitively round
9.95, while the repr retains the unnecessary digits. However, with 2.7
it's exactly the opposite:

Python 2.7.0+ (r27:82500, Sep 15 2010, 18:04:55)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.9.9

Is the change to round() expected?

 

[macm]

I stumbled upon this.  Python 2.6:

Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.>>> 9.95
9.9499999999999993
10.0

So it seems that Python is going out of its way to intuitively round
9.95, while the repr retains the unnecessary digits.  However, with 2.7
it's exactly the opposite:

Python 2.7.0+ (r27:82500, Sep 15 2010, 18:04:55)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.>>> 9.95
9.95
9.9

Is the change to round() expected?

My guess is

use decimal module.

Regards

mario

 

[Martin v. Loewis]

Type "help", "copyright", "credits" or "license" for more information.

10.0

So it seems that Python is going out of its way to intuitively round
9.95, while the repr retains the unnecessary digits.

The 2.6 result is simply incorrect. 9.95 cannot be represented as a
floating point number; the number that is closest to it is actually
smaller than 9.95. Rounding that number should give 9.9 (or something
close to it - 9.9 cannot be represented, either), not 10.0.

9.9

Is the change to round() expected?

Yes. It's a bug fix described in "What's new in Python 2.7" thus:

Float-to-string and string-to-float conversions are correctly rounded.
The round() function is also now correctly rounded.

Not sure that this is correct English; I think it means that the
round() function is now correct.

Regards,
Martin

 

[Stefan Sonnenberg-Carstens]

Am 23.12.2010 19:57, schrieb Hrvoje Niksic:

I stumbled upon this. Python 2.6:

Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.10.0

So it seems that Python is going out of its way to intuitively round
9.95, while the repr retains the unnecessary digits. However, with 2.7
it's exactly the opposite:

Python 2.7.0+ (r27:82500, Sep 15 2010, 18:04:55)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.9.9

Is the change to round() expected?

Indeed:
http://svn.python.org/view?view=rev&revision=76373

 

[Hrvoje Niksic]

Type "help", "copyright", "credits" or "license" for more information.
10.0

So it seems that Python is going out of its way to intuitively round
9.95, while the repr retains the unnecessary digits.

The 2.6 result is simply incorrect. [...]
Yes. It's a bug fix described in "What's new in Python 2.7" thus:

That makes sense, thanks. Even within Python 2.6, rounding with
different methods could produce inconsistent results:
'9.9'

 

[Mark Dickinson]

I stumbled upon this.  Python 2.6:


10.0

So it seems that Python is going out of its way to intuitively round
9.95, while the repr retains the unnecessary digits.

No, Python's not doing anything clever here. Python 2.6 uses a simple
rounding algorithm that frequently gives the wrong answer for halfway
or near-halfway cases. It's just luck that in this particular case it
gives the apparently-correct (but actually incorrect) answer.
Martin's already explained that the 2.7 behaviour is correct, and
agrees with string formatting. However, note that there's still a
disconnect between these two operations in Python 2.7:
'1.2'

That's because 'round' in Python 2.x (including 2.7) still rounds
exact halfway cases away from zero, while string formatting rounds
them to the value with even last digit. In Python 3.x, even this
discrepancy is fixed---everything does round-halfway-to-even.

Is the change to round() expected?

Expected, and intentional.

[Martin]

"Float-to-string and string-to-float conversions are correctly rounded.
The round() function is also now correctly rounded."

Not sure that this is correct English; I think it means that the
round() function is now correct.

Well, the correct result of the example the OP gave would be 9.9
exactly. But since 9.9 isn't exactly representable as a Python float,
we necessarily get an approximation. The language above is intended
to convey that it's the 'correctly rounded' approximation---that is,
the closest Python float to the true value of 9.9 (with halfway cases
rounded to even, as usual).

Mark

 

[Martin v. Loewis]

"Float-to-string and string-to-float conversions are correctly rounded.

Well, the correct result of the example the OP gave would be 9.9
exactly. But since 9.9 isn't exactly representable as a Python float,
we necessarily get an approximation. The language above is intended
to convey that it's the 'correctly rounded' approximation

I see. Shouldn't it say then "The round() function
gives/produces/returns correctly rounded results now", instead of saying
that
the round function *is* correctly rounded? ISTM that the round
function cannot be rounded (correctly or not):

py> round(round)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: a float is required

But then, I'm not a native speaker (of English).

Regards,
Martin

 

[Terry Reedy]

The second line was written to be parallel to the first, but the first
is slightly ambiguous in that 'conversions' can refer to either process
(not rounded, correctly or otherwise ;-) or result. However the
parallelism does not does as 'round() function' is the instrument of the
process and definitly not the result.

....

I see. Shouldn't it say then "The round() function
gives/produces/returns correctly rounded results now", instead of saying
that
the round function *is* correctly rounded? ISTM that the round
function cannot be rounded (correctly or not):

In 2.7 "Float-to-string and string-to-float conversion results are
correctly rounded, as are the results of the round() function."

 

[Mark Dickinson]

I see. Shouldn't it say then "The round() function
gives/produces/returns correctly rounded results now", instead of saying
that
the round function *is* correctly rounded? ISTM that the round
function cannot be rounded (correctly or not):

py> round(round)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: a float is required

But then, I'm not a native speaker (of English).

I dare say that you're just as much a native speaker as anyone else
when it comes to the language of floating-point arithmetic. Not sure
English comes into it that much.

Sure, I agree it's probably a slight abuse of language to refer to a
function as 'correctly rounded', but I think it's a fairly standard
abuse. From the two nearest references to hand: IEEE 754-2008 has a
whole section entitled 'Recommended correctly rounded functions' (nit:
shouldn't there be a hyphen in that title?), and persists in referring
to 'correctly rounded' conversions. The more formal uses in that
document do indeed refer to single values, though. ("A conforming
function shall return results correctly rounded ...") The 'Handbook of
Floating-Point Arithmetic' by Muller et. al. gives a definition of a
correctly rounded function in section 2.2. "When the exact result of
a function is rounded according to a given rounding mode ..., one says
that the function is *correctly rounded*."

It's not so dissimilar from other mathematical abuses, like describing
a real-valued function as 'positive', when what you actually mean is
that all its values are positive.

It's also slightly unsettling usage for me, not least because the
statement 'f is correctly rounded' for a floating-point function f is
really a statement about *two* functions: namely, f (a function from
floating-point numbers to floating-point numbers) and the true
mathematical function that it's based on; the identity of the
underlying mathematical function is left implicit.