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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
