mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   YAFU (https://www.mersenneforum.org/forumdisplay.php?f=96)
-   -   Yafu (https://www.mersenneforum.org/showthread.php?t=10871)

yoyo 2012-01-07 20:02

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]

fivemack 2012-01-07 20:06

[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.

yoyo 2012-01-07 20:14

I have the Linux64 binaries from here [url]http://www.mersenneforum.org/showpost.php?p=126546&postcount=23[/url]

Where are the newest binaries?

fivemack 2012-01-07 20:28

Try [url]http://www.chiark.greenend.org.uk/~twomack/gnfs-batalov/lasieveAsm64latest-updated16e.zip[/url]

yoyo 2012-01-07 20:52

Thanks, they are running now.
yoyo

EdH 2012-01-07 22:43

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].

Stargate38 2012-01-08 00:29

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)

fivemack 2012-01-08 00:56

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.

LaurV 2012-01-09 05:39

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).

bsquared 2012-01-09 14:34

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.

pinhodecarlos 2012-01-09 14:55

[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.