[issue46187] Optionally support rounding for math.isqrt()

[Tim Peters]

Tim Peters <tim at python.org> added the comment:

I've made several good-faith efforts to find any hint of demand for rounded isqrt on the web; I've found no direct support for it in other languages/environments(*); and the one use case you presented isn't compelling. Building static tables to help implement extended precision functions via scaled integer arithmetic is quite niche, and anyone numerically knowledgeable enough to pull that off will have no trouble figuring out how to roll their own isqrt rounding. For them, isqrtrem would make it dead easy.

Close to no demonstrated demand, and no demonstrated prior art, coupled with slowing down _every_ isqrt() call to cater to an overwhelmingly unused possibility (and, to boot, via the slowest possible way of specifying an option, on what should be a fast function), leaves me -1. No, I'm not a fan of the "big"/"little" mandatory arguments to int.{from,to}_bytes() either.

+0 on isqrtrem, though, because it follows established practice in a related context (mpz), and also offers efficient support for the related use case I actually found some (albeit small) demand for ("and was it a perfect square?").

(*) Other languages with an integer square root include Common Lisp, Julia, and Maple's programming language. None have an option for rounding. Maple's doesn't define the rounding used, other than to promise the result is less than 1 away from the infinitely precise result. Common Lisp and Julia return the floor. A number of environments essentially inherit isqrt from their Lisp base (e.g., wxMaxima).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue46187>
_______________________________________