[seqfan] Re: new dragon conjecture

[brad klee]

Hi Fred,

> Can anybody interpret the term "spigot difference" ?

Here's a reference that seems pretty good:

https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/spigot.pdf
Jeremy Gibbons, "Unbounded Spigot Algorithms for the Digits of Pi".

> Rabinowitz and Wagon call their algorithm a spigot algorithm, 
> because it yields digits incrementally and does not reuse digits
> after they have been computed. The digits drip out one by one, 
> as if from a leaky tap. In contrast, most algorithms for computing 
> the digits of π execute inscrutably, delivering no output until 
> the whole computation is completed.

Although these algorithms do not "reuse digits", they tend to 
accumulate lots of hidden data. The hidden data is what I've 
loosely called the "spigot differences", since that data 
effectively works like a transition vector between states. 
 
Take for example the pi g function at the top of Gibbons page 2. 
It is not too much to type and check. In doing so, I get the 
following sequence of hidden states:

branch->{n,q,r,t,k,l}

 Q -> {3, 1, 0, 1, 1, 3}, 
 P -> {3, 1, 6, 3, 2, 5}, 
 Q -> {0, 10, -30, 3, 2, 5}, 
 Q -> {0, 20, -50, 15, 3, 7}, 
 P -> {1, 60, -70, 105, 4, 9}, 
 Q -> {0, 600, -1750, 105, 4, 9}, 
 Q -> {2, 2400, -4950, 945, 5, 11}, 
 Q -> {3, 12000, -1650, 10395, 6, 13}, 
 Q -> {3, 72000, 290550, 135135, 7, 15}, 
 Q -> {3, 504000, 6518250, 2027025, 8, 17}, 
 P -> {4, 4032000, 127946250, 34459425, 9, 19}

The branches--P = Print = True, and Q = Quiet = False--determine 
how the algorithm reaches its next state, and whether it will 
output a digit. The computation above only gets to 3.14.   

In this case, the notion of "spigot differences" turns out more 
ambiguous due to the Q&P pattern. But since Q and P are always 
determined by 4*q + r - t < n*t, we can say loosely that 
the "spigot differences" are a combination of {q,r,t,k,l}. 

Again, Why? 

Because if we know "n" and we know {q,r,t,k,l} then we can 
re-form the state vector {n,q,r,t,k,l} and iterate g again 
to find the next state {n',q',r',t',k',l'}.

All of the columns from the iteration above could be entered 
to OEIS, but the parity pattern is most simple, and the last 
two columns are not too bad with apparently linear growth: 

PQ: 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 1, 
0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1 ...

k: 1, 2, 2, 3, 4, 4, 5, 6, 7, 8, 9, 9, 10, 10, 11, 12, 13, 
14, 14, 15, 16, 17, 18, 18, 19, 20, 20, 21, 22, 23, 23, 24 ...

l: 3, 5, 5, 7, 9, 9, 11, 13, 15, 17, 19, 19, 21, 21, 23, 25,
27, 29, 29, 31, 33, 35, 37, 37, 39, 41, 41, 43, 45, 47, 47 ...

Wouldn't these at least make a nice addition to celebrate 
happy dragon year pi day (龍年率日快樂)?

The now-updated community post builds a spigot around one 
p-recurrence from Beuker's Pi day lecture. Values of the 
p-recurrence are hidden approximation data which we could 
also construe (or misconstrue) as "spigot differences". 
For example, this sequence is a necessary part of that data:

https://oeis.org/A006139

Another pragmatic record keeping question follows from the 
final graph here:

https://community.wolfram.com/groups/-/m/t/3140560

Why does the algorithm starting from Beuker's approximation 
have a smaller memory footprint?

Is it because Jeremy's g spigot has taken a step of encoding 
to integers only? Or because more data is needed to rigorously 
prove convergence?

Eventually it would be nice to have a flexible definition 
of a spigot algorithm for integer sequences in general, 
but it seems like details are getting in the way for now.  

Thanks for you time,


--Brad