PEP proposal for round(x,n) enhancement
Christopher Smith
csmith at blakeschool.org
Wed Sep 12 18:11:23 CEST 2001
I am the proposer of the enhancement and unfortunately did not catch the
first few posts that people made regarding the proposal, but would like ot
address the issues that are arising.
python-list at python.org writes:
>But - AFAIK - Matlab can do decimal calculations, while python is stuck
>to the clib's FP (usually IEEE those days) base-2 numbers which cannot
>exactly represent such numbers. Just try
>>>> 1/5.
>0.20000000000000001
>(Tested on my Python 2.0.1 (#0, Jun 23 2001, 23:50:30))
>
>Maybe we should think about fixed and floating point decimal numbers
>(using string or bcd internal representation) for inclusion in Python.
>Of course, this leads to complex decimals and even rationals composed
>of complex decimals, too :-)
This is a totally different issue. The proposal is not concerned with how
numbers are represented internally, just with how they are printed.
Presumably that is one thing that the round(x,n) function is for--it let's
me through away information that I don't want. What is inconvenient, as
someone else noted--is that while the magnitudes of numbers can vary wildy
(especially in the sciences) the number of digits past the first non-zero
digit often do not...in general, regardless of the magnitude of the
number, I would often not want more than the first 3 digits.
example:
3.0 cm (+/- 1 mm) = 1.1811023622 inches which is about 1.18 inches; I
would have to tell round to round to n=2
3 km (+/- 10 m) = 118110.23622 inches which is about 118000 inches; I
would have to tell round to round to the -3 digit (n=-3)
There should be away to say "round to the 3rd digit from the first
non-zero digit.
>
>
><running away fast>
>
>> It probably should be a separate function from round, rolling it into
>> round seems a little too convoluted and confusing to me.
>
>I fully agree to this, expecially not using floats vs. ints as the
>second argument, as someone proposed.
I am not opposed to a new name--chop seems acceptable and if this were
indeed the same thing as what MATLAB did then this would make sense to
keep the name in Python. I did find that one of the MATLAB toolboxes uses
chop to break a speech file into smaller pieces.
My rational for proposing that it be wrapped into the round() function is
that conceptually you are doing rounding to a digit measured from the
first non-zero digit not the 1's place; you aren't chopping the number off
or truncating it. The positive and negative integer domain is already
interpreted as "to the right" and "to the left" of the 1's place,
respectively. Since the round function already permits floats as the
argument I tried to think of a simple way to use float's to do the job.
round(x,n=0)
if n=integer then round to the 10^(-n)'s digit
if n<>integer the number will be rounded so as to keep the first 10*n
digits of the number (e.g. n=0.1 will keep only the first non-zero digit
while n=0.4 will keep the first 4 digits of the number; the magnitude of
the number is maintained so round(0.0001238, 0.3) will return 0.000124)
BTW, the original post has the workaround; it's very easy to do what I am
proposing...I would just like to see this be a built in.
I have checked both the Scientific and Numeric packages. While they do
allow for extended sorts of formatting (like Fortran formats, etc...) I do
not see this sort of functionality built into them.
/c
More information about the Python-list
mailing list