yafu bugs - Page 31

Dubslow · 2015-02-09, 20:57

Okay, how about this:

Code:

yafu "snfs((1145924053^19-1), (1145924053^19-1)/1145924052)"


02/09/15 14:52:16 v1.34.5 @ Gravemind, System/Build Info: 
Using GMP-ECM 7.0-dev, Powered by GMP 6.0.0
detected        Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
measured cpu frequency ~= 3392.315710
using 1 random witnesses for Rabin-Miller 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


>> nfs: checking for job file - job file found, testing for matching input
nfs: number in job file does not match input
nfs: checking for poly file - poly file found, testing for matching input
nfs: commencing nfs on c173: 13303345562369071347373642357283962165690034810857362376976557581034979264760880857329979228416336163023620060322595160533950610953053117227718347146617048626151678420617516
nfs: searching for brent special forms...
nfs: input divides 1145924053^19 - 1
gen: ========================================================
gen: considering the following polynomials:
gen: ========================================================

n: 11609273353806061265370527677242577124727315533174062723117149111933448853694957488622447753995075550629615426138725605991513485531633746725579983852731846338933183
# 1145924053^19-1, difficulty: 181.18, anorm: 7.84e+23, rnorm: 1.46e+50
# size = 1.798e-19, alpha = -0.220, combined = 1.576e-11, rroots = 2
type: snfs
size: 181
skew: 183.9878
c4: 1
c0: -1145924053
Y1: -1
Y0: 1975964677859978611243759163447028913685415493
m: 1975964677859978611243759163447028913685415493
n: 11609273353806061265370527677242577124727315533174062723117149111933448853694957488622447753995075550629615426138725605991513485531633746725579983852731846338933183
# 1145924053^19-1, difficulty: 199.30, anorm: -2.69e+35, rnorm: 4.30e+45
# size = 2.774e-21, alpha = -0.220, combined = 3.146e-12, rroots = 2
type: snfs
size: 199
skew: 0.0000
c4: 1504760928599007071085696877
c0: -1
Y1: -1
Y0: 1724341742096217794674180875621282481
m: 1724341742096217794674180875621282481
n: 11609273353806061265370527677242577124727315533174062723117149111933448853694957488622447753995075550629615426138725605991513485531633746725579983852731846338933183
# 1145924053^19-1, difficulty: 181.18, anorm: 4.99e+29, rnorm: 2.14e+41
# size = 3.134e-13, alpha = -1.041, combined = 4.390e-11, rroots = 1
type: snfs
size: 181
skew: 64.8382
c5: 1
c0: -1145924053
Y1: -1
Y0: 1724341742096217794674180875621282481
m: 1724341742096217794674180875621282481
n: 11609273353806061265370527677242577124727315533174062723117149111933448853694957488622447753995075550629615426138725605991513485531633746725579983852731846338933183
# 1145924053^19-1, difficulty: 208.36, anorm: -2.38e+46, rnorm: 6.33e+36
# size = 2.995e-16, alpha = -1.041, combined = 6.251e-13, rroots = 1
type: snfs
size: 208
skew: 0.0000
c5: 1724341742096217794674180875621282481
c0: -1
Y1: -1
Y0: 1504760928599007071085696877
m: 1504760928599007071085696877

The last polynomial, though pretty clearly inferior, goes through to test sieving anyways, where what I assume is lasieve complains "Please set a skewness". Is it a Yafu bug that the polynomial has skew 0?

Edit: I'm in need of some more remedial education. It's obvious to everyone that I'm very rusty in these things. However, once upon a time when I understood things better, I had previously written some code do automatically generate OPN polys for me (not coincidentally, this is just before the time when I started trying to make YAFU friendlier to SNFS). I just played with that code:

Code:

>>> my.opnpoly(1, 1145924053, 19, -1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: opnpoly() missing 1 required positional argument: 'deg'
>>> my.opnpoly(1, 1145924053, 19, -1, 5)
Warning: this poly has a significantly larger difficulty than the number in question, consider doing some test sieving
c5: 1
c0: -1145924053
m: 1724341742096217794674180875621282481
skew: 64.8382324510266
type: snfs
size: 182
>>> my.opnpoly(1, 1145924053, 19, -1, 6)
I recommend the following polynomial:
c6: 1145924053
c0: -1
m: 1504760928599007071085696877
skew: 0.03091296727246838
type: snfs
size: 173

Is there a reason YAFU didn't consider the degree 6? Is that simply too high a degree for such a small number? I'm going to try test sieving right now, to see what happens.

Edit2: Yes, test sieving indicates the sextic is 20-30% slower (not terribly much, all things considered). Guess the number's too small.

Also, the -nt option (code that I wrote) is horribly broken. Lovely.

bsquared · 2015-02-09, 21:51

With that enormous leading coefficient the skew will be tiny. It appears yafu is printing using %0.4f instead of %0.4e, so I suppose any skew less than 0.0001 will be printed as 0. As you note, ideally it wouldn't be test sieving this at all.

[EDIT]:
Yes, some degrees are ignored based on input size. Unless, of course, the input has an algebraic factor.

Antonio · 2015-02-21, 10:26

First time I've seen yafu restart a factorization (twice) :-

Code:

02/21/15 09:57:01 v1.34.5 @ MESHGT, System/Build Info:
Using GMP-ECM 6.3, Powered by GMP 5.1.1
detected        Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
detected L1 = 32768 bytes, L2 = 6291456 bytes, CL = 64 bytes
measured cpu frequency ~= 3368.262330
using 20 random witnesses for Rabin-Miller 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(195655305149713288154123188773949297146841344810189391089778259859470761448147802086056459550628436477448302200577)
fac: factoring 195655305149713288154123188773949297146841344810189391089778259859470761448147802086056459550628436477448302200577
fac: using pretesting plan: deep
fac: using tune info for qs/gnfs crossover
div: primes less than 10000
fmt: 100 iterations
rho: x^2 + 3, starting 100 iterations on C114
rho: x^2 + 2, starting 100 iterations on C114
rho: x^2 + 1, starting 100 iterations on C114
pm1: starting B1 = 150K, B2 = gmp-ecm default on C114
ecm: 7/30 curves on C81, B1=2K, B2=gmp-ecm default
ecm: 22/22 curves on C69, B1=2K, B2=gmp-ecm default
ecm: 2/74 curves on C69, B1=11K, B2=gmp-ecm default
fac: factoring 228436888635662051737672282421311
fac: using pretesting plan: normal
fac: no tune info: using qs/gnfs crossover of 95 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 1000 iterations on C33
rho: x^2 + 2, starting 1000 iterations on C33
rho: x^2 + 1, starting 1000 iterations on C33
pm1: starting B1 = 150K, B2 = gmp-ecm default on C33
ecm: 0/30 curves on C33, B1=2K, B2=gmp-ecm default
fac: factoring 2583536085788343611
fac: using pretesting plan: normal
fac: no tune info: using qs/gnfs crossover of 95 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 1000 iterations on C19
rho: x^2 + 2, starting 1000 iterations on C19
rho: x^2 + 1, starting 1000 iterations on C19
pm1: starting B1 = 150K, B2 = gmp-ecm default on C19
ecm: 1/30 curves on C19, B1=2K, B2=gmp-ecm default
Total factoring time = 0.0240 seconds
Total factoring time = 0.0510 seconds
Total factoring time = 0.3110 seconds
 
***factors found***
P13 = 2657885582579
P15 = 588767351145079
P54 = 547325133126275165922253050493766036856888494139235427
P14 = 88420243050701
P9 = 314029091
P10 = 8227059721
ans = 1

Note the highlighted sections - the program seems to forget what is in the yafu.ini file when it starts again!
Is this the expected behaviour or a bug?

This is on a windows 7.1 machine, if that makes a difference.

storflyt32 · 2015-03-22, 13:37

A small thing that could be wished for when it comes to the Yafu output.

When finishing up a factorization I may receive a line such as this:

Aborting...
ecm: 42/904 curves on C142, B1=1M, B2=gmp-ecm default, ETA: 1.62 hrs

***factors found***

P23 = 14388029394339866454181
P34 = 1060364486115069441191164331606927

***co-factor***
C142 = 3056163545298800158466186774022368133068016379503393272824610897858902263
463782869792447400420402750642645810331052346695783446146155176604159

http://factordb.com/index.php?id=1100000000766387041

If a blank line could be inserted in the output, it would be easier to report the individual factors.

I want to know that the report is complete, but for now I will have to mark the single line, copy it and then press carriage return manually. Of course I could report both factors at the same time, but in any case a carriage return needs to be added in order to finish a line.

Therefore, a patch could be added here, more for simplicity and ease of use rather than clarity.

legendarymudkip · 2015-03-22, 14:23

Select the factors in their entirety, without selecting the equals sign. Now paste into the factordb "report factors" box. They will automatically be on different lines.

storflyt32 · 2015-03-22, 16:50

Thank you for that information.

I will make a note of it here.

Also, if you notice Dubslow's original post, you may also be get to this by using Yafu
if you happen to be curious about things.

http://factordb.com/index.php?id=1100000000766401202

swellman · 2015-03-24, 20:27

I get a crash with Yafu 1.34 using the following command

Code:

yafu "nfs(2196940604012711320004471908473775351297134659390227237136233264506968622288346446220877771181454955472133438440586392140297383446237820309950095296878156117919090513)" -v

Consistent on various flavors of Windows, both 32 and 64 bit. It is a composite cofactor of the xyyxf number C166_148_128.

May be a repeat of a bug reported earlier, not really sure.

chris2be8 · 2015-03-25, 16:52

Crash when the name of the logfile is too long:

Code:

$ "/home/chris/yafu/yafu" 'siqs(93451347628425346579303278899392351021992509207379796205743271284749984900563)' -v -p -logfile m99-231249749008564891846452398429823351310239794671906472490432715926072893930573350580185845652491139.
*** buffer overflow detected ***: /home/chris/yafu/yafu terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f735b01c5cc]
/lib/x86_64-linux-gnu/libc.so.6(+0x110560)[0x7f735b01b560]
/home/chris/yafu/yafu[0x40e31a]
/home/chris/yafu/yafu[0x40e426]
/home/chris/yafu/yafu[0x4050bd]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f735af2cea5]
/home/chris/yafu/yafu[0x4055b5]
======= Memory map: ========
00400000-00560000 r-xp 00000000 08:01 5386358                            /home/chris/yafu/yafu
0075f000-00760000 r-xp 0015f000 08:01 5386358                            /home/chris/yafu/yafu
00760000-00771000 rwxp 00160000 08:01 5386358                            /home/chris/yafu/yafu
00771000-00779000 rwxp 00000000 00:00 0
02671000-02692000 rwxp 00000000 00:00 0                                  [heap]
7f735acf5000-7f735ad09000 r-xp 00000000 08:01 12193428                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f735ad09000-7f735af09000 ---p 00014000 08:01 12193428                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f735af09000-7f735af0a000 r-xp 00014000 08:01 12193428                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f735af0a000-7f735af0b000 rwxp 00015000 08:01 12193428                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f735af0b000-7f735b0c9000 r-xp 00000000 08:01 12193403                   /lib/x86_64-linux-gnu/libc-2.17.so
7f735b0c9000-7f735b2c8000 ---p 001be000 08:01 12193403                   /lib/x86_64-linux-gnu/libc-2.17.so
7f735b2c8000-7f735b2cc000 r-xp 001bd000 08:01 12193403                   /lib/x86_64-linux-gnu/libc-2.17.so
7f735b2cc000-7f735b2ce000 rwxp 001c1000 08:01 12193403                   /lib/x86_64-linux-gnu/libc-2.17.so
7f735b2ce000-7f735b2d3000 rwxp 00000000 00:00 0
7f735b2d3000-7f735b3d6000 r-xp 00000000 08:01 12193451                   /lib/x86_64-linux-gnu/libm-2.17.so
7f735b3d6000-7f735b5d6000 ---p 00103000 08:01 12193451                   /lib/x86_64-linux-gnu/libm-2.17.so
7f735b5d6000-7f735b5d7000 r-xp 00103000 08:01 12193451                   /lib/x86_64-linux-gnu/libm-2.17.so
7f735b5d7000-7f735b5d8000 rwxp 00104000 08:01 12193451                   /lib/x86_64-linux-gnu/libm-2.17.so
7f735b5d8000-7f735b5f0000 r-xp 00000000 08:01 12193515                   /lib/x86_64-linux-gnu/libpthread-2.17.so
7f735b5f0000-7f735b7ef000 ---p 00018000 08:01 12193515                   /lib/x86_64-linux-gnu/libpthread-2.17.so
7f735b7ef000-7f735b7f0000 r-xp 00017000 08:01 12193515                   /lib/x86_64-linux-gnu/libpthread-2.17.so
7f735b7f0000-7f735b7f1000 rwxp 00018000 08:01 12193515                   /lib/x86_64-linux-gnu/libpthread-2.17.so
7f735b7f1000-7f735b7f5000 rwxp 00000000 00:00 0
7f735b7f5000-7f735b862000 r-xp 00000000 08:01 11017595                   /usr/local/lib/libgmp.so.10.1.3
7f735b862000-7f735ba61000 ---p 0006d000 08:01 11017595                   /usr/local/lib/libgmp.so.10.1.3
7f735ba61000-7f735ba62000 r-xp 0006c000 08:01 11017595                   /usr/local/lib/libgmp.so.10.1.3
7f735ba62000-7f735ba6b000 rwxp 0006d000 08:01 11017595                   /usr/local/lib/libgmp.so.10.1.3
7f735ba6b000-7f735ba8e000 r-xp 00000000 08:01 12193377                   /lib/x86_64-linux-gnu/ld-2.17.so
7f735bb6a000-7f735bc6c000 rwxp 00000000 00:00 0
7f735bc8a000-7f735bc8d000 rwxp 00000000 00:00 0
7f735bc8d000-7f735bc8e000 r-xp 00022000 08:01 12193377                   /lib/x86_64-linux-gnu/ld-2.17.so
7f735bc8e000-7f735bc90000 rwxp 00023000 08:01 12193377                   /lib/x86_64-linux-gnu/ld-2.17.so
7fffe908e000-7fffe90af000 rwxp 00000000 00:00 0                          [stack]
7fffe91fe000-7fffe9200000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

If i shorten the name of the logfile it works OK:

Code:

$ "/home/chris/yafu/yafu" 'siqs(93451347628425346579303278899392351021992509207379796205743271284749984900563)' -v -p -logfile m99-23124.log


03/25/15 14:22:46 v1.34.5 @ 4core, System/Build Info:
Using GMP-ECM, Powered by GMP
detected         Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
detected L1 = 32768 bytes, L2 = 6291456 bytes, CL = 64 bytes
measured cpu frequency ~= 3392.281750
using 1 random witnesses for Rabin-Miller 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


>>
starting SIQS on c77: 93451347628425346579303278899392351021992509207379796205743271284749984900563

It's easy to bypass it now I know what causes the crash. So no rush to fix.

Chris

bsquared · 2015-03-25, 17:18

Quote:

Originally Posted by swellman

I get a crash with Yafu 1.34 using the following command

Code:

yafu "nfs(2196940604012711320004471908473775351297134659390227237136233264506968622288346446220877771181454955472133438440586392140297383446237820309950095296878156117919090513)" -v

Consistent on various flavors of Windows, both 32 and 64 bit. It is a composite cofactor of the xyyxf number C166_148_128.

May be a repeat of a bug reported earlier, not really sure.

It seems to work in linux, which isn't entirely helpful to your issue. Can you provide more information about where exactly it crashes (e.g., a screenshot)?

bsquared · 2015-03-25, 17:20

Quote:

Originally Posted by chris2be8

Crash when the name of the logfile is too long:

And we have a new contender for "worse-abuse-of-a-feature"

See also: http://www.mersenneforum.org/showpos...70&postcount=3

swellman · 2015-03-26, 00:41

Quote:

Originally Posted by bsquared

It seems to work in linux, which isn't entirely helpful to your issue. Can you provide more information about where exactly it crashes (e.g., a screenshot)?

Sorry I didn't expand - this seems to be the same bug behavior I reported in this post. Lots of polys scroll by, then yafu crashes at the final "m=..." line of the last polynomial. It does not seem to attempt to evaluate the polynomials nor start the test sieving routine.

A generic windows error message pops up from the OS, saying "yafu.exe has encountered a problem and needs to close. We are sorry for the inconvenience."

The error report itself is equally unhelpful. "Error signature AppName: yafu.exe AppVer: 0.0.0.0 ModName: yafu.exe
ModVer: 0.0.0.0 Offset: 000deccc".

Can anyone else confirm this crash in Windows?

2015-02-09, 21:51	#332
bsquared "Ben" Feb 2007 3·1,171 Posts	With that enormous leading coefficient the skew will be tiny. It appears yafu is printing using %0.4f instead of %0.4e, so I suppose any skew less than 0.0001 will be printed as 0. As you note, ideally it wouldn't be test sieving this at all. [EDIT]: Yes, some degrees are ignored based on input size. Unless, of course, the input has an algebraic factor. Last fiddled with by bsquared on 2015-02-09 at 21:55

2015-03-22, 13:37	#334
storflyt32 Feb 2013 2×229 Posts	A small thing that could be wished for when it comes to the Yafu output. When finishing up a factorization I may receive a line such as this: Aborting... ecm: 42/904 curves on C142, B1=1M, B2=gmp-ecm default, ETA: 1.62 hrs *factors found* P23 = 14388029394339866454181 P34 = 1060364486115069441191164331606927 *co-factor* C142 = 3056163545298800158466186774022368133068016379503393272824610897858902263 463782869792447400420402750642645810331052346695783446146155176604159 http://factordb.com/index.php?id=1100000000766387041 If a blank line could be inserted in the output, it would be easier to report the individual factors. I want to know that the report is complete, but for now I will have to mark the single line, copy it and then press carriage return manually. Of course I could report both factors at the same time, but in any case a carriage return needs to be added in order to finish a line. Therefore, a patch could be added here, more for simplicity and ease of use rather than clarity. Last fiddled with by storflyt32 on 2015-03-22 at 13:42

2015-03-22, 16:50	#336
storflyt32 Feb 2013 2×229 Posts	Thank you for that information. I will make a note of it here. Also, if you notice Dubslow's original post, you may also be get to this by using Yafu if you happen to be curious about things. http://factordb.com/index.php?id=1100000000766401202 Last fiddled with by storflyt32 on 2015-03-22 at 16:50

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Running YAFU via Aliqueit doesn't find yafu.ini	EdH	YAFU	8	2018-03-14 17:22
Where to report bugs	Matt	Software	1	2007-02-20 19:13
Possible Prime95 bugs	JuanTutors	Software	9	2006-09-24 21:22
RMA 1.7 beta bugs	TTn	15k Search	2	2004-11-24 22:11
RMA 1.6 fixes LLR bugs!	TTn	15k Search	16	2004-06-16 01:22

2015-03-22, 14:23	#335
legendarymudkip Jun 2014 2³×3×5 Posts	Select the factors in their entirety, without selecting the equals sign. Now paste into the factordb "report factors" box. They will automatically be on different lines.

2015-03-24, 20:27	#337
swellman Jun 2012 2²×13×59 Posts	I get a crash with Yafu 1.34 using the following command Code: yafu "nfs(2196940604012711320004471908473775351297134659390227237136233264506968622288346446220877771181454955472133438440586392140297383446237820309950095296878156117919090513)" -v Consistent on various flavors of Windows, both 32 and 64 bit. It is a composite cofactor of the xyyxf number C166_148_128. May be a repeat of a bug reported earlier, not really sure.