![]() |
Hello,
on a Linux64 system I try to factor some composites with yafu. I have also the gnfs binaries there and in yafu.ini I have: ggnfs_dir=./ Until yafu uses siqs everything works fine. But using nfs it doesn't work. What could be the reason? [CODE]~/yoyo/yafu> ./yafu "nfs(221080477054123556214963727352459063280974722921522554478086751770699794939844735190723227284218841311)" -threads 6 nfs: commencing gnfs on c102: 221080477054123556214963727352459063280974722921522554478086751770699794939844735190723227284218841311 nfs: commencing polynomial search over range: 751 - 1001 deadline: 20 CPU-seconds per coefficient nfs: commencing polynomial search over range: 1251 - 1501 deadline: 20 CPU-seconds per coefficient nfs: commencing polynomial search over range: 1001 - 1251 deadline: 20 CPU-seconds per coefficient nfs: commencing polynomial search over range: 251 - 501 deadline: 20 CPU-seconds per coefficient nfs: commencing polynomial search over range: 501 - 751 deadline: 20 CPU-seconds per coefficient nfs: commencing polynomial search over range: 1 - 251 deadline: 20 CPU-seconds per coefficient elapsed time of 382.5109 seconds exceeds 241 second deadline; poly select done nfs: commencing algebraic side lattice sieving over range: 1240000 - 1280000 nfs: commencing algebraic side lattice sieving over range: 1200000 - 1240000 nfs: commencing algebraic side lattice sieving over range: 1040000 - 1080000 nfs: commencing algebraic side lattice sieving over range: 1120000 - 1160000 nfs: commencing algebraic side lattice sieving over range: 1080000 - 1120000 nfs: commencing algebraic side lattice sieving over range: 1160000 - 1200000 Special q lower bound 1040000 below rFB bound 2.08e+06 Received signal 256... please wait Special q lower bound 1080000 below rFB bound 2.08e+06 Received signal 256... please wait Special q lower bound 1240000 below rFB bound 2.08e+06 Received signal 256... please wait Special q lower bound 1160000 below rFB bound 2.08e+06 Received signal 256... please wait Special q lower bound 1200000 below rFB bound 2.08e+06 Received signal 256... please wait Special q lower bound 1120000 below rFB bound 2.08e+06 Received signal 256... please wait [/CODE] |
[QUOTE=yoyo;285307]Hello,
on a Linux64 system I try to factor some composites with yafu. I have also the gnfs binaries there[/QUOTE] Where did you get the gnfs binaries from? Yours are giving an error message for Q < fbsize, and Serge Batalov and others put in modifications to fix that some years ago. |
I have the Linux64 binaries from here [url]http://www.mersenneforum.org/showpost.php?p=126546&postcount=23[/url]
Where are the newest binaries? |
Try [url]http://www.chiark.greenend.org.uk/~twomack/gnfs-batalov/lasieveAsm64latest-updated16e.zip[/url]
|
Thanks, they are running now.
yoyo |
bsquared also has some binaries that he compiled in Nov 2011 [URL="https://sites.google.com/site/bbuhrow/lasieve4_64.7z?attredirects=0"]here[/URL].
|
Problem. Yafu gets the size mixed up on certain primes:
>> 911*8675309*9118675309 ans = 72066773964359633191 >> factor(72066773964359633191) factoring 72066773964359633191 using pretesting plan: normal div: primes less than 10000 fmt: 1000000 iterations rho: x^2 + 3, starting 10000 iterations on C18 rho: x^2 + 2, starting 10000 iterations on C18 Total factoring time = 0.0380 seconds ***factors found*** P4 = 911 P8 = 8675309 PRP11 = 9118675309 Why does it get the size wrong? Those should say 3, 7, and 10 digits, not 4, 8, and 11. It seems to only do it on about 50% of the primes I've found. 61 shows up as P2=61, but 67 shows up as P3=67. What happened? btw, it works fine on repunits. Here's the factorization of 911# to show more proof (works fine for 2-61, 101-509): [CODE]P1 = 2 P1 = 3 P1 = 5 P1 = 7 P2 = 11 P2 = 13 P2 = 17 P2 = 19 P2 = 23 P2 = 29 P2 = 31 P2 = 37 P2 = 41 P2 = 43 P2 = 47 P2 = 53 P2 = 59 P2 = 61 P3 = 67 P3 = 71 P3 = 73 P3 = 79 P3 = 83 P3 = 89 P3 = 97 P3 = 101 P3 = 103 P3 = 107 P3 = 109 P3 = 113 P3 = 127 P3 = 131 P3 = 137 P3 = 139 P3 = 149 P3 = 151 P3 = 157 P3 = 163 P3 = 167 P3 = 173 P3 = 179 P3 = 181 P3 = 191 P3 = 193 P3 = 197 P3 = 199 P3 = 211 P3 = 223 P3 = 227 P3 = 229 P3 = 233 P3 = 239 P3 = 241 P3 = 251 P3 = 257 P3 = 263 P3 = 269 P3 = 271 P3 = 277 P3 = 281 P3 = 283 P3 = 293 P3 = 307 P3 = 311 P3 = 313 P3 = 317 P3 = 331 P3 = 337 P3 = 347 P3 = 349 P3 = 353 P3 = 359 P3 = 367 P3 = 373 P3 = 379 P3 = 383 P3 = 389 P3 = 397 P3 = 401 P3 = 409 P3 = 419 P3 = 421 P3 = 431 P3 = 433 P3 = 439 P3 = 443 P3 = 449 P3 = 457 P3 = 461 P3 = 463 P3 = 467 P3 = 479 P3 = 487 P3 = 491 P3 = 499 P3 = 503 P3 = 509 P4 = 521 P4 = 523 P4 = 541 P4 = 547 P4 = 557 P4 = 563 P4 = 569 P4 = 571 P4 = 577 P4 = 587 P4 = 593 P4 = 599 P4 = 601 P4 = 607 P4 = 613 P4 = 617 P4 = 619 P4 = 631 P4 = 641 P4 = 643 P4 = 647 P4 = 653 P4 = 659 P4 = 661 P4 = 673 P4 = 677 P4 = 683 P4 = 691 P4 = 701 P4 = 709 P4 = 719 P4 = 727 P4 = 733 P4 = 739 P4 = 743 P4 = 751 P4 = 757 P4 = 761 P4 = 769 P4 = 773 P4 = 787 P4 = 797 P4 = 809 P4 = 811 P4 = 821 P4 = 823 P4 = 827 P4 = 829 P4 = 839 P4 = 853 P4 = 857 P4 = 859 P4 = 863 P4 = 877 P4 = 881 P4 = 883 P4 = 887 P4 = 907 P4 = 911[/CODE] What happened? It also works fine on the first illegal prime: [URL]http://www.factordb.com/index.php?id=1100000000291926358[/URL] (shows up as PRP because of the fact that it is >1000 digits) |
It's estimating the size-in-digits from the size-in-bits (notice that the breakpoints are 11, 67, 521 = first prime after 2^3, 2^6, 2^9) rather than doing a proper logarithm.
|
This is a known bug affecting the last version, discussed in this thread, see few pages before. B^2 promised a fix on the next release. The bug is only cosmetic, it does not influence the performance or the factoring process (maybe with the exception when selection between siqs and nfs is "on the edge" and you end up in making a nfs instead of siqs, taking about 10 minutes to half hour longer, for me this happens when a C96-C97 is identified wrong as a C97-C98, depending on the computer - they have different processors therefore different siqs/nfs cut).
|
Thanks everyone - this is indeed fixed in my development code and once I get around to finishing a few other things, I'll release another version.
|
[QUOTE=bsquared;285535]Thanks everyone - this is indeed fixed in my development code and once I get around to finishing a few other things, I'll release another version.[/QUOTE]
Will this new version run on this [URL="http://www.youtube.com/watch?v=17DPJHNVx2Q&feature=related"]Mac[/URL]? |
| All times are UTC. The time now is 22:43. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.