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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
