PMA !dSvrkhSLR6 ID: 7d9676 April 2, 2018, 11:22 p.m. No.5348   🗄️.is 🔗kun   >>5349 >>5353 >>5406

>>5317

A bit of a performance improvement.

 

While further reviewing the data for the iterative search, I came across a performance improvement relating to the "balancing total" in my previous post.

 

Attached pic for c=7463 shows the last few iterations for the prime solution. Notice how the n0 and XPN values remain the same for different values of est XPN. This is a result of the "balancing total" adjustment explained previously that enables relatively close results to "click" into place.

 

So why do we need to test the same n0 value multiple times?

 

Turns out we don't.

 

The range over which the XPN remains the same for various est XPN values can be determined.

 

By calling the Get_n_from_odd_triangle_base method with the est XPN and next n0 (i.e. n0+1), and adding the absolute value of the result to the current rm 2d(n-1), we can determine the exact spread of est XPN values that will result in the same XPN. This spread can then be used to adjust the iterative search factors to skip relatively large chunks of f-2 div 40 that would otherwise result in duplicate calculations.

 

In addition, because the parity of the prime n and starting n values are always the same, we can increase the next n0 to n0+2 in cases where the parities match.

 

The remaining pics attached show the original and revised iteration results for various odd x+n values. Full revised results are posted at https://pastebin.com/imn7X5M8.

 

The most significant performance improvement can been seen for c=208975787, where the number of iterations has been reduced from 11,153,430 to 4274. Another noteable result is for c=9874400051 where iterations have been reduced from 103 to 11.

 

And in all except the smallest test cases (where the gcd would apply), the iteration process is now faster than directly iterating n values.