[Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[Nick Coghlan]

Ron Adam wrote:
> Consider an example where you are combining data that had different 
> number of significant digits.  Keeping all the digits of your answer 
> gives a false since of accuracy.  The extra digits are meaningless 
> because the margin of error is greater than any of the digits that 
> exceed the minimum number of significant digits in your data.  So you 
> need to remove the extraneous digits by rounding.  Then this answer can 
> be further used as data, and sense the number of significant digits is 
> maintained, the margin of error can be calculated accurately.

This is a fallacy though - add two numbers together each with an error of +/- 
0.05, and the error in the total is +/- 0.1. The approach you propose gives 
the misleading impression that the error in the total is still only +/- 0.05 
(as the answer will contain 1 decimal place).

If you really care about error, you need to do it properly (e.g. stddev or 
adding the error margins).

Anyway, it's not proposed to remove the "round to x decimal places" capability 
entirely - merely remove it from the builtin round() so that the return type 
can be changed.

> It makes since for round have an argument to specify the number of 
> digits of precision to round to and also for it to return floating point 
> numbers because rounding results to a float of n digits of precision is 
> a necessary operation.
> 
> If you have the default round() case of 0 (and negative) digits of 
> precision return integers, you then have a function that may sometimes 
> returns integers, and sometimes returns floats.

That's not the proposal, as Greg has already said (the fround() mentioned 
would probably be 'math.fround' rather than a builtin):

[Greg Ewing]
> No, round() wouldn't have that option at all. If
> you wanted it, you would use fround() instead,
> which would have the option and return a float
> always.
> 
> This would be a Py3k thing, obviously. If done
> before then, the new function would have to be
> given a different name.

[Ron Adam]
> This can be problematic 
> if the values are further used in division operations.  Which will 
> result in many cases of.. float(round(x)) in order to convert integer 
> results back to floats.

Not in Py3k where int/int will return a float as needed.

> And in regard to using round() combined with division operators in 
> floating point math, it is an issue of least surprises.

And in Py3k, with a round that always returned an integer there wouldn't be 
any surprises at all:
   - division would do the right thing, because true division becomes the only 
behaviour for '/'
   - the result of the builtin rounding operation would be usable directly as 
an index without requiring subsequent coercion to an integer

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org