Tim Peters <t...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue46187>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
