>>5592

Pics attached are small odd x+n tests that cover the possible f mod 8 remainders of 0, 1, 2, 4, 5, 6. My tests indicate that remainders of 3 and 7 aren't possible for odd x+n, but someone should please verify.

These tests are grouped by x+n and all sorted by x+n ascending, n-1 ascending, and d descending.

The reason for the sorting is that the largest n-1 value always coincides with the smallest d value. And the smallest n-1 value coincides with the largest d value.

And so determining that range could be extremely beneficial performance wise, but I'd settle for just finding the top n-1 value!

>>5604

Tests for f mod 8 remainders of 4, 5, 6 attached.

>>5604

>>5605

Pics attached are f mod 8 summary tables for odd x+n up to 99, showing min, max, spread, spread div 8, spread mod 8 for n-1 and d values. Last column shows all possible n-1 values for each x+n.

Only including where f mod 8 is 0 and 1, as it appears that f mod 8 behavior can be grouped as follows:

Odd n-1

f mod 8 = 0

f mod 8 = 2

f mod 8 = 4

f mod 8 = 6

Even n-1

f mod 8 = 1

f mod 8 = 5

The n-1 values between mod values in these groups aren't exactly the same, but they may be similar enough.

Not sure if relevant, but wanted to share some observations regarding the f mod 8 patterns.

Back to the c=6107 test, where f=134, and f mod 8 = 6.

Attached pics include:

1) c=6107 iterative search results based on f-2 div 40; (c6107_fm2_iterative_search)

2) valid n-1 and d values for x+n=17 where f mod 8 = 6; (c6107_x_plus_n_17)

3) x+n records where f=134 and f mod 8 = 6 up to the x+n=83 prime solution record. (c6107_f134)

The x+n=17 sample was chosen because the iterative search hits that record very early in the process.

It appears that there are a couple of ways to proceed.

One way is to figure out what the maximum n-1 value is for x+n=17, and use that to jump ahead. In this case, max n-1=5, n=6, and that would place us at least at x+n=30 as the next iteration.

The other, might be using the common f=134 value and various related records in the grid. Not quite sure what the path would be through these various records, but did notice that several chains exist between a and b values.

For example, working backwards from x+n=83:

x+n=83 a=403, b=569

x+n=69 a=265, b=403

x+n=55 a=155, b=265

x+n=41 a=73, b=155

Perhaps, notwithstanding the various e values, this shared f value across multiple records could point the way to the solution.

>>5562

>>5608

>For each odd square what are the permutations of possible values of f,d and (n-1)?

I believe the following describes the valid possible values f, d, and n-1 for odd x+n. Would appreciate someone double checking this.

Attached pics show sample output for x+n=9.

Groups are defined as follows:

————-

Odd n-1

————-

f mod 8 = 0 n: even; d: odd; f: even;

f mod 8 = 2 n: even; d: even; f: even;

f mod 8 = 4 n: even; d: odd; f: even;

f mod 8 = 6 n: even; d: even; f: even;

n = n +/- 2

d = d +/- 4

f = f +/- (n-1) * 8

————-

Even n-1

————-

f mod 8 = 1 n: odd; d: alternates even/odd if (n-1) mod 4 == 0, otherwise even; f: odd;

f mod 8 = 5 n: odd; d: odd; f: odd;

n = n +/- 2 (for f mod 8 = 1)

n = n +/- 4 (for f mod 8 = 5)

d = d +/- 2

f = f +/- (n-1)/2 * 8

d and f work in opposite directions, if d increases then f decreases and vice versa.

Not sure yet what the adjustments are when moving between different n values. But the above should accurately describe how to adjust d and f values within a particular n and maintain the same (x+n)(x+n).

>>5631

Things got a little more intricate in determining the n, d, and f values while doing further testing for odd x+n.

Pic attached is the relevant source code.

Based on f mod 8, n and d each have various start and step (increment) values. And in some cases, it appears that the d values can only be determined once n is known.

Likewise, I have so far only managed to define the incremental f changes in terms of n. (See the GetFStep method). The initial f value is determined once n and d are calculated via f = (x+n)(x+n) - (nn-1 + 2d(n-1)).

That being said, given any odd x+n, these formulas can be used to iterate through all valid n, d, and f combinations.

Trip change needed.

>>5648

changed.

>>5646

Two different examples for each test case. First one shows a constant f. The second a constant d.

>>5651

Nothing fancy at this point. Just using the formulas posted earlier to iterate by n, and only showing "relevant" entries. Find it a good way to review the data.

Have an idea about what we are searching for, but not quite sure how the math works out. Perhaps another anon can assist.

Pics attached are sample odd x+n f,d,n output for x+n=17 at f mod 8 = 0. One image shows all possible values for n=2 and n=4, the other shows the minimum d values for all possible n.

Full pastebin of these pictures for all f mod 8 combinations are available at pastebin.com/gaxUD1ex (all possible values) and pastebin.com/5FpEffS9 (min d values only).

The iterative search gives us n0 and XPN values at each step. And the common f value tells us which f mod 8 rules apply.

Per the formulas at >>5632, we can directly calculate the minimum d for each possible n.

And because there is an inverse relationship between the 2d(n-1) and f values (see the (2dnm1 + f) column) we should have everything we need to determine the first row in each n grouping of possible values.

That first row, I believe, is important because the list of available "d" values decreases as n increases. Notice how the max d for n=2 is 143, but the max d for n=4 is 43. This min d value, however, is available for every n.

The second picture shows only the possible n values using the min d=3 value.

And so when we search for a record with (x+n)=17 and f mod 8 = 0, we already know that the max n that can be used is 14. (This is the formula that needs to be determined. It could be related to the d step and/or f step values.)

Applying this logic at each step of the iterative search should provide a bit of a performance improvement.

>>5664

Still searching for something to enable n jumps greater than 2.

Pic attached shows a filtered search in odd x+n=83, where f mod 8 = 6 and f values are between 126 and 142. f=134 is the target value for c=6107 and the prime solution record is the last entry in the table.

Note from the table that valid n values for f=134 are 2, 6, 8 and 36. Whereas f=142 appears at n = 2, 4, and 14.

Perhaps the valid values of n are determined by f ?

>>5671

AA - I think we're on the same page here. VQC is teaching us the steps to take with the f mod 8 work.

Those relationships seem to be defined pretty well here >>5632. Only recent change I made was to adjust the n_start for f_mod_8 != 0 to 1 instead of 3. This enable me to integrate these n step values into the iterative search process. (only n value not contemplated is 0, but that's a special case anyway).

It would be helpful if someone else could verify these formulas.

So based on these values, iterative search is still n/2 performance, except where f mod 8 = 5. Then it's n/4. Obviously too slow.

The fixing of the odd x+n does allow deeper analysis into the movements of n.

From my latest post >>5670, there is more to it than meets the eye.

Regarding the symmetry, I've only posted pictures for f mod 8=0. There are different layouts for each of the other mod values that are also pretty interesting. All place f in the middle, the nn-1 portion around the edges, and 2d(n-1) filling the space in between. The patterns with f certainly do grow in predictable ways. (again the formulas posted define this quite well).

Little bit of progress to report.

Managed to integrate the n patterns for f mod 8 into the f-2 div 40 iterative search with reasonable performance improvements.

Pics attached show detailed output for c=6107, a portion of all test cases (with full output available at pastebin.com/3DvFwQmu), and an updated code snippet showing start and step values for n that now also includes patterns for d mod 8.

On the performance side, these revised tests have about 50% fewer iterations than the previous f-2 div 40. A few examples of the iteration improvements:

c=6107 from 23 to 10

c=208364311 from 3706 to 1853

c=9874400051 from 11 to 6

These improvements are a result of a few things:

1) Certain f mod 8 and d mod 8 values enable consistent n+4 jumps between records.

2) The fm2 factor and rm factors are now calculated directly from n0 and the (nn-1 + 2d(n-1) + f) formula.

3) This enables the initial n0 calculation to match the valid known n start.

4) Once in sync with starting n, triangles are created using the methods described previously. (1 + 8 * T(fm2_factor * fm2_chunk) + fm2_mod + 8 * (rm_factor * fm2_chunk) + fm2_mod)

5) The next valid n is then determined from the current n0 and f and d mods using the GetNIterateSettings method.

6) A side benefit is that f-2 div 40 chunks are no longer necessary and have been replaced with f-2 div 8 chunks.

For f mod 8 values of 0, 4, 5 and in some cases 1, the performance is still stuck at n/2. Unless we can figure out a few more patterns in how f and d mods affect valid n values.

>>5677

Tried to incorporate everything we know so far about relationships between d, f and n.

Very possible I missed something.

Your f formula is incorrect though. Should be f = 2d + 1 - e.

The f that VQC included in the original grid code represented an "F movement" to the negative e side of the grid.