Hi everyone!
Last week, I shared some tests with you regarding the divisor-centric model GC60_M30x8_suffix. Today, I am here to show you a theoretical shift in perspective that led to the creation of a purely dynamic runtime engine I named LRLN (Local Residue Lattice Navigation), fully developed in Julia.
The full source code is available on GitHub: GitHub - Claugo/GC60-LRLN: LRLN (Local Residue Lattice Navigation) · GitHub
THE SHIFT IN PERSPECTIVE (Beyond the dogma of primality)In classical sieves, the informative relevance of a divisor coincides with its primality. In the LRLN framework (based on the GC-60 philosophy), relevance shifts to the geometric residue of the divisor with respect to the search window W. Through the deterministic condition p - R <= W (where R = n mod p) and the dynamics of even/odd residues, the algorithm classifies divisors upfront directly at runtime, without the need for pre-calculated databases. If the geometric projection of a divisor does not intersect the workspace, it is discarded instantly (early exit). The window thus becomes a passive container, and the complexity of the sieving uncouples from the global magnitude n, depending only on the window size W.
JULIA’S CRITICAL ROLE AND BENCHMARKS. Julia proved to be extraordinary for this approach. In early drafts, I struggled with closure boxing inside parallel loops (Threads.@threads), which generated billions of phantom allocations and slowed down the CPU. By sealing the variable scope with let blocks and standardizing step types to UInt64, memory management went back to being native and extremely lightweight.
Here are the results of the latest stress-test (performed at normal hardware temperatures):Starting magnitude (n): 10^19 Window size (W): 1.000.000 (1 million units) Active divisor filter: Drastically reduced from 49 million down to just 813,511 useful elementsParallel Sieve execution time: 0.054 seconds (54 milliseconds) on a standard 8-thread architectureTotal execution time is just over 2 seconds.
The generated offsets file was 100% validated through a rigorous sequential point-to-point check (using SymPy’s nextprime in Python), confirming the fully deterministic nature of the calculation.
I would be honored to receive your feedback, and I want to thank everyone who read my previous post, especially those who left a like and Oscar_Smith, who kindly tested and improved it.The documentation (in Italian) can be found on Zenodo under record 21266422, downloadable as a PDF.