>>888

>>907

Bit of an update here.

You can switch from an (e,n) record to (e,1) by setting n = 1 and a = na.

There is a shortcut to get to the (1xcc) a=na record for any c.

e = 0

n = 1

t = (c+1)/2.

Example below shows shortcut to (1 x cc(na)) for c =145.

The (0,1) space has known patterns.

Trying to figure out a jump to (aa x bb).

—————————

145=5x29

1 x c *=(1,61,6) = {1:61:12:11:1:145} = 145;

a x b **=(1,5,4) = {1:5:12:7:5:29} = 145;

aa x bb *=(0,288,61) = {0:288:145:120:25:841} = 21025;

1 x cc *=(0,10368,73) = {0:10368:145:144:1:21025} = 21025;

1 x cc(na) development where a=na at (0,1)

1 x cc(na) confirmed at (e,n,t) from t=(c+1)/2: (0,1,73)

1 x cc(na) *=(0,1,73) = {0:1:10512:144:10368:10658} = 110502144;

a root = sqrt(a/2) = 72

d root = 2(t-1)(t) = 27273

>>925

not (e,1). (0,1).

From that, you can switch a=na again and get to the (1xcc) record. I think these are like pointers.

>>927

I have some sample code somewhere and examples posted in these threads that showing jump from (e,n) to (e,1) and back. Will try and cleanup when we get to the end.

This is a shortcut directly to (0,1,t). Pretty powerful stuff.

>>928

my bad…

>>929

>huge

would be finding a way to get to (aa x bb)!!!

>>940

currently I'm playing with the idea of moving any (e,n,t) to (0,1,t). Seeing what relationships are there.

>>924

in my example above, I don't think it's coincidence that the c^2 record is at (1,10368,73) and it's corresponding a=na record is at (0,1,73).

I'm trying to find a pattern that can bridge the gap between the (c^2).x and (aa x bb).x

Or even move directly to the (ab) solution.

It looks like all the heavy lifting has been done by the grid.

>>946

confirmed.

my latest test case for c=145. Looking for a pattern to calculate the x at (aa x bb).

or any other suggestions!

—————————

145=5x29

1 x c *=(1,61,6) = {1:61:12:11:1:145} = 145;

a x b **=(1,5,4) = {1:5:12:7:5:29} = 145;

aa x bb *=(0,288,61) = {0:288:145:120:25:841} = 21025;

1 x cc *=(0,10368,73) = {0:10368:145:144:1:21025} = 21025;

(0,1) records to analyze

1 x c at (0,1,t) =(0,1,6) = {0:1:60:10:50:72} = 3600;

x=10

a root = sqrt(a/2) = 5 from 50

d root = 2(t-1)(t) = 256 = 60

a x b at (0,1,t) =(0,1,4) = {0:1:24:6:18:32} = 576;

x=6

a root = sqrt(a/2) = 3 from 18

d root = 2(t-1)(t) = 234 = 24

aa x bb at (0,1,t) =(0,1,61) = {0:1:7320:120:7200:7442} = 53582400;

x=120

a root = sqrt(a/2) = 60 from 7200

d root = 2(t-1)(t) = 26061 = 7320

1 x cc at (0,1,t) =(0,1,73) = {0:1:10512:144:10368:10658} = 110502144;

x=144

a root = sqrt(a/2) = 72 from 10368

d root = 2(t-1)(t) = 27273 = 10512

1 x cc (0,1,t) confirmed at (e,n,t) from t=(c+1)/2: (0,1,73)

1 x cc (0,1,t) sqrt(a/2) = 1 x c (x+n); 72 = 72

(1 x cc).x - (aa x bb).x = 144 - 120 = 24

sqrt( (1xcc).d - (aaxbb).x ) == (axb).a

sqrt( 145 - 120 ) = 5. (a matches!!!!)

>>1025

The code is a bit sloppy, but the ability to create various records is sound, and every record is verified in the constructor.

So I know the values that I’m looking at are accurate.

The relationships are difficult to understand. And the number of records to bring together is a bit much.

I’m sticking around for the solution - it would be terribly frustrating otherwise.

>>1027

Sounds good. I need some new avenues to explore.

>>1032

I’ve looked at x and n in (0,1) up the yin yang. x, x^2, 2x, x/2, +1, -1, multiples between records, relationships to a, b, c, small square, big square, square root.

Every time I thought I had a breakthrough I went to a different c value and it all broke down.

I know there’s a simple solution here.

In the (0,1) space the formulas get a bit easier as e = 0.

And we’re now dealing with perfect squares.

You’d think that the prime solution would be smack in the middle of the c and cc records. Or that the original e, d, or x would factor in somehow.

>>1046

>>1045

I’ll look into the formula later.

Re-reading vqc notes.

>>1047

f = 2d+1-e (f is what you add to c to make a square)

(x+n)(x+n) = nn + 2d(n-1) + f - 1

Research further…

Found a link between our entry c value and the cc record in (0,1).

(0,1).d == ( ( c - 1 ) / 2 ) * ( c + 1 );

Still looking for elusive d formula from x…

—————————

145=5x29

a x b *=(1,5,4) = {1:5:12:7:5:29} = 145;

1 x c =(1,61,6) = {1:61:12:11:1:145} = 145;

aa x bb =(0,288,61) = {0:288:145:120:25:841} = 21025;

1 x cc =(0,10368,73) = {0:10368:145:144:1:21025} = 21025;

(0,1) perfect squares to analyze

aa x bb (0,1) =(0,1,61) = {0:1:7320:120:7200:7442} = 53582400;

1 x cc (0,1) =(0,1,73) = {0:1:10512:144:10368:10658} = 110502144;

ccna.d = 10512 compared to 10512 = 0

((ter.c - 1) / 2) * (ter.c + 1) = ((145 - 1) / 2) * (145 + 1)

(ccna.d record match!)

>>1099

>>1117

Also analyzing the (0,n) space.

There is a path to the correct record. Below are 2 examples for 3x5 and 3x7.

Substituting the a-b values at e = 0.

For the 3x5 example, I tried simply to use the new.d = (prev.d / 2). Not quite right.

Looks like we need to figure out this movement to solve.

15=3x5

a x b *=(6,1,1) = {6:1:3:0:3:5} = 15;

1 x c =(6,5,2) = {6:5:3:2:1:15} = 15;

aa x bb =(0,2,4) = {0:2:15:6:9:25} = 225;

1 x cc =(0,98,8) = {0:98:15:14:1:225} = 225;

(0,1) perfect squares to analyze

aa x bb (0,1) =(0,1,4) = {0:1:24:6:18:32} = 576;

1 x cc (0,1) =(0,1,8) = {0:1:112:14:98:128} = 12544;

Path subtituting a -b

(0,1,8) = {0:1:112:14:98:128} = 12544;

(0,9,13) = {0:9:56:24:32:98} = 3136;

(0,1,4) = {0:1:24:6:18:32} = 576;

21=3x7

a x b *=(5,1,1) = {5:1:4:1:3:7} = 21;

1 x c =(5,7,2) = {5:7:4:3:1:21} = 21;

aa x bb =(0,8,7) = {0:8:21:12:9:49} = 441;

1 x cc =(0,200,11) = {0:200:21:20:1:441} = 441;

(0,1) perfect squares to analyze

aa x bb (0,1) =(0,1,7) = {0:1:84:12:72:98} = 7056;

1 x cc (0,1) =(0,1,11) = {0:1:220:20:200:242} = 48400;

Path subtituting a -b

(0,1,11) = {0:1:220:20:200:242} = 48400;

(0,9,22) = {0:9:140:42:98:200} = 19600;

(0,1,7) = {0:1:84:12:72:98} = 7056;

>>1166

Topol, keep it up. Words and insights are very helpful.

>>1168

Teach - thanks for adding clarity!

>>1131

Teach - in case you missed it yesterday, I was able to piece together a path through various (0,n) records starting from (1xcc) and getting to (aaxbb).

I can see the path clearly, and there most likely is some elegant math to jump directly to it.

In the meantime, I've gone back to the "drawing board", as VQC suggested and think I've figured out the pattern to walking up and down the tree at (0,n).

Rather than flood with examples, following are the formulas:

to walk up the tree at (0,n)

n is odd: new.d = d + 2*(x+n) + 2n

n is even: new.d = d + (x+n) + n/2

to walk down the tree at (0,n)

n is odd: new.d = d - 2*(x+n) + 2n

n is even: new.d = d - (x+n) + n/2

I have verified this with data from (0,1) through (0,6). Both up and down.

>>1170

Records in the (0,1) space are very well defined. We can break them into their component parts very easily to get an answer.

For example at (0,1,4) we know that the value of a = 18 can be represented as 2*(3^2). And the prime answer is "3".

Squaring the c, puts us into the (0,n) space. Substituting a = na, puts us in the (0,1) space.

And creating the record directly by (0,1) and t = (c+1)/2, is a shortcut to getting to (1xcc) for any c.

Now there, the trick is finding that aa*bb record.

Subsequent records in a column are connected by a -b movements.

In reviewing some data, I found a way to get to the b value of the (aa*bb) record, by going through 1 jump.

Start with the (cc) record, move it's a to the next record b (figure out the d), and then one more jump to the aa*bb record.

I've verified this path twice, but calculating the d value presented a problem.

Hence my previous post.

>>1173

I posted earlier in this thread a way to calculate the d value for the (1xcc) record directly from c.

So I figured to focus a bit on navigating records by changing d values.

Path subtituting a -b

(0,1,8) = {0:1:112:14:98:128} = 12544;

(0,9,13) = {0:9:56:24:32:98} = 3136;

(0,1,4) = {0:1:24:6:18:32} = 576;

First record is the (1xcc) record. Last is (aaxbb).

Notice the movement of a to b in each step. e is always 0, n is 1 in the first and last record. We have the a value in the first record. So we need one more variable to move to the second step, and then we will have the a value to use in the last calculation.

This may not be the end solution, but this is the first time I've seen a direct connection between an (axb) and (1xc) record.

>>1169

well, shit. turns out the d movement formulas work for all cases of (e,n).

Walking up tree 5 iterations from a=5, b=41.

(9,9,5) = {9:9:14:9:5:41} = 205

(9,9,14) = {9:9:68:27:41:113} = 4633

(9,9,23) = {9:9:158:45:113:221} = 24973

(9,9,32) = {9:9:284:63:221:365} = 80665

(9,9,41) = {9:9:446:81:365:545} = 198925

(9,9,50) = {9:9:644:99:545:761} = 414745

Walking down tree 5 iterations from a=157, b=273.

(12,8,26) = {12:8:207:50:157:273} = 42861

(12,8,22) = {12:8:153:42:111:211} = 23421

(12,8,18) = {12:8:107:34:73:157} = 11461

(12,8,14) = {12:8:69:26:43:111} = 4773

(12,8,10) = {12:8:39:18:21:73} = 1533

(12,8,6) = {12:8:17:10:7:43} = 301

>>1180

Thanks Teach. I will look into this soon.

>>1183

>>1184

Teach - good eye.

Following are what I have for all grid entries at (59,5)

(59:5:10) = {59:5:61:19:42:90} = 3780; (x+n)=24x24=576; (d+n)=66x66=4356

(59:5:11) = {59:5:71:21:50:102} = 5100; (x+n)=26x26=676; (d+n)=76x76=5776

(59:5:15) = {59:5:119:29:90:158} = 14220; (x+n)=34x34=1156; (d+n)=124x124=15376

(59:5:16) = {59:5:133:31:102:174} = 17748; (x+n)=36x36=1296; (d+n)=138x138=19044

(59:5:20) = {59:5:197:39:158:246} = 38868; (x+n)=44x44=1936; (d+n)=202x202=40804

(59:5:21) = {59:5:215:41:174:266} = 46284; (x+n)=46x46=2116; (d+n)=220x220=48400

(59:5:25) = {59:5:295:49:246:354} = 87084; (x+n)=54x54=2916; (d+n)=300x300=90000

(59:5:26) = {59:5:317:51:266:378} = 100548; (x+n)=56x56=3136; (d+n)=322x322=103684

(59:5:30) = {59:5:413:59:354:482} = 170628; (x+n)=64x64=4096; (d+n)=418x418=174724

(59:5:31) = {59:5:439:61:378:510} = 192780; (x+n)=66x66=4356; (d+n)=444x444=197136

And here is my walking up formula for a=42, b=90 and a=50, b=102.

Walking up tree 5 iterations from a=42, b=90.

(59,5,10) = {59:5:61:19:42:90} = 3780

(59,5,15) = {59:5:119:29:90:158} = 14220

(59,5,20) = {59:5:197:39:158:246} = 38868

(59,5,25) = {59:5:295:49:246:354} = 87084

(59,5,30) = {59:5:413:59:354:482} = 170628

(59,5,35) = {59:5:551:69:482:630} = 303660

Walking up tree 5 iterations from a=50, b=102.

(59,5,11) = {59:5:71:21:50:102} = 5100

(59,5,16) = {59:5:133:31:102:174} = 17748

(59,5,21) = {59:5:215:41:174:266} = 46284

(59,5,26) = {59:5:317:51:266:378} = 100548

(59,5,31) = {59:5:439:61:378:510} = 192780

(59,5,36) = {59:5:581:71:510:662} = 337620

My walking tree formula seems to iterate only the movements from a -b. Not sure if this is a bug or a feature.

>>1195

>>1197

Happy holidays to everyone.

I adjusted my test case to include the latest walking of the tree using calculated values of d.

Review the TestIterateMovementToAABB line below.

It may look like I'm simply subtracting 1 from t each time, but the reality is that the previous d value is being calculated from the current record using the formula:

return ter.d - 2 * (ter.x + ter.n) + 2 * ter.n;

where ter is the current record.

I think that if we can figure out now how to skip multiple records using a factor, we have a workable solution.

—————————

145=5x29

a x b *=(1,5,4) = {1:5:12:7:5:29} = 145;

1 x c =(1,61,6) = {1:61:12:11:1:145} = 145;

aa x bb =(0,288,61) = {0:288:145:120:25:841} = 21025;

1 x cc =(0,10368,73) = {0:10368:145:144:1:21025} = 21025;

(0,1) perfect squares to analyze

aa x bb (0,1) =(0,1,61) = {0:1:7320:120:7200:7442} = 53582400;

1 x cc (0,1) =(0,1,73) = {0:1:10512:144:10368:10658} = 110502144;

TestDCalculationFromC

———————

ccna.d = 10512 compared to 10512 = 0

((ter.c - 1) / 2) * (ter.c + 1) = ((145 - 1) / 2) * (145 + 1)

(ccna.d record match!)

TestIterateMovementToAABB

1) (0,1,72) = {0:1:10224:142:10082:10368} = 104530176

2) (0,1,71) = {0:1:9940:140:9800:10082} = 98803600

3) (0,1,70) = {0:1:9660:138:9522:9800} = 93315600

4) (0,1,69) = {0:1:9384:136:9248:9522} = 88059456

5) (0,1,68) = {0:1:9112:134:8978:9248} = 83028544

6) (0,1,67) = {0:1:8844:132:8712:8978} = 78216336

7) (0,1,66) = {0:1:8580:130:8450:8712} = 73616400

8) (0,1,65) = {0:1:8320:128:8192:8450} = 69222400

9) (0,1,64) = {0:1:8064:126:7938:8192} = 65028096

10) (0,1,63) = {0:1:7812:124:7688:7938} = 61027344

11) (0,1,62) = {0:1:7564:122:7442:7688} = 57214096

12) (0,1,61) = {0:1:7320:120:7200:7442} = 53582400

Matching aabbna record found!

(1 x cc).x - (aa x bb).x = 144 - 120 = 24

sqrt( (1xcc).d - (aaxbb).x ) == (axb).a

sqrt( 145 - 120 ) = 5. (a matches!!!!)

>>1199

>Is that a coincidence?

yes.

There is a formula here.

>>1239

good job. I'll look into this in a bit a see if it applies to other test cases.

>>1239

>>1245

confirmed.

using the formula for a new d value is equivalent to what I posted earlier.

return ter.d - 4 * ter.t * m + 2 * m * ( m + 1 );

This works for jumping m levels down.

Excellent anon!

If we know the "m" value, we can jump directly to the aabbna result.

>>1257

Following are a couple of my test cases, just to emphasize the importance of a formula for "m".

Also, I haven't tested using t and m to move d in the up the tree, or with odd/even values of n.

for c = 145, only 12 iterations to find the value.

for c= 6107, we're up to 480 iterations.

—————————

145=5x29

a x b *=(1,5,4) = {1:5:12:7:5:29} = 145;

1 x c =(1,61,6) = {1:61:12:11:1:145} = 145;

aa x bb =(0,288,61) = {0:288:145:120:25:841} = 21025;

1 x cc =(0,10368,73) = {0:10368:145:144:1:21025} = 21025;

(0,1) perfect squares to analyze

aa x bb (0,1) =(0,1,61) = {0:1:7320:120:7200:7442} = 53582400;

1 x cc (0,1) =(0,1,73) = {0:1:10512:144:10368:10658} = 110502144;

TestDCalculationFromC

———————

ccna.d = 10512 compared to 10512 = 0

((ter.c - 1) / 2) * (ter.c + 1) = ((145 - 1) / 2) * (145 + 1)

(ccna.d record match!)

TestMLevelJumpingByD

Matching aabbna record found at m=12

(0,1,61) = {0:1:7320:120:7200:7442} = 53582400

(1 x cc).x - (aa x bb).x = 144 - 120 = 24

sqrt( (1xcc).d - (aaxbb).x ) == (axb).a

sqrt( 145 - 120 ) = 5. (a matches!!!!)

—————————

6107=31x197

a x b *=(23,36,24) = {23:36:78:47:31:197} = 6107;

1 x c =(23,2976,39) = {23:2976:78:77:1:6107} = 6107;

aa x bb =(0,13778,2574) = {0:13778:6107:5146:961:38809} = 37295449;

1 x cc =(0,18641618,3054) = {0:18641618:6107:6106:1:37295449} = 37295449;

(0,1) perfect squares to analyze

aa x bb (0,1) =(0,1,2574) = {0:1:13245804:5146:13240658:13250952} = 1909564816;

1 x cc (0,1) =(0,1,3054) = {0:1:18647724:6106:18641618:18653832} = -121773168;

TestDCalculationFromC

———————

ccna.d = 18647724 compared to 18647724 = 0

((ter.c - 1) / 2) * (ter.c + 1) = ((6107 - 1) / 2) * (6107 + 1)

(ccna.d record match!)

TestMLevelJumpingByD

Matching aabbna record found at m=480

(0,1,2574) = {0:1:13245804:5146:13240658:13250952} = 1909564816

(1 x cc).x - (aa x bb).x = 6106 - 5146 = 960

sqrt( (1xcc).d - (aaxbb).x ) == (axb).a

sqrt( 6107 - 5146 ) = 31. (a matches!!!!)

>>1263

>>1262

will do. figured if I couldn't see a pattern with int, big int wasn't going to add any clarity.

>>1275

I'm looking a bit closer at the sqrt(n/2) and sqrt(2n) you posted earlier.

What's missing from all of this is an understanding of how the squares resize.

>Sorry to be a downer.

I think we're almost there.

>>1278

Sure

>>1342

Just a little update.

>>1099

>The pattern GROWS in a certain way as n increases in column zero.

>This pattern is related to the pattern across row one (e,1)

Not sure if this was what VQC was talking about, but I've found a way to increment by c in (e,n).

Example output:

TestGrowingFromC

m=1: (6,5,7) = {6:5:27:12:15:49} = 735;sqrt(b)=7;

m=1: (6,11,10) = {6:11:33:18:15:73} = 1095;sqrt(b)=7;

m=2: (6,59,22) = {6:59:57:42:15:217} = 3255;sqrt(b)=14;

m=2: (6,77,25) = {6:77:63:48:15:265} = 3975;sqrt(b)=14;

m=3: (6,173,37) = {6:173:87:72:15:505} = 7575;sqrt(b)=22;

m=3: (6,203,40) = {6:203:93:78:15:577} = 8655;sqrt(b)=22;

The records are being created 2 ways for each iteration of m.

Method one:

BigInteger d = 2 * ter.c * m - ter.d;

BigInteger a = ter.c;

TheEndRecord eda = TerFactory.CreateForEDA( ter.e, d, a );

Method two:

BigInteger d2 = 2 * ter.c * m + ter.d;

BigInteger a2 = ter.c;

TheEndRecord eda2 = TerFactory.CreateForEDA( ter.e, d2, a2 );

Don't know if any of these records are related to a solution.

>>1544

VA. I posted a formula earlier for calculating new values of d for any (e,n).

>>1169

>>1181

Teach found a problem in (59,5) that I haven't circled back to.

>>1193

>>1559

Iterating the records lead to me to potential matches. But to be honest, I have so many different ways of iterating and creating records it's all a bit of a blur.

>There is some elegant formula hiding beneath all this

This I firmly believe.

Has anyone looked into these 2 formulas yet?

f = 2d + 1 - e ( f is what you add to c to make a square )

( x + n )( x + n ) = nn + 2d( n - 1 ) + f - 1

I was running a few tests around na records, and added these 2 formulas to my output for each record.

What's interesting about this is it appears that the f value equals the small square only at the na records.

Just guessing that maybe there is something in here indicating where we should search next?

c=145

(1,5,4) = {1:5:12:7:5:29} = 145;

f = (2 * 12) + 1 - 1 = 24;

(x+n)^2 = (5*5) + 2 * 12 * (5 - 1) + 24 - 1 = 144;

(x+n)^2 = 12x12=144;

c=145 na record

(1,1,4) = {1:1:32:7:25:41} = 1025;

f = (2 * 32) + 1 - 1 = 64;

(x+n)^2 (1*1) + 2 * 32 * (1 - 1) + 64 - 1 = 64

(x+n)^2=8x8=64;

>>1725

>Also, this may be an impossible task, but if anyone can generate an entry just given the (e,n,d) values that would be sweet, but I don't think we can.

public static TheEndRecord CreateForEND( BigInteger e, BigInteger n, BigInteger d ) {

BigInteger c = d * d + e;

BigInteger x = ( Lib.Sqrt( ( d + n ) * ( d + n ) - c ) ) - n;

BigInteger a = d - x;

BigInteger b = a + 2 * x + 2 * n;

return new TheEndRecord( e, n, d, x, a, b );

}

>>1728

Iterating to find the solution isn't going to work.

See a couple of my previous posts:

>>1342

>>1487

>>1509

VA - thanks for reposting this. Am thinking this through a bit more.

We've been one variable or formula away from a solution for some time now.

The "Use Y on C at X" from >>>/cbts/75435 needs more attention.

I think we know what C and X are. And we know how to create a small square from t. What is Y? y axis? is that n?

CA got me thinking a bit more about the END formula.

c = (d+n)^2 - (x+n)^2

This can be solved a couple of ways. And given that we know c, d, and e for our target aabb and ab records, perhaps if we can identify just the small square movement, we can solve for n.

For example:

Solving for x given n, d and c.

x = ( Lib.Sqrt( ( d + n ) * ( d + n ) - c ) ) - n;

Solving for n given e, d, and (x+n):

c = d*d + e;

n = Lib.Sqrt( c - (x+n)^2 ) - d

Maybe all we have to do is figure out the "small square" movement?

>>1730

yes. I'm focusing specifically on the small square (x+n). It's relationship to t is simple. And it remains constant when you change e at (e,1,t).

>>1731

forgot trip.

Also, if anyone can help explain "Use Y on C at X".

>>1733

>I've also been spending some time going through reading for ECC.

I tried to read some of those documents… realized I'm not that smart.

>n = (x^2 + e) / 2(d - x)

I like the concept. After all, this seems to be an exercise in taking a really small square to it's perfect middle size.

>>1734

I believe this get's solved in the (e,1) space where there aren't any gaps in t. Remember, looking for one more variable or formula. t is just an indexer on values of x. Don't think we want to start changing it's definition based on n.

>>1737

Teach - likewise. I'm not sure I fully understand, but here's where my head is by way of an example:

c=145

1 x c =(1,61,6) = {1:61:12:11:1:145} = 145; (x+n)^2=72x72=5184; (d+n)^2=73x73=5329;

1 x c na =(1,1,6) = {1:1:72:11:61:85} = 5185; (x+n)^2=12x12=144; (d+n)^2=73x73=5329;

In the first record, calculate (n-1)a = (61-1)1 = 60.

If you look at the differences in the n, d, and a values between (1,61,6) and (1,1,6) you will notice:

n = 1

d = d + 60

a = a + 60

So essentially the amount you take off of n gets added into the d and a.

This "transform" enables us to move from any (e,n) into the (e,1) space, and explains what's happening to d and a along the way.

I have played with this attempting to take off different values from n. (n-2), 2(n-1), etc. Haven't had much luck there.