(4,1,2) = {4:1:6:2:4:10} = 40
(4,1,3) = {4:1:14:4:10:20} = 200
(4,1,4) = {4:1:26:6:20:34} = 680
DJT
>Looks like you've successfully increased values of n0^2 and 2d(n-1) until finding a match.
For small numbers, I have a process that works, but it essentially just increments u until it finds a match. When taking larger jumps of u, it's hit and miss. Trying to analyze a possible next step.
Went back to the grid (we've been away far too long!).
Attached pics are for e=0, e=2, e=4, and e=6. Each record now includes a value of u for odd x+n.
Notice how the u increments by n, and in some cases by both 1 and n.
These formulas are all equivalent.
(x+n)(x+n) 1 + 8T(u) (nn-1) + 2d(n-1) + f
VQC refactored into:
8T(u) == nn +2d(n-1) + f - 2
T(u) == (nn +2d(n-1) + f - 2) / 8
And then reduced size by 1/5 as an estimated starting position. That's where the (f-2) / 40 came from.
What's missing in the iteration process, is a way to appropriately handle the (nn + 2d(n-1)) / 40 piece and it's mod. This is where inaccuracies come into play as the numbers get larger. We know d and are estimating n as n0. And for RSA size numbers, we fly right on bye extremely quickly with this approach.
So something else has to come into play.
>Do you have a method yet to check each iteration?
Only thing we have at this point is a check on the result from Get_Remainder_2dnm1. And still not seeing how that helps us determine the "more geometry of triangular numbers" hint.
I was under the impression in the last thread that VQC dropped enough clues to solve the odd number RSA values. And he would stay away until that was accomplished. (Although it would be AWESOME if he came back soon!)
Going to once again go back and review previous posts to see if anything jumps out.
>You're saying that 2d(n-1) is a square? In which cases?
Put together another test to try and explain a bit clearer what I'm seeing regarding the "capstones".
The tests are for odd x+n only.
The "capstone area", represents the red square in >>4758. I am arriving at that number by calculating a triangle base (difference between nn-1 in c and p records), and then subtracting that from c (x+n)(x+n). (nn-1 is the purple area.)
Therefore, the formula for the "capstone area" is 2d(n-1) from the c starting position, plus f, plus the nn-1 portion of the prime solution we are looking for.
This is always a square that can be defined using the 1+8T(u) formula, plus some remainder. Where the remainder is always divisible by 8. In order words, 1 + 8 triangles + an equal extra portion for each triangle.
Love the new images. The world is a confusing place.
>The concern here is that a minor adjustment to this algorithm needs to be made
Think I've found the minor adjustment.
Revised tests for 211073351 and 9874400051 attached. The change is that the remainder 2d(n-1) needs to be subtracted from the estimated XPN.
XPN = est XPN - rm 2d(n-1)
The XPN column is the final value to check. Notice now that the "x+n rm" column is zero. We have a perfect square.
This works for EVERY one of my test cases.
I have tried many different denominators in multiples of 8. Understanding how to handle the remainders is the key. Not how the f-2 chunks are divided.
In order to make this a very efficient solution, we need a way to sub-divide the remainder area to determine if the solution could fall within that area, or simply skip to the next one. Perhaps this is where the "more geometry of triangular numbers" comes into play.
>still looking for a way to verify when we arrive at the correct solution
No. This part is done.
I'll post a bit later some thoughts on how to tackle speeding up the remainder search.
Just posting one more example to explain the u midpoint and tree connections. This might make it a bit easier to see what I was talking about.
Pics attached are for c=9874400051. And include the iterative solution, the d and e factor tree including some f properties, and an annotated u div 2 parse tree.
Because of the low n value in the prime solution, the iteration process happens entirely in the "remainder" portion. Before any triangle can be made from a factor of (f-2) div 40.
The iterative solution here is reasonably quick at 103 calculations.
The u/2 parse tree calculated from the midpoint between the starting est u of 0 and the next rm u of 4889 results in 4095 nodes.
Only the path to the solution u of 996 is included. And would require only 12 iterations, assuming we could determine the correct path to take.
Which leads me back to thinking that we really need to understand the original parse tree to finish this iterative approach.
VA - Hope this clarifies. I'm considering the "remainders" as falling within the gap between two triangle bases, f-2 div 40 units apart.
Still looking for something concrete that can relate the 2 triangles together.
Attached pics are for c=115 and show various iterative results and a few diagrams of how the different sized triangles may come together around the solution small square.
Included in the diagram are the grid entries for the starting c, solution p, and prime a and b records, together with some observations about how the squares relate to each other.