In the immediately previous release, our square residues (`% N`) were perfect squares, but it's trivial to confirm (with debugging `std::cout` statements) that `solveCongruence()` did not find perfect squares on both sides of the equation. By restoring the logic that **forces** all sieving candidates to become smooth **perfect squares**, it's similarly trivial to confirm that **now all purported solutions have perfect squares on both sides of the equation** of `solveCongruence()`. **However**, we're finding that almost all of these congruences are **trivial**, i.e. satisfying the intended form of the equation but not leading to a factorization in practice.
This seems **tantalizing**, in terms of discrete mathematical theory. It could be that the simple prescription to overcome this very last hurdle is to **find a very large number of solutions**, but, given how **ridiculously fast** the sieve seems to be, despite the high incidence of trivial congruence of squares, it **could be worth it**.
**Full Changelog**: https://github.com/vm6502q/FindAFactor/compare/v5.2.1...v5.2.2
sha1sum results:
927df80cafa2525630f5a6cf9a89bcf83db626db FindAFactor-5.2.2-cp310-cp310-manylinux_2_35_x86_64.whl
55527ac08ce9090340dde167da15e5f3fe85703a FindAFactor-5.2.2-cp312-cp312-manylinux_2_39_x86_64.whl
8632d8e9e8a6cd68e87696f7b3c3a8c47032679f FindAFactor-5.2.2-cp312-cp312-win_amd64.whl
219c8cd8a569b5b0d198b83c5d7125b069809478 FindAFactor-5.2.2-cp313-cp313-macosx_13_0_x86_64.whl
d42ca3f6fdcefa6ad642743128784e9b43cba6a6 FindAFactor-5.2.2-cp313-cp313-macosx_14_0_arm64.whl
c9c25bacaeaec545c39280175a6ac0385fd6820c FindAFactor-5.2.2-cp313-cp313-macosx_15_0_arm64.whl
15ee384e2ce382f6a8b0429bf6b2e651df93cde5 FindAFactor-5.2.2-cp38-cp38-manylinux_2_31_x86_64.whl
b5dee3c0e81242c2bfc71a838395bbb9077c62d4 findafactor-5.2.2.tar.gz