Content deleted Content added
Update archiving templates after a page move (Report bot issues) |
|||
| (10 intermediate revisions by 7 users not shown) | |||
Line 1:
{{User:MiszaBot/config
| algo = old(360d)
| archive = Talk:
| counter = 1
| maxarchivesize = 150K
Line 8:
| minthreadsleft = 5
}}
{{WikiProject banner shell|class=C|
{{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.
== 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)
== Lucas sequence method - original research? ==
Line 76 ⟶ 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)
| |||