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

[Ron Adam]

Greg Ewing wrote:
> Raymond Hettinger wrote:
> 
>> -1 on an extra built-in just to save the time for function call
> 
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards. At
> least nobody has put forward an argument to
> the contrary yet.

I'll try to give a valid argument of the contrary.

I think you are only considering part of the usefulness of round().  In 
statistics and science math equations, rounding isn't used to get an 
integer, but instead used to give an answer that is meaningful within 
the margin of error of the data being used.

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.


[ NOTE: While floating point may contribute a significant error to value 
that are very large or very small, in most cases it is a very small 
amount in relation to the precision of the calculation and so the error 
can be managed without too much trouble.  In cases where it is a 
significant factor, another internal representation should probably be 
considered.  I only mention it here because someone would point it out 
(again) anyway. The accuracy of floating point is not the issue being 
discussed in this thread. ]


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. 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.

      See pep-0238:  Changing the division operator.

      http://www.python.org/dev/peps/pep-0238/

While it is true we often will use round along with converting to an 
integer, it is also true that functions that are predictable and return 
a single type are easier to use and learn.  So the question of which is 
better is a matter of point of view in this respect.

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


> Sure you can define your own function to do
> this. But that's still a considerable burden
> when you add up the effort over all the
> programs that use int(round()).

I think the only time it would be a burden is if a single program uses 
int(round()) many times, otherwise it is only a very small additional 
amount to type for each program.  In the case of single program using it 
many times, a helper function is a very practical solution.


Cheers,
   Ron