PEP proposal for round(x,n) enhancement

[Chris Barker]

Tim Peters wrote:

> > I think it was in reply to the issue that floating point numbers are
> > stored in binary internally, so if you round to n decimal digits, the
> > internal representation may still require all digits (or moare, of
> > course) to represent. I think what he meant to say was:
> >
> > The proposal is not concerned with how numbers are represented
> > internally, just with what the values are, which, to the degree it is
> > possible, should be the value rounded appropriately to the required
> > decimal digit.
> 
> Doesn't sound much like "just with how they are printed" to me -- but you're
> not *required* to have the same agenda as his <wink>.

No, we're not, but having followed this entire thread, I really don't
think he is concerned only with printing, that particular statement not
withstanding.

> >>> float("%.3g" % 1234)
> 1230.0
> >>>
> 
> That is, you're not required to print the result, and it's trivial to
> convert it back to a float (if that's what *you* want).

I did think of this, and it would be one easy way to write a SigFig()
function. Do you trust implimentation to do it consistantly and
accurately??? And is it efficient? and how hard would it be to make a
NumPy Ufunc out of it.
 
> > I use round All the time!! when converting a float to an integer,
> > sometimes I want floor(), sometimes ceil() and sometimes round()
> 
> I usually know I'm mucking with a positive float, and if I need it rounded
> to an int (and know that it fits in an int!) do int(x + 0.5).  Partly that's
> because I know exactly what that expression does (and am prepared to take
> the blame for the biased rounding in halfway cases), while round() can
> introduce multiple rounding errors

I'm curious why that would be...

(and errors you can't analyze without
> studying the implementation --

True. but this is the case with all floating point functions. Must of us
would be perfectly happy with a a good round function, and would rather
the wierd details were worked out by folks that know more than me about
FP. While I may know what int(x + 0.5) does, I might not have been aware
of the biased rounding issue.

Having a nice round() and SigFig function would in no way preclude you
from using your own hand written version.

> when you wrote "to the degree it is possible above, you weren't describing Python's builtin round.

Too bad. Does it have a major flaw we should address?

> As above, printing isn't required.

no it's not, but using a printing formatting statement to round a nuber
seems like kind of a round about way to do it... and do you trust it any
more than you do round()? or Christopher Smith's proposed function? By
the way, I'd love to have anyone who really knows the ins and outs of FP
to comment on his proposed function.

> BTW, I'd much rather have a round()
> function that specified the number of significant bits.

That would be handy, and I did suggest the the proposed SigFig()
function allow you to specify the base. base 10 and 2 would be the most
common, of course, but people might have a reason to use another base as
well.

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------