# Talk:Metallic ratios

## Please don't add unnecessarily large outputs[edit]

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:

- I didn't intend to call specifically

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)

- The actual value though? That's easily available in other places. I used the adjective insane because posting it here just forces

- As for huge walls of text, I tried to solve that obstacle by using a smaller font, so on
*my*screen, it was onlyof 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^{1}/_{3}*wider*output.) If anyone wanted to scroll horizontally, the capability~~is~~was 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

## Initial values for the "Lucas sequences"[edit]

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)