[issue31978] make it simpler to round fractions

Wolfgang Maier added the comment: That, of course, wasn't my original suggestion, but since Mark started discussing other possible forms this could take, like round-to-nearest analogs of mod and divmod, I thought maybe it's worth pointing out this aspect and, yes, maybe the three-argument for

[issue31978] make it simpler to round fractions

Serhiy Storchaka added the comment: Mark said about round(x/y), not round(x/y, 1). Do you propose to add a three argument divide_and_round(x, y, ndigits)? -- ___ Python tracker __

[issue31978] make it simpler to round fractions

Wolfgang Maier added the comment: >>> for x in range(1,501): for y in range(1,501): if round(x/y, 1) != float(round(F(x,y), 1)): print(x,y) where F is fractions.Fraction Sorry! -- ___ Python tracker

[issue31978] make it simpler to round fractions

Wolfgang Maier added the comment: > (E.g., if both `a` and `b` are not-too-large integers, `round(a / b)` is > still "safe" in that it will give the same result as if a non-lossy integer > division is used.) Well, it does not take particularly large a and b to break round's tie-breaking thro

[issue31978] make it simpler to round fractions

Mark Dickinson added the comment: > I don't know whether there is a common enough need in third-party code. Me neither. But one thing to look for would be people doing `round(a / b)`, which is almost certainly giving the wrong result in corner cases. OTOH, even those uses may well be in code

[issue31978] make it simpler to round fractions

Serhiy Storchaka added the comment: I thought about adding a public function in the math module when worked on one of that functions. But there are not many cases for it in the stdlib (datetime, fractions, decimal, and maybe it's all). I don't know whether there is a common enough need in thi

[issue31978] make it simpler to round fractions

Wolfgang Maier added the comment: ok, I agree with you that the returned type should not change with the value of an argument. I simply didn't think one vs two argument versions here, but in terms of three different code branches where one returns int already. Maybe 'slight' was the wrong word

[issue31978] make it simpler to round fractions

Mark Dickinson added the comment: On the main proposal: rounding an integer division to the nearest integer does seem to be a somewhat common need, and one that's not entirely trivial to code up and get right first time. (Unlike floor or ceiling of a quotient, which can be simply spelled as `

[issue31978] make it simpler to round fractions

Mark Dickinson added the comment: > There is one slight additional tweak in the patch: in the case of ndigits < > 0, it returns an int, not a Fraction (see test_fractions modification to make > it pass). This would be a backwards incompatible change, potentially breaking existing code, so we

[issue31978] make it simpler to round fractions

Serhiy Storchaka added the comment: See also _divide_and_round() in Lib/datetime.py, _div_nearest() in Lib/_pydecimal.py and _PyLong_DivmodNear() in Objects/longobject.c. -- nosy: +belopolsky, facundobatista, rhettinger, serhiy.storchaka, skrah, stutzbach versions: -Python 3.8 _

[issue31978] make it simpler to round fractions

New submission from Wolfgang Maier : Hi, because of floating point inaccuracies it is suboptimal to use round(int1/int2) for rounding of a fraction. fractions.Fraction, OTOH, offers exact rounding through its implementation of __round__, but using it requires users to create a fractions.Fracti