PEP proposal for round(x,n) enhancement

[Markus Schaber]

Hi,

Chris Barker <chrishbarker at home.net> schrub:

> Markus Schaber wrote:
> 
>> And this is what I meant - the float doesn't store how many digits
>> are significant, so when you round to n digits, you often get an
>> approximation to the rounded number, and this way don't have any
>> information about the accuracy afterwards.
> 
> OK, I get it now, but this doesn't make the proposal any more useless
> than the current round.
>>>> round(0.2,3)
> 0.20000000000000001

That's correct.
 
> Just because Python doesn't store any information about the accuaracy,
> doesn't mean that the programmmer doesn't know what was done. If you
> take this now stored number and display the first <17 digits, it will
> display what is wanted, and if you do calculations with it, it will do
> what is wanted as well (as well as FP ever can).

Also ack. 
 
>> My proposal only has to do with enhancing the
>> > syntax used by the round() function.
>> 
>> And enhancing the semantics :-)
> 
> True, which is why I'd be just as happy to see it in a separate
> function.

Which is what I would clearly prefer.
 
> Note: the current round() will accept decimal input, even if it
> doesn't do anything with it, so adding this functionality does hav
> ethe potential to break someones code, somewhere:
> 
>>>> round(1.2345,2.3)
> 1.23
>>>> round(1.2345,0.3)
> 1.0
>>>>

And I would rather expect round with fractional arguments to round to 
something like 2.3 digits (e. G. round to 0.5 digits rounds to the 
nearest multiple of 0.2) so I think the current round should give an 
error when called with a float that doesn't convert to an integer 
seamlessly.

markus
-- 
"The strength of the Constitution lies entirely in the determination of 
each citizen to defend it. Only if every single citizen feels duty 
bound to do his share in this defense are the constitutional rights 
secure." -- Albert Einstein