And how is that useful?
So we don't actually have to calculate q ourselves? If we use the c values in those cells I guess it would be the same sort of thing (although they won't all be primes).
The pattern for e in the increasing b values is >>9145 here. I'll put some code together to display what you're talking about.
And if n isn't equal to 1, both e and n become unknowns, so we can't find the cells, or there could be multiple. You're going to have to clarify.
To those of you who aren't Chris but know how to use the grid (I don't know how many of you there are and it's hard to keep track), in particular the one who's been here a lot in the last few days. I've put together almost all of the concepts and patterns we know in as compact, concise and ordered of a way as I could (four posts in the Grid Patterns thread, which I'll link at the bottom of this post).
You seem to think we're ready and that now is the time for us to figure it out. You know better than we do how that's meant to happen. You're coming from the perspective of knowing how to use the grid, so having seen how far we've come, you probably think we're awfully close. From our perspective, we have an overwhelmingly long set of patterns and concepts and no idea how to use them, and there are a bunch of concepts we know exist but haven't been told about. You want us to figure it out without you just telling us how to do it, and we want to figure it out in the same way. We have to work with each other here. No matter how close you think we are, all we've done over the last couple days is more of the same thing we've been doing for 19 and a half months, which is analyzing patterns without knowing how to use them. If you think that's how to do this, maybe you're right, but that's how Chris has run this operation, and seeing how one of you left him a grumpy message in GP telling him nobody listens to him anymore, maybe you'll also understand that the reason for that sentiment is exactly the method by which he has been trying to teach us (which, so far, has been the same way you've been doing things with us here, albeit a bit more openly).
Maybe I don't know exactly how this could work best, but we all want the same thing, and you seem more open to conversation than Chris ever was. We talked today about how we know all of these patterns but we don't know how to use them. If continuing in the same way of analyzing specific patterns until you personally feel we understand them enough to move onto the next one is going to work, you should know, PMA, blank-name poster and I are here daily (as well as Topol, although he isn't a math person so much), and I personally have a lot of free time on my hands, so I will gladly work through whatever you feel necessary to get this done. All you have to do is tell us what to do. But I am skeptical of that being the way things will work (given, like I said, it's how things have gone for 19 and a half months). So, my suggestion to you guys (you could even just be the one person, or even Chris pretending to be other people… I don't know) is to have a read through the four posts I'll link below, which sum up most of our knowledge to date. Instead of going over individual patterns without having any idea why we're learning about them, given you'll have an overview of pretty much everything we've got, you could potentially guide us by showing us which concepts to use in conjunction with one another and what they actually accomplish. Let's be efficient here rather than stumbling around blindly.
>x is an index, BUT when something else is used as the index, it becomes more relevant.
>Try the elements at x=d and x=d+1 (2d + 1).
So far all I'm seeing is that a[t] from (f,1) is always equal to BigN-1. Pic related.
>ALSO, if the elements d is between are calculated with x ~= sqrt(f), what is at “x = f or x = f-1?”
c between d[t]
>ALSO, if the elements d is between are calculated with x ~= sqrt(f), what is at “x = f or x = f-1?”
May have jumped the gun a bit with that one, it was an assumption based on squares. It seems like you're talking about one specific element rather than two elements with something in their gap, since two x values in (e,1) or (f,1) are 2 apart rather than f and f-1 in the same cell. You're also linking it to the elements d is between obviously, so there should be some kind of linked concept or something that equals something else. All I'm seeing is that the |e| and |f| values in the two elements are 1 apart (which is also true of their x values, given those are f and f-1). I'm not seeing any link to the d between d[t] elements.
Which ones? I just double checked a few and I'm not seeing anything wrong.
We do, yeah. We're figuring out the issue at the moment. It's probably something about the Java port.
Fixed
I wouldn't have a clue. Given you're talking about this after talking about gaps, it probably has something to do with making calculations in a gap in some way we haven't done before. Maybe there's a formula to find an f value that we want in row 1. All the non-trivial things I can think of would immediately solve so I would think whatever we do to find an element pair where it adds up to something nontrivial would possibly be complicated and possibly involve recursion.
>How are you doing that when you input grid coordinates without realizing it?
That's pretty vague but you could maybe be talking about an (e,n) co-ordinate containing an infinite set of elements, or maybe you're talking about (e,1), or maybe the fact that you're choosing an n value implies something about a calculation that I can't think of. If that's an answer to your question.
I have a couple code issues to sort before I post a screenshot, but for all the examples I've tried so far, our original d is lower than the d[t] value in t=1 of (e',1) and (f',1), so it would be between negative elements.
Okay here's a better example. c4343 (43*101), (118,7,12) = {118:7:65:22:43:101}, f=-13, c=4343, u=14, i=72, j=29
For this example if you add the leaves of the tree together you get 13, so if that's a0 then d-a0=65-13=52, where the actual x value is 22.
It certainly does occasionally find exact matches in a similar way; for example, c559 where a=13, the leaves add up to 13. Whatever it is we do with the tree comes in what Chris called "part 3", part 2 being the generation of the tree itself, and he never went any further into how the tree relates to the grid (since part 3 is where the grid comes in). You were wanting to go in that direction, right?
So if we're using e as x and f as x at the same time, we'd need to be using two elements. If d is used as x+n then there'll be two separate n values for those elements. And then we do that recursively through the square roots of each one? I'll put some code together to do that in a bit. Does this relate to the tree?
And is it -f or |f|?
Great, thank you for clarifying. Just about finished my code so I'll post an example in a minute. Thank you also very much for how generous you've been with your time. In less than a week you've given us more than we've had in probably the last year.
Hang on, x is always even in (0,n) but e and f aren't always even.
It seems like the (0,n) cells in the first run of the recursive function aren't even valid, but from then on they're squares. The non-(0,n) elements are quite close together in their values, though. I calculated them based on (0,n,t) and then converting those t values back into x values to do xx+e=2na.
I've put together some code that finds (0,|d-e|) and (0,|d-|f||) recursively using their square roots. Since valid elements don't always exist at the given x values, I made it find the element with the closest x value in that (0,n) (sometimes it has to use elements where x=0, but I also made a version where it only uses valid elements). Is this correct (first picture, with relevant tree for comparison)?
Here are two more examples then. One thing I've noticed is that for each example, at least one of the original x values at each level is between the j values that end up being used. But I haven't noticed anything else yet.
>Unity of method necessary also to work together with one another.
Is there anything you'd recommend changing about the method the way I posted it then? Otherwise, we've been talking about it on Discord and it seems like we're ready to learn how to use it if you'd like to continue.
Okay, we'll adapt it for the two surrounding elements. A few of us are online right now so we're ready to do whatever.
Necessary vagueness I guess. If you meant multiplying numbers together that would remain in (0,n), you would have probably said "square" (since you mentioned something about "squaring the gap" a couple days ago, whatever that means). If it doesn't have to be perfectly implemented, it must have more to do with the d/e/f values than the elements they're used to find. I remember there being something in the grid about a number multiplied by (itself plus 1). It may have been a values in a particular cell. And in every example I've seen so far, the n values in the two first-generated elements for this recursive method thing have always been one apart. You're probably going to continue to be vague given the way you typed what I'm replying to but I might look into multiplying those n values together.
Here's the same c as before with the (-1,1) elements I gathered you were potentially talking about. The triangle base u is the same as the higher of the two n values in the cases I tested (including this one obviously).
I'm not sure if it's obvious algebraically or not but I just figured out that c-((|d-e|)(|d-|f||)) is a square.
I'm not going to lie, I would personally love it if this was finally over within a few days. I don't know how close we are though. If it is done by then, there'll be plenty for you to come back to, so don't worry too much. I'll certainly still be here getting as much done as Not Chris' time allows.
What I do see is that the i values from the d between d[t] elements become the j values in the squared elements (and when we have to find the surrounding elements due to parity i is halfway between the j values). So I gather there's something useful about the values found halfway between these newer i values too potentially. But I have a feeling we were meant to "see" something else.
Well if we're "squaring" the d between d[t] elements then I'd have to assume those are the "square roots".
>until there’s nothing but the factors or a prime determination
How have the tree, the tree elements or the squaring of the d between d[t] gap limited the search space? There have been various variables that have been equal to other variables, or variables that have appeared between two of the same variable, but none of it has been knowns leading us to unknowns as far as I can tell. In fact, unless I'm missing something here, we've done basically the same thing again in that you've given us another list of transformations and new elements to look at in the grid that we still don't know how to use. I understand the vagueness, and I'm sure we're more close to a solution than we realize. I can imagine that when you say we're unblurring the large square and to try other parts you're referring to this all being based around i and that it would be useful to do the same thing with j and the elements where c is between i[t]. That's all well and good but where are we going with this? Is there something we're meant to see that we haven't seen yet? Is there something we're meant to do with all of these things that you haven't told us yet? Because if the c between i[t] equivalent is anything like the d between d[t] stuff you've been guiding us through, it seems like it's going to add to that list of things we don't know how to use.