Talk:Square root algorithms: Difference between revisions

Content deleted Content added
Update archiving templates after a page move (Report bot issues)
 
(11 intermediate revisions by 7 users not shown)
Line 1:
{{User:MiszaBot/config
| algo = old(360d)
| archive = Talk:MethodsSquare ofroot computing square rootsalgorithms/Archive %(counter)d
| counter = 1
| maxarchivesize = 150K
Line 8:
| minthreadsleft = 5
}}
{{WikiProject banner shell|class=C|
{{Maths rating|class= Start|importance= low|field= analysis}}
{{WikiProject Mathematics|importance= low}}
}}
{{archive box|auto=long}}
 
Line 26 ⟶ 28:
 
That cryptic constant is actually a composite of three bitfields, and twiddling it requires some understanding of what those fields are. It would be clearer, but a few more operations, to do that line as a pair of bitfield extract/inserts. But we're saving divides in the subsequent iterations, so the extra 1-cycle operations are a wash.
 
== {=3 } =4 ==
 
In procedure int32_t isqrt(int32_t n)
* 3 left curly brackets
* 4 right curly brackets [[User:Jumpow|Jumpow]] ([[User talk:Jumpow|talk]]) 20:37, 21 December 2021 (UTC)
 
:I tried to fix it. Is it OK now? [[User:JRSpriggs|JRSpriggs]] ([[User talk:JRSpriggs|talk]]) 22:57, 22 December 2021 (UTC)
:: Yes, now OK [[User:Jumpow|Jumpow]] ([[User talk:Jumpow|talk]]) 21:33, 4 January 2022 (UTC)
 
== Undefined behaviour ==
Line 51 ⟶ 44:
:This basically says, 'you may use a union to reinterpret the bits of one type into another but we're not going to promise that the new interpretation will be valid'
:I will say that the C code in this article is rather clunky and may benefit from a bitfield to separate the different sections of the float representation so it is easier to read and understand, but I will have to flatly disagree with you that <code>memcpy() </code>is more appropriate than a union in this code snippet. [[User:WillisHershey|WillisHershey]] ([[User talk:WillisHershey|talk]]) 17:24, 25 September 2023 (UTC)
 
== binary method in c ==
 
I believe that the example that is given in C is what is referred to as the [http://totton.idirect.com/soroban/KojimaSq/ Chinese Abacus Method] - confirmation from [http://medialab.freaknet.org/martin/src/sqrt/ this article] and [http://medialab.freaknet.org/martin/src/sqrt/sqrt.imp code that appears to be the same algorithm.] <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/70.124.38.160|70.124.38.160]] ([[User talk:70.124.38.160#top|talk]]) 15:55, 18 April 2022 (UTC)</small> <!--Autosigned by SineBot-->
 
== Lucas sequence method - original research? ==
Line 66 ⟶ 55:
Should this paragraph be removed as original research?
Or it could also simply be made much shorter, by avoiding to repeat the properties of Lucas sequences. [[User:BlueRavel|BlueRavel]] ([[User talk:BlueRavel|talk]]) 23:27, 3 December 2023 (UTC)
 
: {{ping|BlueRavel}} I have searched, and I too failed to find any relevant source for this. It was posted into the article in 2009 without any explanation, by an editor who has never made any other substantial contribution, just one other very small edit. It looks as though it may well be original research, but whether it is or not, it is unsourced, so I have removed it. [[User:JBW|JBW]] ([[User talk:JBW|talk]]) 21:54, 5 December 2023 (UTC)
 
== Merge "Approximations that depend on the floating point representation" into "Initial estimate" ==
Line 74 ⟶ 65:
 
Additionally, in my opinion the entirety of the article could benefit from some trimming/rewriting, as many sections contain redundant information, unnecessary details, and awkward formulations. [[User:BlueRavel|BlueRavel]] ([[User talk:BlueRavel|talk]]) 14:54, 4 December 2023 (UTC)
 
:: Your proposition makes sense to me, and I dont necessarily disagree. That said though, as a pure mathematician, I am uninclined to blur the lines between programmatical issues and mathematical problems. I think maintaining a distinction is appropriate. An analysis of the pure mathematical problem of initial estimation in these abstract reiterative processes is a decidedly distinct discussion from considerations in this programming language, or that programming language, or this architecture, or that architecture. The former is future-proofed, the latter is not. [[User:CogitoErgoCogitoSum|CogitoErgoCogitoSum]] ([[User talk:CogitoErgoCogitoSum|talk]]) 21:09, 11 February 2024 (UTC)
 
== Useful addition?? ==
Not sure if its useful, but I have found that, in general, <math>\sqrt{x+2} \approx \frac{x+1}{\sqrt{x}}</math>, and if {{math|''x''{{=}}''n''{{sup|''2''}}}} we get <math>\sqrt{n^2+2} \approx n + \frac{1}{n}</math>.
 
Similarly <math>\sqrt{x+4} \approx \frac{x+2}{\sqrt{x}}</math>.
 
I sometimes use this for quick pencil and paper calculations, if Im close enough to a convenient value.
 
Not sure if this is a known or established property, proven, bounded, or if its already in the article in some alternative capacity, or if its even appropriate for this article. I do know the taylor series approximation with two terms connects these expressions.
[[User:CogitoErgoCogitoSum|CogitoErgoCogitoSum]] ([[User talk:CogitoErgoCogitoSum|talk]]) 21:05, 11 February 2024 (UTC)
: There is nothing special about 2 and 4: <math>\sqrt{x+2c} \approx \frac{x+c}{\sqrt{x}}</math> provided that c is small compared to x. This is, in fact, just the first two terms of the series given in the article under the section heading "Taylor series". [[User:JBW|JBW]] ([[User talk:JBW|talk]]) 01:45, 13 February 2024 (UTC)
 
: I don't think they are useful. In the first, you have replaced a square root and an addition with a square root, an addition, and a division to get an approximate answer. [[User:Bubba73|Bubba73]] <sup>[[User talk:Bubba73|You talkin' to me?]]</sup> 08:02, 13 February 2024 (UTC)