>>8834

Example of how q primes help to reduce the search space.

First pic attached is for c25185549107 and shows summary output for the iterative search process at n/4 performance. The solution n=353827 is found in 885458 iterations.

Second pic represents gcd(a[t],c) solutions for different q*c products.

Search methodology here is simply iterating t in each (e',1). The t column is the grid index and number of iterations.

Tests run using various combinations of primes. (Those ending in binary 01, 11, and either).

Interesting that the best result for all these tests is 224 iterations and uses any prime.

>>8871

>885458 iterations

s/b 88458

>>8874

appreciate the insight. added clarity to >>8860

First pic attached is for c259 and shows how the a[t] values in (0,1) and (1,1) can be used to calculate (e,1) records where a=c.

Relevant formulas are:

e = e + (c-a[t])/2

e = e + (c-a[t]^2)/2

with valid records shown in their respective ter columns.

Second pic relates those records to the previous method which starts at (2c,1,1), and moves left via e = e - 4 * (x + 1).

>>8891

Taking this a bit further.

For c6107, the attached picture includes three grids:

1) calculated e values from (0,1) and (1,1).

2) matching (e,1) records in the (2c,1,1) sequence moving left (t=1,2,3…). (red underline)

3) matching (e,1) records in the (2c-1,1,1) sequence moving left (t=1,2,3…). (green underline)

For each of the calculated records, a gcd(a[t],c) factor record can be found earlier in the (e,1) column.

>>8899

nice.

Looks like this works from any record if you hold a constant and the multiple is a square.

>>8938

All equivalent.

c % d dd + e % d e % d

>>8947

MM, likewise.

>>8952.

AA's correct about the t formulas.

The previous output for c259-pivot was filtered to just relevant records. Attached is an unfiltered view for c259 showing from t=1 to t=25.

Also attached are the seed elements for (-10,1) through (10,1) for t=1. Just to make sure you're aligned properly.

>>8963

>are you suggesting we ignore the original VQC algorithm and grid?

no, most definitely not.

But we should understand that it was a small subset of an infinite grid.

If you look at the original CreateTheEnd method in >>20, you'll notice that the grid is created by iterating i (d+n) from 0 to 512 and j (x+n) from 0 to < i. This generates data between (0,n) and (1020,n), over an n range of 0 to 480.

The records in the (-f,n-1) portion of the grid are created during the same loops, but from these combinations in (e,n).

The separate Output method then further constraints the generated data to e values between -64 and 64, n values between 0 and 64, and a maximum of 12 entries for each distinct (e,n). Making the subset easily digestible in spreadsheets.

Excluded from all of the sample data are records with negative d or negative x values.

For example, attached are valid records in (-4,1) and (-9,1) for t between -20 and 20.

You'll notice that the output you posted doesn't include any records before (-4,1,3) or (-9,1,3).

>>9001

>>9007

Pell(n) and ST(n) sequences attached.

ST(45) in row 23.

>>9083

>When is the remainder of (DPN + XPN) a square?

DPN + XPN = d+n from the (0,n) c^2 record.

moving right from that record by e = e + 2 * n (i.e. 2n), and e is always a square.

example:

c106577

i^2 = 2839717521

j^2 = 2839610944

i^2 + j^2 = 5679328465

c^2 record

(0,5679221888,53289) = {0:5679221888:106577:106576:1:11358656929} = 11358656929; f=213155; (x+n)=5679328464; (d+n)=5679328465

mv right

(11358443776,5679221888,53289) = {11358443776:5679221888:106578:106576:2:11358656930} = 22717313860; f=-11358230619; (x+n)=5679328464; (d+n)=5679328466

sqrt(11358443776) = 106576 = c-1

Working through a recursive approach to column selection and iteration using the trimmed qc-c value.

Pic attached is for 97397 x 572816239 = c55790583229883.

d, e, and f values are computed recursively from e, starting with the remainder of sqrt(qc-c). Column selection is based on either e or f being perfect squares, otherwise ignored.

Within that column, simply iterating t until gcd(a[t],c) match is found.

In this example, the solution is found in (4,1) in 3759 iterations.

Previous iterative search, with n/4 performance, would have found a match in 69746877 iterations.

>>9112

>>9119

Haven't quite gotten to the 6 calculations for c3638604803.

>>9128

> what happens if you multiple d by two?

But using different multiples of d[t] - m*d does lead to a few more c values with instant factoring.

For example, in the range 3638600000 to 3638610000:

d[t]-2d

c3638601837 = {99437:60841:60320:44237:16083:226239}

d[t]-7d

3638604589 = {102189:362297:60320:55993:4327:840907}

d[t]-26d

c3638609991 = {107591:1507276:60320:59159:1161:3134031}

d[t]-197d

c3638600253 = {97853:11830607:60320:60167:153:23781701}

>>9119

For c3638604803, where we don't find an exact d+n match in D, D2, D_f, or D_f2, there is a way to at least iterate to the correct d+n square.

The next d value can be calculated for each record as next_d = b + (x + 2), which gives us a start and end d+n range to iterate through by d+2.

Not terribly efficient, but it does work if we could determine which D record to use as the starting position.

From:

D = {102403:1:60179:133:60046:60314}

[failed] in 135 iterations at {102943:1:60449:133:60316:60584}

From:

D2 = {102403:1:60449:135:60314:60586}

[success] in 7 iterations at {102427:1:60461:135:60326:60598}

From:

D_f = {-18238:1:59701:370:59331:60073}

[failed] in 372 iterations at {-16750:1:60445:370:60075:60817}

From:

D_f2 = {-18238:1:60445:372:60073:60819}

[success] in 9 iterations at {-18206:1:60461:372:60089:60835}

>>9132

>Does subtracting increasing multiples of d give n?

Explored this angle a bit further, under the assumption that md would be used to find a record in (-f,1) and (e,1) where d[t] is below md.

Then in each column comparing the difference between abs(d[t] - md) and the solution n.

Pics attached are results for a few test cases where n, n+1, or n-1 appeared.

c6107 - finds n+1 and n-1

c7633 - finds n

c34117 - finds n+1

c21059917 - finds n and n-1

This didn't work in all cases, as the closest matches for c260891 was n+5 and n-5.

>>9096

>>9098

>>9102

Noticed that the offset calculation for d[t] always returns either 2 or 6 and can be used to group a range of odd numbers.

Pics attached show these groupings for small odd values between 1 and 1000, and larger c values between 900120005 and 900550000 to demonstrate that the pattern holds.

For each range of numbers, half of the set has an offset of 6, the other half an offset of 2.

For example:

1, 3: offset 6

5, 7: offset 2

9, 11, 13, 15: offset 6

17, 19, 21, 23: offset 2

etc.

>>9134

>>9135

Found some c values where n-1 can be calculated directly using D, D_2, D_f, or D_f2. And c3638604803 falls into that category.

Pic attached show examples between c3638604803 and c3638610000.

The new method is indicated in the result column as "nm1", and calculated as:

i = 2d - d[t] + 1

>>9139

Offset calculation can be further simplified. Looks like they are tied directly to e parity.

even e: offset 6

odd e: offset 2