M.-A. Lemburg wrote: > If you are eventually rounding to say 2 decimal > places in the end of the calculation, you won't > want to find yourself presenting the user 1.12 > and 1.13 as equal values :-) Even if, before rounding, they were actually 1.12499999999 and 1.125000000001? And if the difference were only due to the unrepresentability of some decimal fraction exactly in binary? I still maintain that (a) rounding a *binary* float to *decimal* places is wrongheaded, and (b) digit chopping is a bad way to decide whether two inexact numbers should be considered equal. Not just a different way, but a poorer way. > Most > such calculations do work with floats, so having > round() return an int would just add another > coercion to a float for those use-cases. I'm *not* proposing to eliminate round-to-float, despite the fact that I can't see much use for it personally. I'm also *not* advocating changing the existing behaviour of round() or int(). That was just tentative speculation. All I'm asking for is another function that does round-to-int directly. I wouldn't have thought that was such a controversial idea, given the frequency of use for that operation. -- Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4