20180423, 06:10  #1 
Apr 2018
1 Posts 
two (trivial) bugs for yafu 1.34
Hello. When I played with yafu1.34 recently, I found some unusual behaviours as below:
1. The state_fermat is bypassed on Linux machine, due to uninitalized fermat_iterations variable. 2. When I use a large number consist of many primes, the output type can be wrong. It seems the type variables are not correctly updated when delete factors. For example, one factor is wrongly labeled as prime here. Code:
user@machine:~$ ./yafu 04/23/18 06:03:04 v1.34.5 @ machine, System/Build Info: Using GMPECM 6.4.4, Powered by GMP 5.1.1 detected Intel(R) Xeon(R) CPU E52650 v4 @ 2.20GHz detected L1 = 32768 bytes, L2 = 31457280 bytes, CL = 64 bytes measured cpu frequency ~= 2199.976780 using 20 random witnesses for RabinMiller PRP checks =============================================================== ======= Welcome to YAFU (Yet Another Factoring Utility) ======= ======= bbuhrow@gmail.com ======= ======= Type help at any time, or quit to quit ======= =============================================================== cached 78498 primes. pmax = 999983 >> factor(27581 * 27583 * 27611 * 27617 * 27631 * 27647 * 27653 * 27673 * 27689 * 27691 * 27697 * 27701 * 27733 * 27737 * 27739) fac: factoring 4256714116406481080465850827827846132360630331512285046282096722381 fac: using pretesting plan: normal fac: no tune info: using qs/gnfs crossover of 95 digits div: primes less than 10000 rho: x^2 + 3, starting 1000 iterations on C67 rho: x^2 + 2, starting 1000 iterations on C67 rho: x^2 + 2, starting 1000 iterations on C63 rho: x^2 + 2, starting 1000 iterations on C54 rho: x^2 + 2, starting 1000 iterations on C45 rho: x^2 + 2, starting 1000 iterations on C40 rho: x^2 + 2, starting 1000 iterations on C36 rho: x^2 + 2, starting 1000 iterations on C18 rho: x^2 + 2, starting 1000 iterations on C9 fac: factoring 765295807 fac: using pretesting plan: normal fac: no tune info: using qs/gnfs crossover of 95 digits div: primes less than 10000 fmt: 1000000 iterations Total factoring time = 0.0059 seconds fac: factoring 587328196026280979 fac: using pretesting plan: normal fac: no tune info: using qs/gnfs crossover of 95 digits div: primes less than 10000 fmt: 1000000 iterations fac: factoring 766734251 fac: using pretesting plan: normal fac: no tune info: using qs/gnfs crossover of 95 digits div: primes less than 10000 fmt: 1000000 iterations Total factoring time = 0.0054 seconds fac: factoring 766012729 fac: using pretesting plan: normal fac: no tune info: using qs/gnfs crossover of 95 digits div: primes less than 10000 fmt: 1000000 iterations Total factoring time = 0.0055 seconds Total factoring time = 0.0215 seconds fac: factoring 763304359 fac: using pretesting plan: normal fac: no tune info: using qs/gnfs crossover of 95 digits div: primes less than 10000 fmt: 1000000 iterations Total factoring time = 0.0057 seconds too many refactorization attempts, aborting Total factoring time = 0.0451 seconds ***factors found*** P5 = 27701 P5 = 27739 P5 = 27689 P9 = 761538991 P5 = 27653 P5 = 27691 P5 = 27697 P5 = 27631 P5 = 27733 P5 = 27647 P5 = 27737 P5 = 27617 P5 = 27673 P5 = 27583 ans = 1 I have tried to patch it locally as below, if anyone interested. (the newest source I have found is 1.34.3) Code:
user@machine:~$ diff ~/yafu1.34src/yafu1.34.3/factor/factor_common.c ~/yafu1.34src/yafu1.34.3/factor/factor_common.c.bak 557d556 < fobj>fobj_factors[j].type = fobj>fobj_factors[j+1].type; 1816d1814 < fwork>fermat_iterations = 0; 
20180519, 21:14  #2 
May 2018
3 Posts 
The yafu bug, is it universal?
The yafu that I have just compiled from the source files available here cannot factor this integer [67 digits]: 4256714116406481080465850827827846132360630331512285046282096722381
Well, yafu factors it but does not get it right. The factoring time is less than a second, but in the list of factors is P9 = 761538991, which is not prime. Therefore yafu gets it WRONG! Do other versions of yafu have this problem? I would like to find a version of yafu that can factor this integer. What is special about this integer? Other factoring programs, such as msieve and parigp, get it right. Why do I care? Well, for integers up to 70 digits or so, yafu has the best time, and I have a lot of such integers to factor. 
20180520, 03:24  #3 
"Kieren"
Jul 2011
In My Own Galaxy!
2·3·1,693 Posts 
Hi! And welcome to the forum. May you find what you are looking for!
I am a recently appointed moderator, and yours is the first post I got to pass through. Thanks! 
20180520, 13:02  #4 
"Ben"
Feb 2007
2·3^{2}·191 Posts 
There was a bug in the rho code that was fixed a while ago that may be causing this... are you using the latest source from /branches/wip?

20180524, 08:52  #5 
May 2018
11_{2} Posts 
Am I getting yafu from the correct place?
Here is the url:
http://www.mersenneforum.org/showthread.php?t=23087 Here is what is suggested to get yafu: svn co https://svn.code.sf.net/p/yafu/code/branches/wip Here is what happens: version 1.34.5 in directory yafucode on 21 May 18 version 1.35 beta in directory wip on 23 May 18 < does not compile Am I getting yafu from the correct place? 
20180524, 13:11  #6 
"Ben"
Feb 2007
3438_{10} Posts 
Yes, that looks like the right place. And I've verified the bug with yafu1.34.5. branches/wip works. So, how are you trying to compile the wip version?

20180524, 16:43  #7 
"Ed Hall"
Dec 2009
Adirondack Mtns
2·3·619 Posts 
I ran the composite with several of my machines across three different platforms and OSs with no issue, so I can't duplicate the trouble here.

20180527, 06:40  #8  
May 2018
3_{16} Posts 
I am getting a compiler error
Two hours ago I did the following to make sure that I have the latest code:
svn co https://svn.code.sf.net/p/yafu/code/branches/wip Question: Why is spbrent.c in the top directory? I am running Fedora 28. I am using gcc version 8.1.11. I modified the makefile for my environment. This is the compiler error that I am getting: Quote:


20180529, 19:38  #9  
"Ben"
Feb 2007
2×3^{2}×191 Posts 
Quote:
(I suspect there will still be cases that won't work.) 

20180530, 21:32  #10 
"Ed Hall"
Dec 2009
Adirondack Mtns
2×3×619 Posts 
Is gcc7.3.0 a requirement? The repository gcc for Ubuntu 16.04 is 5.4.0, which compiles r369 without trouble. (I'm also compiling it against r1021 of msieve.) I am running the r369 revision on a test machine ATM, with no noticeable issues.
Thanks for all... Last fiddled with by EdH on 20180530 at 21:33 
20180530, 22:05  #11 
"Ben"
Feb 2007
2·3^{2}·191 Posts 
Not a requirement unless you want to build AVX512 enabled code (of which there is now some in the sieve of Eratosthenes). Then you need some version of gcc capable of that, which I think starts in 7.x somewhere.

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
yafu bugs  jwes  YAFU  492  20210419 09:44 
Running YAFU via Aliqueit doesn't find yafu.ini  EdH  YAFU  8  20180314 17:22 
Trivial question  davieddy  Information & Answers  6  20111208 08:07 
Trivial bug: repeated PM notifications  Christenson  Forum Feedback  0  20110321 03:49 
SNFS trivial factorization  fetofs  Factoring  39  20060726 12:32 