>>5870

As a follow up to my previous post >>5851, attached is revised odd x+n=83 output for both f mod 8 = 5 and 6.

Additional columns have been added for (n-1) + (f-1), it's div 8 and mod 8 values.

The f mod 8 = 6 results include c6107 and c27707.

From the mod 8 column, we can see (unfortunately) that there are times when this relationship still doesn't equally distribute among the 8 triangles. Notice records with mod 2, 4, and 6 values. I just happened to pick another example that worked out perfectly.

There may, however, be a deeper relationship to explore.

In the f mod 8 = 5 output, the only valid mod values appear to be 2 and 6.

If there is a way to consistently relate these mod values to f, we would be able to predict the remainder portions around the center (n-1) + (f-1) area.

>>5907

>>5932

Using the (f-1)/8 as a base for u1 and u2 enables calculating a larger n0 starting value for cases where (f-1)/8 n.

I'm estimating about 10% performance improvement here for the iterative search process, but still need to rely on n+4 jumps for subsequent records.

Couple of issues that I'm researching:

1) Is there a way to determine from the outset if the large (f-1)/8 jump for n is even possible. (i.e. rule out cases where (f-1)/8 < n). Initial thought was to try and rule out -e values from n,d,f records. Not sure of this yet.

2) Is there something else in the n,d,f tables that can lead to larger n jumps? Some patterns and/or combinations of (n-1) + (f-1) that can be relied on.

>>5942

Couple of examples attached for e+2n within the same (x+n) = 83.

difference is f appears to be 2n-2.

A couple more animated examples. This time for (x+n) = 13, and similar to the static images posted in the last thread (>>5755 and >>5756).

For the (f-1) version, the orange center square comes from (f-1), except for f mod 8 in (1,5) where the green center square comes from nn.

For the (n-1)+(f-1) version, the red center square comes from (2d-1)(n-1), and for f mod 8 in (1,5) the green center square comes from nn.

In addition, the "groups" of triangles have been highlighted in the middle.

>>6079

Thank you.

>>6223

>>6224

Nicely done!

Found a way to represent any even x+n in terms of a triangle base u.

Pic attached shows sample layouts for even squares 6, 8, 10, and 12, but similar rendering can apply to any even square.

The formula to represent this structure is:

(x+n)(x+n) = 4*(1 + 2u + T(u) + T(u-1))

where u = ((x+n) / 2) - 1

Perhaps there is also a way to visualize the nn+2d(n-1)+f-1 breakdown for even squares.

>>6272

Apologies. I made this way too complicated.

New simpler pic attached for even x+n.

An even square is comprised of 4 other squares. And every square is T(u) + T(u-1).

Revised formula:

(x+n)(x+n) 4T(u) + 4T(u-1) 4(T(u)+T(u-1))

where u = (x+n)/2

Yellow squares in the middle are just anchor points for reference and belong to the larger triangles.

Now that we can draw even x+n squares, attached pics are for our old friend c145.

These are the (1,61,6) entry record, it's (-24,60,7) mirror in negative e.

The solution (1,5,4) record, and it's (-24, 4, 5) mirror.

>>6292

Just browsing around into negative x again to verify the t offsets.

First pic is just showing for c145 the x to negative x matches for the entry (1,61,6) record and the corresponding na record at (1,1,6).

Then stumbled across something that seems extremely relevant.

Additional pics are for c145 and c6107 and show output from a browser app that helps navigate the grid.

For example, the steps for c145 are as follows:

1) create c record at (1,61,6)

2) na = move to na record at (1,1,6)

3) nx = move to negative x at (1,1,-5)

4) f = show factors of c at (1,1,-5) where c = 2501.

The interesting part here, is that the negative x record (with reversed a/b values) points directly to the TOP of the factor tree for it's corresponding c value. See the a/b values circled in red.

That means, I believe, that using the negative x record and an entry c record, we can isolate the full range of factor records for any c.

The remaining question is how to arrive at the correct negative x record.

>>6328

>>6340

Relevant records for the 1,c starting position of Rsa100. Big numbers really force you to look at the last digit.

Nice format 3D!

>>6344

And the Rsa2048 values, just for fun.

>>6374

>>6376

Hello, VQC.

Searching through >>6368 and you add clarity to everything else. Thanks.

I have been referring to grid coordinates as (e,n,t) because it enables quick reference to exact entries.

Your notation of (e,n) and a[t] for specific values is obviously more concise.

Is there a preference going forward?

>>6376

>bn at t+n should read:

>e:1:(nb+2x+n):(x+2n):(nb+x+2n):(nb+3x+6n+2)

e:1:(nb+x+2n):(x+2n):nb:(nb+2x+4n+2)

>>6374

>Grid (p,q) where p and q are signed integers

Just clarifying an earlier post >>6358 and confirming VQC's grid statement.

Attached pic shows grid entries in the 4 quadrants for c values where mod 145 = 0.

And they appear to be arranged as follows:

(e, n)

(e, -n)

(-f, n-1)

(-f, -(n-1))

Within each cell x can be positive or negative.

>>6403

Continuing the analysis on the (e,n) and (-f, n-1) related records.

Revised spreadsheets attached for c145 and c287 and include the following observations:

1) The differences between f values in adjacent rows changes in steps of 2. Similar to how x changes vertically.

2) Highlighted rows indicate where c mod a = 0.

• Every 5 records for c145, every 7 for c287. And in groups of 2.

• This looks similar to how we can iterate by known factors in (e,1). t = t + m * factor and t = m * factor + 1 - t, where m is a multiplier.

• Except instead of jumping vertically by x, we are moving horizontally by f.

3) Added columns to analyze c mod the starting c value.

• For the first few records on either side of our starting c, it looks like the c mod differences can be expressed in terms of 2T(u).

• Where u is (a-1) in the (e,n) space and abs(a) in (-f,n-1).

• Alternatively, without the T(u), the differences can be expressed as the product of 2 adjacent numbers.

For example, for record (489,61,6) where c=745. 745 mod 145 = 20.

20 = 2T(4) = 45.

We can further define that new c value in terms of our destination a.

new c = a*c + a(a-1)

So, it looks like we can make pretty large horizontal jumps as well, assuming we know which a we are looking for.

>>6395

>Any product of 2 primes will be divisible by 3 if you add either 2 or 4, or if you subtract 2 or 4.

>Any product of 2 primes will be divisible by 5 if you…

>>6424

Product of 2 primes divisibility rules may be:

div 3 is +/- ( 2 or 4 )

div 5 is +/- ( 1 or 3 )

div 7 is +/- ( 3 or 4, 1 or 6, 2 or 5 )

And do not contemplate where the product is immediately divisible by 3, 5, 7, etc.

The div 7 rule (if correct), is interesting, as it appears the pattern for checking is:

3-4…

2-5…

1-6…

Where the sum of each combination equals the div value.

For div 11, as an example, this means that the +/- ranges to check would be 1 apart, 3 apart, 5 apart, 7 apart, 9 apart.

+/- (5 or 6)

+/- (4 or 7)

+/- (3 or 8)

+/- (2 or 9)

+/- (1 or 10)

Which seems to work properly on smaller test cases for 119, 221, 323, 437, 551, 1159, 2499, 5781.

>>6420

>>6427

Attached spreadsheets for c145, c287, and c6107 (partial) show side by side comparison of grid entries in (e,n) and (-f,n-1).

For each of these spreadsheets, notice that the d value descends in (e,n), ascends in (-f,n-1), and the total of both d values is always 2d+1.

The difference between the d values is also highlighted, showing odd values at increments of 2.

The last 2 sections of the spreadsheets are an attempt to incorporate the product of 2 primes +/- some number to see if there are any matches, as the pattern looks very similar to the div 11 example posted previously. >>6427

Using the d value from the (e,n) and (-f, n-1) columns respectively, the results show the four possible combinations of (c +/- d), and then each of those divided by (2d+1).

The green highlighted row in the middle indicates where there is no remainder to that formula.

Interesting how this match only happens once for each example, and before the d value at (e,n) reaches 0.

>>6374

>>6380

>>6470

>Since d contains a+x, this is the key.

Have spent some time reviewing VQC's na and nb formulas in terms of x and n, and the most recent post about finding the key in (e,1) related to (-f,1).

Just a reminder on the formulas:

na: e:1:(na+x):x:na:(na+2x+2)

nb: e:1:(nb+x+2n):(x+2n):nb:(nb+2x+4n+2)

So went in search of ways to understand movements in terms of x+2n, and may have stumbled on a better understanding for movements within specific cells.

For example, starting from the nb record for c145: (1,1,67) = {1:1:8978:133:8845:9113}

We can move to the next record at (1,1,68) = {1:1:9248:135:9113:9385} by manipulating d.

new d = d + 2(x+2n)

new d = 8978 + 2(133+2*1) = 9248

But what about moving back to (1,1,67)? The formula for d in reverse turns out to be pretty simple.

previous d = a - x

previous d = 9113 - 135 = 8978

For the current record, we know that d=a+x. And now we can calculate the previous record's d value in terms of the current a and x.

And it turns out that this movement works everywhere, regardless of (e,n).

From the original c145 record (1,61,6) = {1:61:12:11:1:145}, the next relevant record in terms of x and n should be:

next d = d + 2(x+2n)

next d = 12 + 2(11 + 2*61)

next d = 278

(1,61,67) = {1:61:278:133:145:533}

And then moving backwards:

previous d = 145 - 133 = 12.

Here are a few additional records in the same chain, that show the movements in reverse:

(1,61,67) = {1:61:278:133:145:533} = 77285

(1,61,128) = {1:61:788:255:533:1165} = 620945

(1,61,189) = {1:61:1542:377:1165:2041} = 2377765

(1,61,250) = {1:61:2540:499:2041:3161} = 6451601

2041 - 499 = 1542

1165 - 377 = 788

533 - 255 = 278

The shortcuts in the grid to navigating this way starting at (e,n) at t are:

Next d record = (e,n) at [t + n]

Previous d record = (e,n) at [t - n]

Just summarizing, in case it helps anyone:

t rules:

even e: t = (x+2)/2

odd e: t = (x+1)/2

u rules:

odd x+n: u = (x+n-1)/2

even x+n: u = (x+n)/2

(x+n)(x+n) in terms of u:

odd x+n: (x+n)(x+n) = 1+8T(u)

even x+n: (x+n)(x+n) = 4T(u)+4T(u-1)

(x+n)(x+n) in terms of t at n=1

even e: (x+n)(x+n) = 2t*2t

odd e: (x+n)(x+n) = (2t-1)(2t-1)

>>6445

>What happens when you compare the -f and e columns in the grid for 4c? The square for x+n has now sides of 2(x+n) compared to c.

Have been working through this crumb, looking for patterns for x+n as c increases in various multiples, and ran into a slight descrepancy with the 2(x+n) statement from VQC that warranted a closer look.

Attached pic, shows 10 records generated from c145 multiplied by 2^1, 2^2, 2^3, 2^4, etc up to 2^10. The pattern holds as you move higher as well.

The initial result of 145 * 2^1, results in c=290. Because this is an even number where c mod 4 != 0, no valid grid entry exists. To find a valid entry, you have to divide c by 2, making it odd, and then create the entry.

This is indicated with the (290/2) notation next to the c value.

The red arrows show a connection between the c value and the matching x+n value as the multiples increase.

The green arrows show a similar connection between x+n and u values as the multiples increase.

And the yellow square shows how the (c/2) adjusted record for c290 matches to c1160, which otherwise looks disconnected from the pattern.

The rules appear to be:

1) any c multiplied by 2^2, the matching entry can be found where (x+n) = c-1.

2) even c multiplied by 2, the next entry can be found where (x+n) = 2(x+n) + 1.

Which possibly means that we can work backwards from a given (x+n) in steps of (x+n-1)/2 to find factor records. At least for numbers divisible by 2.

>>6494

>>6541

Just an indication of where this can be applied, and more specifically where it falls short.

Attached pic for c299008 shows grid factor records in (e,n).

Using either of the following formulas to navigate backwards, we can hit all except the 3 records underlined in red.

previous x+n = ((x+n)-(a+a/2))/2

or

previous x = x - a

>>6541

A slightly different method for linking records exists for factors of 5.

Pic attached shows 10 records starting from c145 and then multiplied by 5^1, 5^2, 5^3, up to 5^10.

Green arrows indicate a relationship between u and the next factor record's x+n.

Red arrows indicate a relationship between c and the previous factor record's x+n.

Moving down, the relationship is x+n = u * 10 + 2.

And moving up, the relationship is x+n = (c - 5)/10.

Not a solution, but interesting nonetheless.