Nick Coghlan wrote:
> 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).
I did say "the margin of error can be calculated accurately". I did not
go into detail on the correct method to do that. You do need to round
to the correct number of significant digits AND yes, you do need to also
take into account the number of items in your data set.
If you don't round, the value of your answer would be shifted up or down
by the amount of the non significant digits. And the error range would
also be shifted up or down by that amount.
In any case, my point is (and my opinion) that rounding to floating
point types is very common and not something that is needed rarely as it
has been expressed in several messages. I don't want to debate the
correct method of calculating errors and maintaining accuracy in
statistical equations. I'll let the mathematicians do that.
> If you really care about error, you need to do it properly (e.g. stddev
> or adding the error margins).
Yes
> 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.
That would work.
This is one of those places where I wonder when should a function be
included in a types methods and called by either using arguments with
__init__, an external function to call a private method, or by having it
be a public method to be called with the dot syntax like is common for
strings?
If you look at the Decimal type, it has quite of few rounding methods,
(as well as other non-underscored methods), while int, float, and long,
do not have them. Also the Decimal _round() method returns the number
unchanged (max precision) if no precision argument is given where
round() has a default precision of 0.
Will there be more efforts (in Py3k to unifiy Decimal and the other
types so they are more alike in both the way they work and in how they
are used?
Would it make since for the numeric type to have methods (other than the
underscored ones) that can be called with the dot syntax like we do in
unicode and the Decimal types that do not have the underscores? Or
would it be better to remove those in favor of builtin or module
functions? The extremes of both might be a foolish consistency, but
this may also be a good area to make some basic improvements for python
3k. (I'm sure Guido and others here have though some on this in general.)
If these types gain a round method that all work the same way, then
round() can then use those and it would return the same type as it is
given. So then round(float(x)), round(int(x)), round(long(x)) and
round(Decimal(x)) will return their own type respectfully.
And to get a specific type, you would call the types method directly.
int.round(x) -> integer
Which is nicer than int(round(x)).
And the round methods could have arguments to designate the type of
rounding to use. Where 'f','c', and 'e' are floor, ceiling, and even
rounding.
int.round(x, 'c') # 'f' is the default rounding mode
The functions round(), roundcieling(), and roundeven() could then call
the method of the type with the appropriate argument, although I'd be
happy without these round functions if there are round methods are
consistent across types.
Well, this is the direction I would go in. Hopefully by Python 9000 the
decimal type or something equivalent will be as fast as all the others
and/or computers will be so fast as to make it irrelevant, then we can
have just one scaler base type. ;-)
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
