Talk:Metallic ratios
Please don't add unnecessarily large outputs
If you want to demonstrate calculating the ratio to insane precision past 256 decimal places, fine, but please just put how many iterations it took, not the calculated value. It doesn't really add anything. If you really want to see extremely precisely calculated values for phi, here's it is to one million places. --Thundergnat (talk) 18:19, 1 November 2019 (UTC)
- Why is it that you call my 10,000 decimal digit example (REXX) an insane precision, but 1,000,000 was extremely precise? In any case, it has been deleted. But, my reason wasn't to see extremely precisely calculated values of phi. -- Gerard Schildberger (talk) 01:30, 2 November 2019 (UTC)
- I didn't intend to call specifically your example insane. (Though I admit, effectively I did and I apologize for that.) I just wanted to head off people adding larger and larger dumps of digits to the page. Posting the number of iterations it took to determine is cool, and is moderately interesting/useful information that is not easily found in other places. Something perhaps like:
Reached 1000 after 2395 iterations. Reached 10000 after 23927 iterations. Reached 100000 after 239250 iterations. ... whatever ...
- The actual value though? That's easily available in other places. I used the adjective insane because posting it here just forces everybody to scroll through huge walls of low information text. I debated even just asking for the iteration count for the stretch goal. --Thundergnat (talk) 12:37, 2 November 2019 (UTC)
- As for huge walls of text, I tried to solve that obstacle by using a smaller font, so on my screen, it was only 1/3 of a screen, ··· now, admittedly, I have a large screen. (I could've even made the output smaller yet height-wise, and probably should have in retrospect, or better yet, used a wider output.) If anyone wanted to scroll horizontally, the capability
iswas there, but nobody is forced to scroll horizontally, unless they wanted to verify that their value or REXX's value is/was correct, or perhaps to verify some portion of that number. (One option I had considered was just to show the "last" hundred decimal digits of the calculated value.) Another option would just to use a maximum height output window (specified within the <pre> HTML tag), which, in hindsight, probably should've been used by most examples --- if vertical scrolling is a problem. I also left the (display/showing) technique intact for showing 256 decimal digits (or more) on one line, so there is no vertical scrolling penalty for anyone). Additionally, I used a smaller font for the first output to reduce scrolling for everybody. -- Gerard Schildberger (talk) 20:50, 2 November 2019 (UTC)
- As for huge walls of text, I tried to solve that obstacle by using a smaller font, so on my screen, it was only 1/3 of a screen, ··· now, admittedly, I have a large screen. (I could've even made the output smaller yet height-wise, and probably should have in retrospect, or better yet, used a wider output.) If anyone wanted to scroll horizontally, the capability
Initial values for the "Lucas sequences"
The initial values (1, 1) do not give the actual Lucas sequences used in mathematics. The Lucas sequences U_n(P,Q) and V_n(P,Q) are defined with the following initial values: U_0(P,Q) = 0, U_1(P,Q) = 1, and V_0(P,Q) = 2, V_1(P,Q) = P.
For example, A006190(n) = U_n(3, -1), which, by definition, has the property that the ratio between successive terms converges to the bronze ratio.
On the other hand, there is no mentioning of "Lucas" or "bronze" in A003688. See also the Sidef entry, which uses the actual Lucas sequences. -- Trizen (talk) 13:02, 2 November 2019 (UTC)
- You aren't wrong, and perhaps I should specify more clearly that these are a variant of Lucas sequences in the task description (Lucas-like sequences?). Actual Lucas sequences are of the form
xₙ = P * xₙ₋₁ - Q * xₙ₋₂.
- and I glossed over the fact that the value I chose for c (Q) means we are subtracting -1 rather than adding +1 as it makes no difference to the answer. As for starting at 1 rather than 0... yeah, well, I mostly chose that to avoid the complication of having to trap divide by zero errors. The ratios work out due to the interval between terms; the starting value has very little effect. It may change how many terms it takes to converge (by at most 1), but the point I was trying to demonstrate with this task was the fact that the ratios could be calculated this way and the relative "speed" at which they converge not the actual number. --Thundergnat (talk) 13:06, 2 November 2019 (UTC)
Accelerated Convergece
I'm a bit rusty on some of my math skills, but when a sequence converges slowly by alternating above and below the final result, doesn't that make the sequence a candidate for some kind of tweak to make it converge more quickly? Might be interesting to make a stretch goal to illustrate how well the convergence can be shortened for each metallic ratio.
A Wikipedia article about Golden ratio indicates there is a quadraticly converging equation for this: <lang>
X(n)^2 + 2X(n)
X(n+1) = ----------------
X(n)^2 + 1
</lang>
Of course, formulas for where "B" is other than 1 would have to be worked out.
Another way might be to calculate a one-shot, larger-than-needed, Fibonacci number like this to a point past where the division will yield the required amount of decimal places. The trick would be to formulate a good estimate of which nth Fibonacci number it would need. ...And what modifications are needed to do the other metallic ratios.
But, I suppose that, the trickiest bit would be to show how the faster convergence is still related to the "Lucas-like" sequence prescribed by the task description. --Enter your username (talk) 18:41, 16 September 2020 (UTC)