Thank you for this direction.
>or will come as less of a shock in due course
A bit surprised, yes. Will get over it! :-)
Forgot image. You guys with the gcd call were spot on. Good job!
>we can ultimately express any c breaking it down to its most smallest pieces
I spent quite a bit of time over the weekend breaking down the (0,1) space for d[t] and a[t] changes. Didn't post the results as it seems a bit unnecessary, and I might be stating the obvious, but all the movements between records look like they be described by prime numbers.
At it's most basic, the numbers seem to work together in very obvious patterns.
>When this is all over I'm going to post my notebook
Thanks Teach. I'd be interested in reading.
I know we're currently working on trees, but if anyone has an interest in reviewing d[t] and a[t] output:
c145 pastebin.com/mJcE0CDy
c481 pastebin.com/yx1ym1C0
c533 pastebin.com/U4KDsUnv
c785 pastebin.com/Kthbi32S
both (1,c) and (a,b) records run against (e,1), (0,1), and (f,1).
Just a reminder regarding (0,n), the a value from the prime solution can be easily calculated from the cc and aabb records:
a = sqrt( cc.d - aabb.x )
We just never found a way to navigate to the aabb record without iterating.
VQC previously mentioned regarding the grid:
>How many times does 105 with three factors appear in one column?
>How many time for a number with four factors?
>It's not linear.
Perhaps the tree we are building is a way to query these numbers. And not necessarily to provide the prime solution.
???
I did spend some time looking at f movements. Specifically, enumerated all values in the original grid, created a corresponding record at (f,1,t), and then tried to analyze the differences.
c is the original (e,n,t) record from the grid.
cf is the (f,1,t) record
For odd values of e, found the following:
cf.e == c.f
cf.n == 1
cf.x == (c.x - 1)
cf.d == (c.d + (c.n - 1) * c.a + (c.a - c.e))
cf.a == ((c.n + 1) * c.a - c.e + 1)
Wasn't able to fully describe the movements for even values of e, only figured out the x:
cf.x == (c.x + 1)
Teach - this is great work. Makes it real easy to follow along.
A couple of the records don't look like valid grid entries. Specifically the even nodes where n's are fractions.
Also, instead of treating the d nodes as "c" values and trying to calculate their "prime" solutions, perhaps just treat them as "d" entries, and resolve to a valid record based on e=0, d=2d, a = d. Don't know if that will add any clarity, but certainly something to look into.
Thinking more about f.
In the original grid code, the f record was used to illustrate a mirror in the negative half of the grid.
The (n-1)*a transform, which takes us from (e,n,t) to (e,1,t), was explained as being a shortcut for an f movement. (I believe VQC stated this).
These are both big movements in the grid. We can do individual record movements (by adjusting x, t, or even computing the next d), but unless we know a factor, we can't move around any better than this.
While creating the tree, the only values we can compute definitively from e and d are c and f.
Perhaps the point of making the tree is not to figure out the x or x+n directly, but to create a structure that allows medium sized movements within the grid itself (phase 3).
What if the f value we can generate at each d node in the tree can be used to navigate backwards in bigger steps towards the correct solution?
Still - great insights, thanks.
Found a connection between the parse tree and the grid. Not sure if relevant or what to do with this, but wanted to share.
c=6107 tree attached with an "a" formula for d nodes.
From the d value in the tree, and using the e value at the same level, you can calculate a valid "a" in the tree using the formula:
a = 2d(d+1) + (e+1)/2
This formula works only for odd values of e.
Also attached is a spreadsheet analysis of "a" values in (23,1). At small values of a the formula doesn't work, but above that it's spot on.
Thanks for looking into this.
VQC hinted about triangles.
T(n) = (n*(n+1))/2
I bit strange that the formula for a puts 4 of them together, then adjusts for e.
>a = 2d(d+1) + (e+1)/2
At worst, this is a coincidence in the tree, and we've learned a bit more about the "a" value and how it works for odd values of e.
Alternatively, we need to figure out a formula for even values of e, and see if walking the tree produces anything of value.
The other hint was that the tree leads us to an x or x+n. I don't believe we know which x or x+n it is. Could very well be higher up.
for your n=4 example at {40:4:35:12:23:55}, it does seem pretty interesting that 2(3536) - 4 + 1 == 2523.
Perhaps there is a "triangle" way to navigate between columns.
Also would be interesting to see if there is any factor shared between these records. Could just be numbers thrown together.
Lol. It works. Except when it doesn't!
VA - thanks for posting these and keeping in touch with Chris.