I looked over my binary search code. It basically just guesses. In order for binary search to be a solution there needs to be a known relationship that we can compare an unknown's guess value to and know whether our guess is higher or lower than what it should be. That relationship doesn't appear to exist, or at least nobody found one. It was also mentioned earlier in this thread that it's log(n) because you take the square root until you can't anymore. That might be the same time complexity as binary search but it's a completely different algorithm. If the Root of David thing you're referring to is the element {0, 2d, 3d, 2d, d, 9d}, and that somehow relates to binary search, you're going to have to get significantly less vague if we're going to have any way of using this information.
Some analysis.
You start off by mentioning that this is used to adjust the squares. These squares are the i^2 and j^2 estimates from the (0,|d-e|) and (0,|d-|f||) cells, in the elements where d is between d[t]. e and f are columns unique to c, but they don't include column 0 for numbers other than squares. Also, each (0,n) element will have a different f. This means whatever elements you're referring to where we look at na-(n-1)a and a[t+n0] aren't directly found from any of the (0,n) concepts we've looked at. Further evidence of this comes from the variables we know when we find the elements in (0,|d-e|) and (0,|d-|f||). If we use the x values we find from e and f, there will only ever be valid elements in (0,1) (where (0,n) na transforms are found) for even x values, but it could be either parity. Plus the element we'd find from d, e and f would be invalid most of the time anyway, so its na tranform also wouldn't exist (i.e n*a wouldn't show up as a[t] in (0,1)). If we used the elements d is between, we would already know the a and n values, so we wouldn't need to find factors by subtracting (n-1)a from na. We could just use the a and n values we already had. So you wouldn't explain it like that if that was the case (I also tried it out in my code and didn't see anything, since it was just variables that were already within the elements, like I said).
So whatever elements these clues refer to are obviously specifically based around our c's (e,1) and (f,1), both since you explained it like that and because it wouldn't work otherwise. But if these n values "converge to n from c", then that would make the i^2 and j^2 estimates from (0,|d-e|) and (0,|d-|f||) irrelevant, so the link between these concepts is missing. There is also no mention of what n0 is specifically, although it can be inferred that the concept is related to finding an estimate n and doing something repeatedly to get a better estimate (one that converges to the unknown n we're looking for). If this n0 is the same n0 from the triangle estimate, it doesn't give us enough information to find specific elements, since we need either a or x to complete the xx+e=2na equation. That makes me think it's from >>9869 here, where n0 from the triangle base estimation is mentioned not as the same number but as a similar concept (it being the first guess n for further transforms). But no information in that post is given to explain how to get from an n0 element to an n1 element and then to n2 and so on. If these clues are based on >>9869 then it seems from my perspective like it could go in two directions: either going from n0 to n1 to n2 etc changes the e and f values making them lower/closer to 0 logarithmically and ends up on a pair of elements where the n values is the same as the unknown n we're looking for, or it stays within the same (e,1) (f,1) pair and somehow logarithmically iterates through t values. Either way I can't find a link to the (0,n) tree cells.
It was a logical conclusion to be drawn. The only way I can think to look for something like that right now would be to look at every possible pairing of e/f columns and check all of their na-(n-1)a values, but that seems extremely inefficient and impossible for bigger numbers.
There hasn't been any indication to look at a specific row, and there hasn't been any link made between factors of na and i value adjustments (or what "adjustment" actually means in this context). The earliest row we know will exist in both (e,1) and (f,1) and the cells between them is where (f,1)'s t values start, so I'll look in that row. If it's about i values and not na values, we could just look for the correct d value (the unknown d from the na element), since i=d+n, and n=1. So that sounds like it could be done with math just based around the whole (e+1)/2 thing for d and a values in (e,1). I'll have a look I guess.
I looked for the elements in (e,1) and (f,1) where i[t] is equal to either of the i values from the a[t]=na and a[t]=(n-1)a elements. I also compared this to the tree cells and their x values (only really the first two generated cells).
Given the a[t]=c sequence concepts, we know that there are only two elements within row 1 where the a values will be equal at the same t (and therefore also only two where the d values are equal at the same t, since d[t]=(e-1,1)'s a[t]). Also since we're in row n=1, i=d+1. So there will always be only one other element in row 1 aside from the na element at the same t where the i value is the same. If we find this element for na and the same thing for (n-1)a, the e and f values add to the same value as the n values in the tree cells, as well as the difference between the x values in the tree cells. So I found a link. In the first example, 53+52 and 71+34 both add to 105, which is also 118-13. In the second example, 7+8 and 39+-54 both add to 15/-15 (obviously one will be negative but this pattern still holds), which is also 93-78. When na and (n-1)a are one t value apart, e+f and n+n will have a difference of 4. These two patterns hold for all of the examples I've looked at.
This doesn't seem to be a pattern that allows us to directly calculate anything, but at the very least it is a link between i[t] and the tree cells.
Just noticed also that (na's e)-(na i[t]=i's e) is equal to ((n-1)a's e)-((n-1)a i[t]=i's e). In that first example, 118-71=47 and 34–13=47. They're the same distance from their starting places. Same with the second example. 78-39=39 and -93–54=-39. So if we start from (e,1) and (f,1) and move the same distance towards (0,1) from each one until we reach two cells where the absolute value of e-f is equal to (|d-e|)+(|d-|f||), the two cells we land on will contain within them the only other two elements in row one where elements exist at the same t as our na and (n-1)a values with the same i values. We'd still have to find that t, but maybe there's something about sequence patterns like d[t]-d that would allow us to do that.
Okay forget about pretty much everything I just said. Every pair of cells the same distance from (e,1) and (f,1) inwards will add to the same value as the tree cell n values added together.
(1,1) and (6,1), 1+6=7
(2,1) and (5,1), 2+5=7
(3,1) and (4,1), 3+4=7
There's still only one element in row one aside from na/(n-1)a where i[t]=i at the same t, but the rest of what I said would appear to be redundant.
?
One or two of you mentioned that you were writing code that was meant to help us in some way several days ago. Is that still happening?
I've been looking into this more but it doesn't seem to lead to a solution. Every two cells there's a value with the same i (at different ts), so there's no way to predict which specific one has the i value at the correct t. So I've explored everything I can think to explore in relation to these hints
and not found anything. Has anyone else been looking at anything related to these posts?