Talk:Integer square root

message: If someone with Maple, Mathematica, etc. and would graph a function of isqrt, that would be very appreciated.  I have use of Maple over Putty, but it displays graphs with ASCII characters, and it's hideous to look at.  Iamunknown 09:26, Sep 13, 2004 (UTC)-
:On second thought, is a graph necessary?  Opinions, please. Iamunknown 18:53, 28 July 2006 (UTC)
thread_title: Request for a picture

message: Is anyone interested in the divison-free algorithm for the square root? Obviously it only converges linearly rather than quadratically, but, especially in binary, it might be faster anyway. —The preceding unsigned comment was added by 80.175.250.218 (talk • contribs) 10:46, 31 October 2005 (UTC)
replies: text: Actually, now that I think about it, it's only purely division-free in binary, not in other bases. —The preceding unsigned comment was added by 80.175.250.218 (talk • contribs) 10:48, 31 October 2005 (UTC)
thread_title:  Division-free square root 

message: The algorithm given in the article
: x_{k+1} = \frac12\left(x_k + \frac n{x_k}\right), \ k \ge 0.
with x_0=n works if you do integer calculations, too (truncate when dividing).  Then the algorithm terminates when x_{k+1}=x_k.  And as far as I can see, it actually converges a little faster.  Wouldn't it make more sense for the article to do everything in terms of integers, instead of rationals?  dbenbenn | talk 09:45, 18 March 2006 (UTC)
thread_title:  Algorithm in terms of integers 

message: Would it be appropriate to post the following C code in the article?
It is fast and tested:
#include <stdio.h>
/*
 * Return the truncated integer square root of "y" using longs.
 * Return -1 on error.
 */
long
lsqrt(long y)
{
        long    x_old, x_new;
        long    testy;
        int     nbits;
        int     i;
        if (y <= 0) {
                if (y != 0) {
                        fprintf(stderr, "Domain error in lsqrt().\n");
                        return -1L;
                }
                return 0L;
        }
/* select a good starting value using binary logarithms: */
        nbits = (sizeof(y) * 8) - 1;    /* subtract 1 for sign bit */
        for (i = 4, testy = 16L;; i += 2, testy <<= 2L) {
                if (i >= nbits || y <= testy) {
                        x_old = (1L << (i / 2L));       /* x_old = sqrt(testy) */
                        break;
                }
        }
/* x_old >= sqrt(y) */
/* use the Babylonian method to arrive at the integer square root: */
        for (;;) {
                x_new = (y / x_old + x_old) / 2L;
                if (x_old <= x_new)
                        break;
                x_old = x_new;
        }
        return x_old;
}
I have thoroughly tested this code and guarantee it is correct. --Gesslein 16:20, 2 July 2006 (UTC)
replies: text: I do not know.  I started a Integer square root codebase on Wikisource which was eventually deleted, because (although the programs in each language worked) the programs were original contributions.  I think that applies to this article and would thus forbid you to place that code in the article, but I will forward the query to Charles Matthews, a prominent mathematics administrator.  This article itself, however, may be an original contribution.  He will be more likely to know than I. Iamunknown 20:03, 18 July 2006 (UTC)

text: I thought the terms of Wikipedia edits were "No original research".  Contributions should always be welcome :-) --Gesslein 18:53, 28 July 2006 (UTC)

text: I agree that contributions should always be welcome.  The proposed mathematics convention for algorithms, however, suggests that "Algorithms, like all other content in Wikipedia, should be traceable to reliable, published sources. Every presentation of an algorithm (both pseudocode and sample code) should include a citation."  I agree with this, even though abiding by it currently prevents your code from inclusion. Iamunknown 19:34, 28 July 2006 (UTC)

text: Thanks for your thoughts on this.  The algorithm used is Newton's method (also called the Babylonian method) described in the article.  It gets a speed increase from using binary logarithms to select the starting value.  --Gesslein 19:40, 28 July 2006 (UTC)
thread_title: Integer square root code in C

message: I would like to suggest that the definition is extended from 'a positive integer n' to 'a non-negative integer n', which would be in line with the definition of the (real-number domain) square root.
If that is accepted, it should be stated that the algorithm is only suitable for finding isqrt(n), n > 0.
Lklundin 09:53, 8 March 2007 (UTC)
thread_title:  Extend definition to include zero 

message: Currently, there is a statement in the Algorithm section with an unsourced statement that |x_{k+1}-x_k|<1 implies \lfloor x_{k+1}\rfloor=\lfloor\sqrt n\rfloor, which is not actually difficult to prove (contrary to what the text suggests). Of course, I can't cite myself, since that's original research. I'm going to remove the claim that the proof is not trivial; if anybody objects, reply here. (Oh, and no offence to the person who wrote that it isn't trivial.) CHL (aka yse) (talk) 07:28, 20 October 2009 (UTC)
thread_title:  Stopping criterion 

message: I doubt that √n is irrational for almost all n. I can easily give infinitely many n, such that √n is rational (even an integer).
Maybe something like "for most n" was meant, though strictly this is not correct either, as there are exactly as many square numbers as non-square numbers ... --134.102.204.124 (talk) 16:17, 21 February 2012 (UTC)
replies: text: It is irrational for almost all n, insofar as it is rational for a set of measure 0. CRGreathouse (t | c) 18:50, 21 February 2012 (UTC)

text: There are much more irrational numbers than rational numbers.  — Preceding unsigned comment added by 129.97.171.175 (talk) 21:41, 3 March 2014 (UTC)
thread_title:  irrational for "almost all"? 

message: ===Ad 'Algorithm using linear search'===
*In the previous revision(s) the C-code was changed. The type of the functions was changed from unsigned long long int to int.
:Comment: In a fragment further down sub 'Example implementation in C' the type used was unsigned long.Another fragment (further down) is not in C. An article should be consistent in style, so a mix of data types should be based on a reason, which here I do not see. I admit that by introducing unsigned long long int myself I did not stick to this design principle. I fixed this in the current release by changing the type throughout to unsigned long. Whatever the outcome shall be, I am in favour of keeping unsigned, to visualize that negative numbers are disallowed.
*The code
:
x = 1;
while( x * x <= y )
	x = x + 1;
:was changed to
:
for( x = 1; x * x <= y; ++x )
	;
:This is a change of syntax only. As a professional C-veteran myself I have no problems at all with this for-statement. My decision to use an equivalent while is based on the consideration that the present article is not an article about C. The readers can be expected to know some Pascal or Algol or BASIC or ... . Pseudocode too. But they are not necessarily experts in C. A for statement like this will pull many off. On the other hand the C-programmers also understand the while-construct. So why not stay on common ground?
===Ad 'Algorithm using binary search'===
*The assignments L = 0; R = y; are illegal without previous declaration of these variables. The code does not compile. I fixed this.
*In the previous revision the test while( L != R - 1 ) was changed to while( L < R - 1 ). The author hailed this as an increase of robustness. I disagree. For a while (condition){...} loop to be valid, the condition must at some point turn False. If the != condition is never met then the loop will run forever. An unexpected eternal loop is made more unlikely by strengthening the termination condition to <. As the procedure is designed to reach an = situation, the defensive reflex to allow illegitimate variable values to become even more illegitimate cannot be called 'more robust'. On the theoretical side see the following informal example.
*An inline variable declaration int const was introduced. This is not possible in many other languages. The attention is deflected to considerations about const and scope. Avoid! Keep it simple.
*I further simplified the code, keeping the proposed name change M instead of x.
*It was incorrectly mentioned that the linear search on input  would need  steps.  steps are needed.
===Reply===
In 'Algorithm using linear search',
you convinced me to keep the while loop, which indeed makes to code more understandible to non-C-programmers.
However, for a similar reason, I'd still suggest to keep the involved types (throughout the whole article) as easy as possible. That is, long should be avoided, as it is very specific to C. My personal taste would also omit unsigned, but you have a point in explicitly disallowing negative numbers.
In 'Algorithm using binary search', you convinced me that != in the loop condition is more robust than  < . On the other hand, the latter indicates the loop invariant L <= R in a better way. If you insist on !=, I won't object any further. As for the declaration of M, as far as I know, many languages allow new local declarations at the beginning of a block, i.e. immediately after a {. I found programs easier to understand if variable scopes are as small as possible, and if immutible variables are used whenever possible (using const in C); however, for a demonstration program of this small size, it doesn't make much difference, so I don't want to argue any further about this, either. In the while condition, I'm still in favor of omitting the parantheses; the involved operator priorities are the same in all programming languages I know, and in mathematics, so the expression is understandible for anybody without parantheses. Finally, you are right with 1414 vs. 2000000. - Jochen Burghardt (talk) 10:23, 8 December 2021 (UTC)
thread_title: Notes ad Revision 08-12-2021 (01:11)

message: In 'Algorithm using linear search',
you convinced me to keep the while loop, which indeed makes to code more understandible to non-C-programmers.
However, for a similar reason, I'd still suggest to keep the involved types (throughout the whole article) as easy as possible. That is, long should be avoided, as it is very specific to C. My personal taste would also omit unsigned, but you have a point in explicitly disallowing negative numbers.
In 'Algorithm using binary search', you convinced me that != in the loop condition is more robust than  < . On the other hand, the latter indicates the loop invariant L <= R in a better way. If you insist on !=, I won't object any further. As for the declaration of M, as far as I know, many languages allow new local declarations at the beginning of a block, i.e. immediately after a {. I found programs easier to understand if variable scopes are as small as possible, and if immutible variables are used whenever possible (using const in C); however, for a demonstration program of this small size, it doesn't make much difference, so I don't want to argue any further about this, either. In the while condition, I'm still in favor of omitting the parantheses; the involved operator priorities are the same in all programming languages I know, and in mathematics, so the expression is understandible for anybody without parantheses. Finally, you are right with 1414 vs. 2000000. - Jochen Burghardt (talk) 10:23, 8 December 2021 (UTC)
thread_title: Reply

message: From the section Introductory remark I removed the sentence (which I had introduced myself):
:"One can define \sqrt y to be the number for which there is an algorithm — more precisely: "Turing machine" — which, given a second input parameter k, terminates with the decimal representation of \sqrt y truncated to k decimal digits."
My reasons for removal were:
* It looks like the definition of \sqrt y is self-referential, as \sqrt y appears in the definiens as well as in the definiendum. It is not, but a second thougth is required.
* The notion of "algorithm" is too broad, as it carries on its back the Church–Turing thesis. "Turing machine" is a more restrained concept. On the other hand I did not want to talk about Turing machines in this article.
* The removed sentence is not neccessary for the remark I make. The sentence might even obnubilate my point to some extent.
My revision has been reverted with the comment: "unexplained content removal".
As the content removal is explained here, I will "undo".
Marc Schroeder (talk) 20:31, 27 February 2022 (UTC)
thread_title: Notes ad Revision 27-02-2022‎ (16:51)

message: As written, the program does not produce correct results for all input (e.g. for input 8 the program produces 3 and not the desired 2). This may have been an attempt to modify the algorithm to avoid needing to repeatedly insert zeros into digits as described in the referenced paper (see step R2 on page 1), which would involve more complicated arithmetic. 2604:3D08:6881:4A00:D9A0:6FE3:4F1F:17DE (talk) 17:50, 12 September 2022 (UTC)
thread_title:  Suggest correction or removal of "... using subtraction section"