3rd record looks weird. Shouldn’t that be e=-144?
Just tested your {144:0:17:12:5:29} record.
It fails this check:
c == ( d * d ) + e
If you look at the original data in the grid, the t value in the (-e, 0) space is unreliable. See pic of records in (-16,0) with t = 2.
I don't believe you can generate these records using t as an input parameter.
>Something interesting is that it shows 17, and 17^2-12^2 = 145
That is interesting. Will look into also.
>You can't rely on d^2+e
Not sure about that. I've been generating records all over the place (including the left half) without any failures just using that IsValid check I posted before. Happy to post it again.
The 17^2 - 12^2 = 145 comment is a good observation. Have confirmed on other records.
This makes sense, because normally (d+n)^2 - (x+n)^2 = c, and we are dealing with n = 0. So everything here is a perfect square.
MA - we're still searching.
Can't summarize everyone's work, but VQC did drop some hints again about (n-1)*a transforms from (e,n) into (e,1).
He mentioned that an offset can be found to solve the problem by analyzing (d[t] - d)/(n-1) factors and comparing them with a[t]/n.
I've posted an example for c=145 that shows my limited understanding of this.
There was also a recent reminder about records in the (-e, 0) space that also contain the prime results we are looking for.
Patterns and patterns all over the place. But nothing yet that links any c records to prime solutions.
Just posting some additional tests of the (-e,0) space.
This includes records for both c and p (prime solution), and the (-d^2, 0) record they both share.
Interesting that the c value from (-d^2) less the original e equals the e value in the (-e,0) record.
And corrected method is:
public static TheEndRecord CreateForZeroN( TheEndRecord ter ) {
BigInteger a = ter.a;
BigInteger b = ter.b;
BigInteger n = 0;
BigInteger x = (b - a) / 2;
BigInteger d = b - x; // this was posted incorrectly earlier.
BigInteger e = -(x * x);
return new TheEndRecord( e, n, d, x, a, b );
}
Here is another example of what doesn't quite work in different test cases, but works for c=901.
Might be considered a follow up to my post at >>3093 but using the (e,1) na records only to solve.
Starting na record for c=901
(1,1,15) = {1:1:450:29:421:481}
Destination na record for prime solution
(1,1,7) = {1:1:98:13:85:113}
New d formula:
newD = d - ( (d[t] diff) * (x+1) - (a[t] diff) * (x-1) )
the d[t] diff value can be calculated from (x^2 - f)
the a[t] diff value is d[t] diff - 4
In this example:
d[t] diff: 120
a[t] diff: 116
x+1 = 30
x-1 = 28
98 = 450 - (120 * 30 - 116 * 28)
Thank you for clarifying.
I looked into f records previously. But not with regards to the d[t]-d pattern. Will revisit.
Regarding the (-e,0) discussion earlier, attached pic are various test cases showing c and prime solution and their corresponding (-e,0) records.
In some cases, there is a defined relationship between the 2.